From report at bugs.python.org  Thu Aug  1 00:21:51 2013
From: report at bugs.python.org (Catherine Devlin)
Date: Wed, 31 Jul 2013 22:21:51 +0000
Subject: [issue1666318] shutil.copytree doesn't give control over directory
	permissions
Message-ID: <1375309311.97.0.698221223399.issue1666318@psf.upfronthosting.co.za>


Catherine Devlin added the comment:

Thanks, Antoine - I've signed and submitted the Contributor's Agreement.

----------
Added file: http://bugs.python.org/file31104/Python Contributor Agreement Form - signed.pdf

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

From report at bugs.python.org  Thu Aug  1 00:39:26 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 31 Jul 2013 22:39:26 +0000
Subject: [issue18214] Stop purging modules which are garbage collected before
	shutdown
In-Reply-To: <1371221979.53.0.00385452158182.issue18214@psf.upfronthosting.co.za>
Message-ID: <1375310366.88.0.440570013978.issue18214@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

I played a bit with the patch and -v -Xshowrefcount.  The number of references and blocks left at exit varies (and is higher than for unpatched python).

It appears that a few (1-3) module dicts are not being purged because they have been "orphaned".  (i.e. the module object was garbaged collected before we check the weakref, but the module dict survived.)  Presumably it is the hash randomization causing the randomness.

Maybe 8 out of 50+ module dicts actually die a natural death by being garbage collected before they are purged.  Try

    ./python -v -Xshowrefcount check_purging.py

----------
Added file: http://bugs.python.org/file31105/check_purging.py

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

From report at bugs.python.org  Thu Aug  1 00:48:21 2013
From: report at bugs.python.org (Robin Schoonover)
Date: Wed, 31 Jul 2013 22:48:21 +0000
Subject: [issue18610] wsgiref.validator expects wsgi.input read to give
	exactly one arg
Message-ID: <1375310901.82.0.276465395742.issue18610@psf.upfronthosting.co.za>


New submission from Robin Schoonover:

wsgiref.validator requires wsgi.input's read to always give EXACTLY one argument. This is incorrect.

It's own documentation says:
* That wsgi.input is used properly:
  - .read() is called with zero or one argument

PEP3333 says:
A server should allow read() to be called without an argument, and return the remainder of the client's input stream.

----------
components: Library (Lib)
files: wsgiref.patch
keywords: patch
messages: 194027
nosy: Robin.Schoonover
priority: normal
severity: normal
status: open
title: wsgiref.validator expects wsgi.input read to give exactly one arg
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31106/wsgiref.patch

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

From report at bugs.python.org  Thu Aug  1 00:50:39 2013
From: report at bugs.python.org (Robin Schoonover)
Date: Wed, 31 Jul 2013 22:50:39 +0000
Subject: [issue18610] wsgiref.validate expects wsgi.input read to give exactly
	one arg
In-Reply-To: <1375310901.82.0.276465395742.issue18610@psf.upfronthosting.co.za>
Message-ID: <1375311039.81.0.202586251052.issue18610@psf.upfronthosting.co.za>


Changes by Robin Schoonover <robin at cornhooves.org>:


----------
title: wsgiref.validator expects wsgi.input read to give exactly one arg -> wsgiref.validate expects wsgi.input read to give exactly one arg

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

From report at bugs.python.org  Thu Aug  1 00:51:26 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 31 Jul 2013 22:51:26 +0000
Subject: [issue11571] Turtle window pops under the terminal on OSX
In-Reply-To: <1300287451.35.0.164099198094.issue11571@psf.upfronthosting.co.za>
Message-ID: <1375311086.03.0.950312882762.issue11571@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Thu Aug  1 00:57:14 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 31 Jul 2013 22:57:14 +0000
Subject: [issue18603] PyOS_mystricmp unused and no longer available
In-Reply-To: <1375228725.23.0.641374823001.issue18603@psf.upfronthosting.co.za>
Message-ID: <1375311434.72.0.613812525559.issue18603@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


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

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

From report at bugs.python.org  Thu Aug  1 02:11:39 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 01 Aug 2013 00:11:39 +0000
Subject: [issue1666318] shutil.copytree doesn't give control over directory
	permissions
Message-ID: <1375315899.39.0.541384154388.issue1666318@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Hi Catherine,

the contributor agreement must go through proper channels. The bug tracker is not the right place to post your agreement. Please follow the instructions at http://www.python.org/psf/contrib/ . You can submit the agreement electronically, too.

----------
nosy: +christian.heimes

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

From report at bugs.python.org  Thu Aug  1 02:11:48 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 01 Aug 2013 00:11:48 +0000
Subject: [issue1666318] shutil.copytree doesn't give control over directory
	permissions
Message-ID: <1375315908.43.0.405463028578.issue1666318@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


Removed file: http://bugs.python.org/file31104/Python Contributor Agreement Form - signed.pdf

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

From report at bugs.python.org  Thu Aug  1 02:48:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Aug 2013 00:48:43 +0000
Subject: [issue17616] wave.Wave_read and wave.Wave_write can be context
	managers
In-Reply-To: <1364894166.78.0.454807000252.issue17616@psf.upfronthosting.co.za>
Message-ID: <3c5CYP4PNPz7Lk1@mail.python.org>


Roundup Robot added the comment:

New changeset 4f3b6eff2ede by R David Murray in branch 'default':
#17616: Improve context manager tests, fix bugs in close method and mode docs.
http://hg.python.org/cpython/rev/4f3b6eff2ede

----------

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

From report at bugs.python.org  Thu Aug  1 03:11:52 2013
From: report at bugs.python.org (Bill Gale)
Date: Thu, 01 Aug 2013 01:11:52 +0000
Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with
	VC Express
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1375319511.99.0.907062436998.issue7511@psf.upfronthosting.co.za>


Bill Gale added the comment:

so i hit the same exception, here is how i solved it.

environment:
windows 7 enterprise 64 bit
python 2.7.5 64 bit
visual studio 2008 32 bit

issue:
pip installs failed with the above exception.

solution:
there are two parts.
1. install 64 bit components to vs2008
2. modify the PATH to point to 64 bit vs2008 bin folder

to confirm is this solution will help you:
check if there is an amd64 under your vs2008 bin folder:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin
if yes, this solution will not help you.
if missing follow the steps below.

step 1.
control panel
select Microsoft Visual Studio 2008 Professional -ENU
window Visual Studio 2008 Maintenance Mode is opened
click through to and select Add or Remove Features
Under Language Tools->VC++ "X64 Compilers and Tools" should be unchecked.
if it is checked, skip to step 2.
check "X64 Compilers and Tools", Update.
you may have to provide the VS2008 installation CD.
confirm that update creates bin\amd64 subfolder.

step 2.
add 64 bit subfolder to your path.
VS2008_HOME=C:\Program Files (x86)\Microsoft Visual Studio 9.0
PATH=%PATH%;%VS2008_HOME%\VC\bin;%VS2008_HOME%\VC\bin\amd64;
open new command window to receive new PATH changes.
pip installations should no die with the ValueError.

----------
nosy: +bgale

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

From report at bugs.python.org  Thu Aug  1 06:35:31 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 01 Aug 2013 04:35:31 +0000
Subject: [issue1666318] shutil.copytree doesn't give control over directory
	permissions
Message-ID: <1375331731.86.0.121049235479.issue1666318@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Hi Catherine,

I saw your patch. It looks good, except you are trying to copy the directory onto its subdirectory.

src_dir = tempfile.mkdtemp()
dst_dir = os.path.join(tempfile.mkdtemp(), 'destination')

I prefer it if you copy it to somewhere else. This would be better:

tmp_dir = self.mkdtemp()
src = os.path.join(tmp_dir, 'foo')
dst = os.path.join(tmp_dir, 'bar')

----------
nosy: +vajrasky

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

From report at bugs.python.org  Thu Aug  1 07:58:41 2013
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Thu, 01 Aug 2013 05:58:41 +0000
Subject: [issue17998] internal error in regular expression engine
In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za>
Message-ID: <1375336721.45.0.728085399172.issue17998@psf.upfronthosting.co.za>


Changes by Bohuslav "Slavek" Kabrda <bkabrda at redhat.com>:


----------
nosy: +bkabrda

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

From report at bugs.python.org  Thu Aug  1 09:14:26 2013
From: report at bugs.python.org (Michael Foord)
Date: Thu, 01 Aug 2013 07:14:26 +0000
Subject: [issue16662] load_tests not invoked in package/__init__.py
In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za>
Message-ID: <1375341266.01.0.367607810958.issue16662@psf.upfronthosting.co.za>


Michael Foord added the comment:

I'm happy with the check being removed.

The old behaviour was documented I believe - so there'd need to be documentation changes to go with it. As the old behaviour is so "un-useful" I don't think there are backward compatibility issues with changing it.

----------

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

From report at bugs.python.org  Thu Aug  1 09:44:55 2013
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Thu, 01 Aug 2013 07:44:55 +0000
Subject: [issue17998] internal error in regular expression engine
In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za>
Message-ID: <1375343095.04.0.714809905119.issue17998@psf.upfronthosting.co.za>


Changes by C?dric Krier <cedric.krier at b2ck.com>:


----------
nosy: +ced

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

From report at bugs.python.org  Thu Aug  1 10:21:10 2013
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 01 Aug 2013 08:21:10 +0000
Subject: [issue16245] Update html.entities.html5 dictionary and
	parseentities.py
In-Reply-To: <1350380511.49.0.860998010837.issue16245@psf.upfronthosting.co.za>
Message-ID: <1375345270.34.0.233852492299.issue16245@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I'm downgrading this to "deferred blocker".  We'll make sure it happens before Python 3.4.0, but there's no need to hold up Python 3.4a1 for this.

----------
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Thu Aug  1 10:22:13 2013
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 01 Aug 2013 08:22:13 +0000
Subject: [issue18257] Two copies of python-config
In-Reply-To: <1371567872.42.0.116049773773.issue18257@psf.upfronthosting.co.za>
Message-ID: <1375345333.6.0.389139375628.issue18257@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Okay, downgrading to "deferred blocker".

----------
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Thu Aug  1 10:23:29 2013
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 01 Aug 2013 08:23:29 +0000
Subject: [issue5302] Allow package_data specs/globs to match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1375345409.54.0.198620772308.issue5302@psf.upfronthosting.co.za>


Larry Hastings added the comment:

And this will hold up Python 3.4a1, as I can't close #13463 until this is closed first.  So I'm closing this as wontfix.

----------
nosy: +larry
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Thu Aug  1 10:23:59 2013
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 01 Aug 2013 08:23:59 +0000
Subject: [issue13463] Fix parsing of package_data
In-Reply-To: <1322068433.36.0.783240091616.issue13463@psf.upfronthosting.co.za>
Message-ID: <1375345439.28.0.0647222076793.issue13463@psf.upfronthosting.co.za>


Larry Hastings added the comment:

This was held up by #5302, so I just closed that one too as the same rule applies.

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

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

From report at bugs.python.org  Thu Aug  1 10:25:03 2013
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 01 Aug 2013 08:25:03 +0000
Subject: [issue17998] internal error in regular expression engine
In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za>
Message-ID: <1375345503.26.0.999332787957.issue17998@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Can I downgrade this to "deferred blocker"?  That means we still need to deal with it before the release, but we don't have to hold up Python 3.4a1 for it.

----------

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

From report at bugs.python.org  Thu Aug  1 11:34:14 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 01 Aug 2013 09:34:14 +0000
Subject: [issue18181] PEP447: Add type.__locallookup__
In-Reply-To: <1370870153.93.0.646087371852.issue18181@psf.upfronthosting.co.za>
Message-ID: <1375349654.28.0.341959386734.issue18181@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Updated the patch for PEP 442.

----------
Added file: http://bugs.python.org/file31107/issue-18181-full-v4.txt

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

From report at bugs.python.org  Thu Aug  1 11:37:05 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 01 Aug 2013 09:37:05 +0000
Subject: [issue5262] PythonLauncher considered harmfull
In-Reply-To: <1234638505.38.0.029039550018.issue5262@psf.upfronthosting.co.za>
Message-ID: <1375349825.54.0.897654219883.issue5262@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The attached patch removes the code that checks if "Python Launcher" is the default application for opening python files.

----------
Added file: http://bugs.python.org/file31108/issue-5262.txt

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

From report at bugs.python.org  Thu Aug  1 11:49:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 09:49:15 +0000
Subject: [issue18214] Stop purging modules which are garbage collected before
	shutdown
In-Reply-To: <1371221979.53.0.00385452158182.issue18214@psf.upfronthosting.co.za>
Message-ID: <1375350555.58.0.466500236393.issue18214@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> It appears that a few (1-3) module dicts are not being purged because they 
> have been "orphaned".  (i.e. the module object was garbaged collected before 
> we check the weakref, but the module dict survived.) 

Module globals can be kept alive by any function defined in that module. So if that function is registered eternally in a C static variable, the globals dict will never get collected.

> ./python -v -Xshowrefcount check_purging.py

I always get either:

# remaining {'encodings', '__main__'}
[...]
[24834 refs, 7249 blocks]

or

# remaining {'__main__', 'encodings'}
[...]
[24834 refs, 7249 blocks]

... which seems to hint that it is quite stable actually.
The encodings globals are kept alive because of the codecs registration, I believe.
As for the __main__ dict, perhaps we're missing a decref somewhere.

> Maybe 8 out of 50+ module dicts actually die a natural death by being 
> garbage collected before they are purged.

I get different numbers from you. If I run "./python -v -c pass", most modules in the "wiping" phase are C extension modules, which is expected. Pretty much every pure Python module ends up garbage collected before that.

By the way, please also try issue18608 which will bring an other improvement.

----------

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

From report at bugs.python.org  Thu Aug  1 11:50:44 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 01 Aug 2013 09:50:44 +0000
Subject: [issue18611] Mac: Some Python Launcher issues
Message-ID: <1375350644.84.0.910420929307.issue18611@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

There are some issues with the Python Launcher application:

1) There is a useless 'Help' menu, the application does not
   include help (removal is trivial and doesn't affect functionality)

2) The list of interpreters does not include the framework locations,
   only /usr/local, /usr and /sw (Fink).

   IMHO the factory default should only include the framework and
   system pythons.

3) Python Launcher should probably sniff the script for a '#!', if 
   only to detect if the script is python 2 or 3. 
   
   This may need to be an option, an the algoritm needs to be specified.
   Probably something like:

   - No #!: use app setting
   - #!/usr/bin/env ...: use '...' to determine python version, use
     app setting to find that. 
   
     Rationale: /usr/bin/env uses $PATH to find a binary, the value
     of $PATH for GUI apps cannot easily be changed by users (if at all,
     there used to be an environment.plist file but I haven't checked if
     thats still used by the system).  Therefore it is better to use
     an application setting for this.

   - #!/path/to/python: use that interpreter if it exists
     (not sure yet what should happen if that interpreter does not exist)

   This has several advantages over the current behavior:
   - Can use a single Python Launcher for python2 and python3 scripts
   - Works with virtualenv/pyvenv environments (assuming that the right
     path is used in the #! line)

See also the pep397 specification for the "py" launcher on windows, but I don't propose to add such a command-line tool to Mac installations, the normal Unix conventions work just fine for command-line use.

See als #5262

----------
assignee: ronaldoussoren
components: Macintosh
messages: 194041
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Mac: Some Python Launcher issues
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug  1 11:55:59 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 01 Aug 2013 09:55:59 +0000
Subject: [issue18608] Avoid keeping a strong reference to locale in the _io
	module
In-Reply-To: <1375305631.67.0.684843179592.issue18608@psf.upfronthosting.co.za>
Message-ID: <1375350959.61.0.321816776394.issue18608@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

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

From report at bugs.python.org  Thu Aug  1 11:56:34 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 01 Aug 2013 09:56:34 +0000
Subject: [issue18214] Stop purging modules which are garbage collected before
	shutdown
In-Reply-To: <1371221979.53.0.00385452158182.issue18214@psf.upfronthosting.co.za>
Message-ID: <1375350994.33.0.514039468098.issue18214@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

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

From report at bugs.python.org  Thu Aug  1 11:59:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 09:59:25 +0000
Subject: [issue18214] Stop purging modules which are garbage collected before
	shutdown
In-Reply-To: <1371221979.53.0.00385452158182.issue18214@psf.upfronthosting.co.za>
Message-ID: <1375351165.31.0.90572956917.issue18214@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> As for the __main__ dict, perhaps we're missing a decref somewhere.

Actually, it's not surprising. Blob's methods hold a reference to the __main__ globals, and there's still a Blob object alive in encodings.

If you replace the end of your script with the following:

for name, mod in sys.modules.items():
    if name != 'encodings':
        mod.__dict__["__blob__"] = Blob(name)
del name, mod, Blob


then at the end of the shutdown phase, remaining is empty.

----------

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

From report at bugs.python.org  Thu Aug  1 12:27:14 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 01 Aug 2013 10:27:14 +0000
Subject: [issue18214] Stop purging modules which are garbage collected before
	shutdown
In-Reply-To: <1375351165.31.0.90572956917.issue18214@psf.upfronthosting.co.za>
Message-ID: <51FA37F9.5020405@gmail.com>


Richard Oudkerk added the comment:

On 01/08/2013 10:59am, Antoine Pitrou wrote:
> If you replace the end of your script with the following:
>
> for name, mod in sys.modules.items():
>      if name != 'encodings':
>          mod.__dict__["__blob__"] = Blob(name)
> del name, mod, Blob
>
>
> then at the end of the shutdown phase, remaining is empty.

On Windows, even with this change, I get for example:

   # remaining {'encodings.mbcs', '__main__', 'encodings.cp1252'}
   ...
   [22081 refs, 6742 blocks]

or

   # remaining {'__main__', 'encodings'}
   ...
   [23538 refs, 7136 blocks]

----------

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

From report at bugs.python.org  Thu Aug  1 12:40:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 10:40:39 +0000
Subject: [issue18214] Stop purging modules which are garbage collected before
	shutdown
In-Reply-To: <1371221979.53.0.00385452158182.issue18214@psf.upfronthosting.co.za>
Message-ID: <1375353639.23.0.690904372683.issue18214@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

You might want to open a prompt and look at gc.get_referrers() for encodings.mbcs.__dict__ (or another of those modules).

----------

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

From report at bugs.python.org  Thu Aug  1 13:08:35 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 01 Aug 2013 11:08:35 +0000
Subject: [issue18214] Stop purging modules which are garbage collected before
	shutdown
In-Reply-To: <1371221979.53.0.00385452158182.issue18214@psf.upfronthosting.co.za>
Message-ID: <1375355315.8.0.935721723114.issue18214@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> You might want to open a prompt and look at gc.get_referrers() for 
> encodings.mbcs.__dict__ (or another of those modules).

>>> gc.get_referrers(sys.modules['encodings.mbcs'].__dict__)
[<module 'encodings.mbcs' from 'C:\\Repos\\cpython-dirty\\lib\\encodings\\mbcs.py'>, <function decode at 0x01DEEF38>, <function getregentry at 0x01DFA038>, <function IncrementalEncoder.encode at 0x01DFA098>]

>>> gc.get_referrers(sys.modules['encodings.cp1252'].__dict__)
[<module 'encodings.cp1252' from 'C:\\Repos\\cpython-dirty\\lib\\encodings\\cp1252.py'>, <function getregentry at 0x02802578>, <function Codec.encode at 0x02802518>, <function Codec.decode at 0x028025D8>, <function IncrementalEncoder.encode at 0x02802638>, <function IncrementalDecoder.decode at 0x02802698>]

>>> gc.get_referrers(sys.modules['__main__'].__dict__)
[<function Blob.__init__ at 0x0057ABD8>, <function Blob.__del__ at 0x02AD36F8>,
<frame object at 0x027DFA80>, <function <listcomp> at 0x02AD3DB8>, <frame object at 0x02A38038>, <module '__main__' (<_frozen_importlib.SourceFileLoader object
at 0x0271EAB8>)>]

----------

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

From report at bugs.python.org  Thu Aug  1 13:09:35 2013
From: report at bugs.python.org (Tim Golden)
Date: Thu, 01 Aug 2013 11:09:35 +0000
Subject: [issue18306] os.stat gives exception for Windows junctions in v3.3
In-Reply-To: <1372236300.43.0.559187613539.issue18306@psf.upfronthosting.co.za>
Message-ID: <1375355375.68.0.308421150629.issue18306@psf.upfronthosting.co.za>


Tim Golden added the comment:

I propose to close this one: using Python 3.3 on Win7 I can successfully stat NTFS Junctions. Is there any remaining issue?

----------

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

From report at bugs.python.org  Thu Aug  1 13:17:24 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 01 Aug 2013 11:17:24 +0000
Subject: [issue18214] Stop purging modules which are garbage collected before
	shutdown
In-Reply-To: <1371221979.53.0.00385452158182.issue18214@psf.upfronthosting.co.za>
Message-ID: <1375355844.87.0.23023177643.issue18214@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> I get different numbers from you. If I run "./python -v -c pass", most 
> modules in the "wiping" phase are C extension modules, which is expected. 
> Pretty much every pure Python module ends up garbage collected before 
> that.

The *module* gets gc'ed, sure.  But you can't tell from "./python -v -c pass" when the *module dict* get gc'ed.

Using "./python -v check_purging.py", before the purging stage (# cleanup [3]) I only get

# purge/gc operator 54
# purge/gc io 53
# purge/gc keyword 52
# purge/gc types 51
# purge/gc sysconfig 50

That leaves lots of pure python module dicts to be purged later on.

----------

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

From report at bugs.python.org  Thu Aug  1 13:23:32 2013
From: report at bugs.python.org (uglemat)
Date: Thu, 01 Aug 2013 11:23:32 +0000
Subject: [issue18612] More elaborate documentation on how list comprehensions
	and generator expressions relate to each other
Message-ID: <1375356212.93.0.797789110077.issue18612@psf.upfronthosting.co.za>


New submission from uglemat:

Today there are list comprehensions, set comprehensions, dict comprehensions and then... there are generator expressions, which apparently was called 'generator comprehensions' in the original PEP, don't know why that was changed. Some questions arises:

 * Are generator expressions a type of list comprehension, or are generator expressions to be considered their own thing.

 * Does 'list comprehension' mean a type of comprehension that happens to return a list, or is it to be considered more of a general concept.

I usually talk about 'list comprehension' as a type of comprehension, and 'generator expression' as another type of comprehension, and after investigating whether or not that is correct I couldn't find an answer. On the wikipedia article on list comprension (http://en.wikipedia.org/wiki/List_comprehension#Python) they list generator expressions as well, indicating that it's a type of list comprehension. I think there's a lot of confusion to be had here, and that the documentation should clarify what exactly is meant by 'list comprehensions', regardless of what happens to be the case.

I haven't really a bug report before, so forgive me if I'm doing something wrong. :)

----------
assignee: docs at python
components: Documentation
messages: 194048
nosy: docs at python, uglemat
priority: normal
severity: normal
status: open
title: More elaborate documentation on how list comprehensions and generator expressions relate to each other
versions: Python 3.5

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

From report at bugs.python.org  Thu Aug  1 13:45:54 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Aug 2013 11:45:54 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>
Message-ID: <3c5V7j6P8wz7LjZ@mail.python.org>


Roundup Robot added the comment:

New changeset f283589cb71e by Tim Golden in branch 'default':
Issue #9035: os.path.ismount now recognises volumes mounted below
http://hg.python.org/cpython/rev/f283589cb71e

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Aug  1 14:01:51 2013
From: report at bugs.python.org (Laurent Fournier)
Date: Thu, 01 Aug 2013 12:01:51 +0000
Subject: [issue18613] wrong float minus op result
Message-ID: <1375358511.45.0.0761593009905.issue18613@psf.upfronthosting.co.za>


New submission from Laurent Fournier:

Python 3.3.1 (with GCC 4.7.3) on Linux

print (.3-.1)
0.199999999999999998

----------
messages: 194050
nosy: Laurent.Fournier
priority: normal
severity: normal
status: open
title: wrong float minus op result
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug  1 14:05:27 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Aug 2013 12:05:27 +0000
Subject: [issue18517] "xxlimited" extension declared incorrectly in setup.py
In-Reply-To: <1374393760.41.0.977042124577.issue18517@psf.upfronthosting.co.za>
Message-ID: <1375358727.89.0.932931433446.issue18517@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I would be fine with it being build only in a debug build. The rationale for the module is that it should test whether the header files actually compile under the limited API (or whether e.g. some functions are exposed that rely on unexposed structures). So the main test is really whether it compiles.

----------

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

From report at bugs.python.org  Thu Aug  1 14:14:51 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Aug 2013 12:14:51 +0000
Subject: [issue18521] [cppcheck] Full report
In-Reply-To: <1374408848.64.0.369654911435.issue18521@psf.upfronthosting.co.za>
Message-ID: <1375359291.78.0.264591619982.issue18521@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Julien: I propose to resolve this issue in the same way as we have done previously with analysis tools (with some unfortunate exceptions).

Somebody motivated enough (hopefully you) agrees to initially study the tool output, and ideally also then agrees to run the tool on a regular basis (but this is really not mandatory - the help with the initial run is already appreciated).

You would then filter out the reports, and see which of them are useful. If you can, have the tool silence the bogus reports (e.g. with a configuration file). For the issues that you consider valid, please file individual bug reports (possibly combining related reports, e.g. by module or by error kind, but only if they can all be reasonably fixed in a single commit).

The key concern of the developers here is probably this:
a) there is no doubt that getting issues detected and fixed would be a helpful contribution, but
b) the amount of false positives makes it unattractive to actually run the tool yourself.

If you do not want to volunteer, this is fine as well. Just don't feel sad if the issue gets closed with no action.

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

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

From report at bugs.python.org  Thu Aug  1 14:16:31 2013
From: report at bugs.python.org (Laurent Fournier)
Date: Thu, 01 Aug 2013 12:16:31 +0000
Subject: [issue18613] wrong float plus/minus op result
In-Reply-To: <1375358511.45.0.0761593009905.issue18613@psf.upfronthosting.co.za>
Message-ID: <1375359391.0.0.800896436484.issue18613@psf.upfronthosting.co.za>


Laurent Fournier added the comment:

also with addition !

print (.05+.01)
0.0600000000000000005

----------
title: wrong float minus op result -> wrong float plus/minus op result

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

From report at bugs.python.org  Thu Aug  1 14:19:38 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Aug 2013 12:19:38 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za>
Message-ID: <1375359578.69.0.338177002419.issue18472@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Changes in version 5:

- added a new reference pointing back to this tracker issue. I figure that's a good precedent to set for future updates.
- I liked Barry's point about "Don't break backwards compatility" enough that I moved it into its own paragraph ahead of the bulleted list and changed the heading to "Some other good..."
- changed a few more cases of "rule" to "guideline"
- tabs vs spaces section now strongly prefers spaces, saying tabs should be used only for legacy compatibility reasons
- changed the line length recommendation to allow up to 99 characters when it improves readability (I kept 79 as the default recommendation, and 72 for reflowing long blocks of text)
- rewrapped my additions to the PEP at 72 chars ;)
- encodings section no longer mentions Latin-1, referring only to UTF-8, ASCII and non-ASCII.
- class based exception note changed to a recommendation to inherit from Exception (this ended up leading quite well into the comment about inheritance heirarchy design)
- we already had an admonition to avoid bare except clauses (as well as "except BaseException:")
- dropped the "highly" from the annotation decorator recommendation
- added a note that the public/internal API guideline still applies when using a wildcard import to republish APIs, as well as noting you should only use them when you don't know the list of republished names in advance

I *didn't* make any changes in relation to Barry's comment about having the commentary intermixed with the guidelines. I quite like the notion of stripping PEP 8 down to just the essentials and having PEP 108 as "The annotated PEP 8", but that's a bigger project than I'm prepared to tackle (heck, even the *current* patch turned out to be a far more substantial update than I expected!).

I'll commit this version - feel free to tweak further in the PEP repo if you spot any mistakes :)

I deliberately left the following point out since Guido said "out of scope" above (I wrote it before noticing that):

- Use an iterator or a "loop-and-a-half" construct rather than
  repeating loop setup code in the body of the loop.

  Yes::

    def itervalues(x):
        yield x.getvalue()

    for value in itervalues(obj):
        process(value)

  Yes::

    while True:
        value = obj.getvalue()
        if not value:
            break
        process(value)

  No::

    value = obj.getvalue()
    while value:
        process(value)
        value = obj.getvalue()

----------
Added file: http://bugs.python.org/file31109/issue18472_pep_8_update5.diff

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

From report at bugs.python.org  Thu Aug  1 14:23:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 12:23:41 +0000
Subject: [issue18214] Stop purging modules which are garbage collected before
	shutdown
In-Reply-To: <1371221979.53.0.00385452158182.issue18214@psf.upfronthosting.co.za>
Message-ID: <1375359821.13.0.0215219004833.issue18214@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here (Linux) I get the following:

# purge/gc os.path 12
# purge/gc operator 50
# purge/gc io 49
# purge/gc _sysconfigdata 48
# purge/gc sysconfig 47
# purge/gc keyword 46
# purge/gc site 45
# purge/gc types 44

Also, do note that purge/gc after wiping can still be a regular gc pass unless the module has been wiped. The gc could be triggered by another module being wiped.

----------

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

From report at bugs.python.org  Thu Aug  1 14:24:47 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Aug 2013 12:24:47 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za>
Message-ID: <1375359887.08.0.408210107693.issue18472@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

For the record, the thread where Thomas Wouters provided the feedback that led to the current wording regarding imports: http://mail.python.org/pipermail/python-dev/2013-July/127373.html

----------

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

From report at bugs.python.org  Thu Aug  1 14:37:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Aug 2013 12:37:22 +0000
Subject: [issue18612] More elaborate documentation on how list comprehensions
	and generator expressions relate to each other
In-Reply-To: <1375356212.93.0.797789110077.issue18612@psf.upfronthosting.co.za>
Message-ID: <1375360642.97.0.509501336354.issue18612@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, you haven't done anything wrong, but I'm not sure what we can do in response to the report.  What how will the answer to the question serve you?  What will you know after getting the answer that you didn't know before getting the answer?  I'm trying here to understand what it is that is missing from your mental model of Python that needs to be filled in, because the syntax and behavior of these constructs is documented, and it has never occurred to me to wonder whether or not a generator expression "is" a comprehension or not.

I'm making things up here, but I suspect we call generator expressions that because while they share the base syntax and much of the same semantics as the things we call comprehensions, (a) they produce an iterable (a generator object) instead instead of a fully realized object and (b) you can specify a generator expression without explicit surrounding punctuation (eg: "myfunc(x for x in range(7))").  That is, the 'comprehensions' are conceptually a notation for "specifying" a collection object using a compact notation, while a generator expression is a way of "creating" a generator-iterable *function* that must then be iterated to produce the collection object implicitly specified by the expression.  I'm not sure I'm being clear, because the distinction is subtle and perhaps not meaningful...the difference in naming might just be an historical accident :)

And, because it is not entirely clear, I'm not sure it is a good idea to try to document it.  Again, what enlightenment would derive from a clear explanation?

----------
nosy: +r.david.murray
versions: +Python 2.7, Python 3.3, Python 3.4 -Python 3.5

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

From report at bugs.python.org  Thu Aug  1 14:42:34 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 01 Aug 2013 12:42:34 +0000
Subject: [issue12645] test.support. import_fresh_module - incorrect doc
In-Reply-To: <1311789815.76.0.639942891335.issue12645@psf.upfronthosting.co.za>
Message-ID: <1375360954.84.0.771246589439.issue12645@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Ben, would you like to provide an updated patch?

----------

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

From report at bugs.python.org  Thu Aug  1 14:44:52 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 01 Aug 2013 12:44:52 +0000
Subject: [issue3591] elementtree tests do not include bytes handling
In-Reply-To: <1219078669.04.0.473516144349.issue3591@psf.upfronthosting.co.za>
Message-ID: <1375361092.29.0.300392747744.issue3591@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Quite a bit of encoding-related tests were added recently (by Serhiy, IIRC). Unless there are objections or more specific test suggestions, I will close this issue in a few days.

----------

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

From report at bugs.python.org  Thu Aug  1 14:48:51 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 01 Aug 2013 12:48:51 +0000
Subject: [issue18613] wrong float plus/minus op result
In-Reply-To: <1375358511.45.0.0761593009905.issue18613@psf.upfronthosting.co.za>
Message-ID: <1375361331.99.0.801693019965.issue18613@psf.upfronthosting.co.za>


Brett Cannon added the comment:

This is actually expected because that is just how floating point works in programming (see http://en.wikipedia.org/wiki/Floating_point for all the gnarly details).

If you want exact decimal arithmetic, use the decimal module (which got significantly faster in Python 3.3)::

>>> import decimal
>>> decimal.Decimal('.3') - decimal.Decimal('.1')
Decimal('0.2')
>>> decimal.Decimal('.05') + decimal.Decimal('.01')
Decimal('0.06')

----------
nosy: +brett.cannon
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Thu Aug  1 14:48:57 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 01 Aug 2013 12:48:57 +0000
Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular
	encoding
In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za>
Message-ID: <1375361337.0.0.704639930477.issue13612@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Serhiy, do you want to backport the buffer overflow fix to 2.7?

----------

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

From report at bugs.python.org  Thu Aug  1 14:54:50 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 01 Aug 2013 12:54:50 +0000
Subject: [issue17372] provide pretty printer for xml.etree.ElementTree
In-Reply-To: <1362640725.41.0.836381435016.issue17372@psf.upfronthosting.co.za>
Message-ID: <1375361690.15.0.227137542864.issue17372@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Thanks for the report (Eric) and the patch (Alex). There are currently some open bugs we need to handle first, so this is somewhat lower priority. I hope to get to it before the 3.4 release.

----------

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

From report at bugs.python.org  Thu Aug  1 14:55:00 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Aug 2013 12:55:00 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za>
Message-ID: <1375361700.89.0.527525158552.issue18472@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


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

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

From report at bugs.python.org  Thu Aug  1 14:59:13 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Aug 2013 12:59:13 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za>
Message-ID: <1375361953.8.0.480727275758.issue18472@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Heh, I just realised a correct generator definition would have needed the loop-and-a-half internally anyway:

    def itervalues(x):
        while True:
          value = x.getvalue()
          if not value:
              break
          yield value

----------

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

From report at bugs.python.org  Thu Aug  1 15:00:44 2013
From: report at bugs.python.org (uglemat)
Date: Thu, 01 Aug 2013 13:00:44 +0000
Subject: [issue18612] More elaborate documentation on how list comprehensions
	and generator expressions relate to each other
In-Reply-To: <1375356212.93.0.797789110077.issue18612@psf.upfronthosting.co.za>
Message-ID: <1375362044.65.0.916069751782.issue18612@psf.upfronthosting.co.za>


uglemat added the comment:

Yeah I think the differences are pretty easy to comprehend. To be honest the reason I came here is that I had an argument where someone commented on my code (where I used a generator expression) saying something akin to "list comprehensions are nice", so I replied "actually, that's a generator expression, which are very similar but behave differently". The response was that the two concepts are one and the same. I couldn't really say that that's incorrect, but I think it's very confusing for beginners if people are talking about generator expressions like they are list expressions because they behave so differently and the documentation for list comprehensions doesn't mention generator expressions. I was kind of longing for a definite answer so I could say "Nay, thou shall differentiate between list comprehensions and generator expressions". Is it right to correct someone and say that generator expressions are in fact *not* generator expressions? Maybe I'm blowing this out of proportions. :)

----------
versions: +Python 3.5 -Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Aug  1 15:03:35 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Aug 2013 13:03:35 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>
Message-ID: <3c5WsL5C8sz7Lkd@mail.python.org>


Roundup Robot added the comment:

New changeset 5258c4399f2e by Tim Golden in branch 'default':
issue9035: Prevent Windows-specific tests from running on non-Windows platforms
http://hg.python.org/cpython/rev/5258c4399f2e

----------

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

From report at bugs.python.org  Thu Aug  1 15:03:46 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 01 Aug 2013 13:03:46 +0000
Subject: [issue18214] Stop purging modules which are garbage collected before
	shutdown
In-Reply-To: <1375359821.13.0.0215219004833.issue18214@psf.upfronthosting.co.za>
Message-ID: <51FA5CA9.2080407@gmail.com>


Richard Oudkerk added the comment:

> Also, do note that purge/gc after wiping can still be a regular
> gc pass unless the module has been wiped. The gc could be triggered
> by another module being wiped.

For me, the modules which die naturally after purging begins are

# purge/gc encodings.aliases 34
# purge/gc _io 14
# purge/gc collections.abc 13
# purge/gc sre_compile 12
# purge/gc heapq 11
# purge/gc sre_constants 10
# purge/gc _weakrefset 9
# purge/gc reprlib 8
# purge/gc weakref 7
# purge/gc site 6
# purge/gc abc 5
# purge/gc encodings.latin_1 4
# purge/gc encodings.utf_8 3
# purge/gc genericpath 2

Of these, all but the first appear to happen during the final cyclic 
garbage collection.

----------

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

From report at bugs.python.org  Thu Aug  1 15:05:17 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Aug 2013 13:05:17 +0000
Subject: [issue10434] Document the rules for "public names"
In-Reply-To: <1289919338.9.0.394057770971.issue10434@psf.upfronthosting.co.za>
Message-ID: <1375362317.81.0.560638431698.issue10434@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

PEP 8 now covers the developer side of things: http://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces

A user facing counterpart describing our backwards compatibility policy is still desirable. Updating PEP 5 wouldn't go astray, since that's *supposed* to serve that purpose :)

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Thu Aug  1 15:05:31 2013
From: report at bugs.python.org (uglemat)
Date: Thu, 01 Aug 2013 13:05:31 +0000
Subject: [issue18612] More elaborate documentation on how list comprehensions
	and generator expressions relate to each other
In-Reply-To: <1375356212.93.0.797789110077.issue18612@psf.upfronthosting.co.za>
Message-ID: <1375362331.76.0.275902634818.issue18612@psf.upfronthosting.co.za>


uglemat added the comment:

> Is it right to correct someone and say that generator expressions are in fact *not* generator expressions?

Ups, I meant "Is it right to correct someone and say that generator expressions are in fact *not* list comprehensions?"

All these expressions and comprehensions are making me dissy :)

----------

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

From report at bugs.python.org  Thu Aug  1 15:12:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 13:12:15 +0000
Subject: [issue18214] Stop purging modules which are garbage collected before
	shutdown
In-Reply-To: <1371221979.53.0.00385452158182.issue18214@psf.upfronthosting.co.za>
Message-ID: <1375362735.69.0.489638925149.issue18214@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Also, do note that purge/gc after wiping can still be a regular gc
> pass unless the module has been wiped. The gc could be triggered by
> another module being wiped.

That said, I welcome any suggestions to improve things. The ultimate
reasons we need to purge some modules are the same two reasons I
indicated on python-dev: C extension modules are almost immortal;
and some C code keeps references alive too long.

Do you agree that this patch is ok and we should address those two
problems in separate new issues?

----------

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

From report at bugs.python.org  Thu Aug  1 15:12:29 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 01 Aug 2013 13:12:29 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1375359578.69.0.338177002419.issue18472@psf.upfronthosting.co.za>
Message-ID: <20130801091230.7b13c883@anarchist>


Barry A. Warsaw added the comment:

On Aug 01, 2013, at 12:19 PM, Nick Coghlan wrote:

>I *didn't* make any changes in relation to Barry's comment about having the
>commentary intermixed with the guidelines. I quite like the notion of
>stripping PEP 8 down to just the essentials and having PEP 108 as "The
>annotated PEP 8", but that's a bigger project than I'm prepared to tackle
>(heck, even the *current* patch turned out to be a far more substantial
>update than I expected!).

You've done great work on a substantial undertaking!  Thanks. :)

----------

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

From report at bugs.python.org  Thu Aug  1 15:20:28 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Aug 2013 13:20:28 +0000
Subject: [issue18612] More elaborate documentation on how list comprehensions
	and generator expressions relate to each other
In-Reply-To: <1375356212.93.0.797789110077.issue18612@psf.upfronthosting.co.za>
Message-ID: <1375363228.87.0.646528199026.issue18612@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, it is the case that if you substitute a list comprehension for a generator expression in arbitrary code, most of the time it would work but occasionally it wouldn't, because the runtime behavior is different (lazy production versus all-at-once production).  So yes, the two are not the same thing, and it is important to understand the differences in behavior between them.  Calling a generator expression a list comprehension indicates someone's mental model of how Python works has a couple holes in it, IMO :)

----------

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

From report at bugs.python.org  Thu Aug  1 15:30:02 2013
From: report at bugs.python.org (DLowell)
Date: Thu, 01 Aug 2013 13:30:02 +0000
Subject: [issue14130] memoryview: add multi-dimensional indexing and slicing
In-Reply-To: <1330259007.41.0.197339877072.issue14130@psf.upfronthosting.co.za>
Message-ID: <1375363802.02.0.184353061124.issue14130@psf.upfronthosting.co.za>


DLowell added the comment:

Is this issue still being worked on?

----------
nosy: +DLowell

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

From report at bugs.python.org  Thu Aug  1 15:32:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Aug 2013 13:32:59 +0000
Subject: [issue18257] Two copies of python-config
In-Reply-To: <1371567872.42.0.116049773773.issue18257@psf.upfronthosting.co.za>
Message-ID: <3c5XWG69K7zPqh@mail.python.org>


Roundup Robot added the comment:

New changeset 7b165c7ab7ef by doko in branch 'default':
- Issue #18257: Fix readlink usage in python-config.  Install the python
http://hg.python.org/cpython/rev/7b165c7ab7ef

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Aug  1 15:35:25 2013
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 01 Aug 2013 13:35:25 +0000
Subject: [issue18257] Two copies of python-config
In-Reply-To: <1371567872.42.0.116049773773.issue18257@psf.upfronthosting.co.za>
Message-ID: <1375364125.12.0.38426165.issue18257@psf.upfronthosting.co.za>


Matthias Klose added the comment:

checked in a fix for the readlink issue, and Ronald's proposed solution for Darwin.  And documented for now, that we do have two versions of this script.  This works as long as you don't cross-build for Darwin or on Darwin.

----------

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

From report at bugs.python.org  Thu Aug  1 15:54:05 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 01 Aug 2013 13:54:05 +0000
Subject: [issue18614] Enhanced \N{} escapes for Unicode strings
Message-ID: <1375365245.12.0.441428484785.issue18614@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

As per the discussion here:

http://mail.python.org/pipermail/python-ideas/2013-July/022419.html

\N{} escapes should support the Unicode code point notation U+xxxx (where there are four, five or six hex digits after the U+).

E.g. '\N{U+03BB}' => '?'

unicodedata.lookup should also support such numeric names, e.g.:

unicodedata.lookup('U+03BB') => '?'

As '+' is otherwise prohibited in Unicode character names, there should never be ambiguity between 'U+xxxx' as a code point and an actual name, and a single lookup function can handle both.

(See http://www.unicode.org/versions/Unicode6.2.0/ch04.pdf#G39 for details on characters allowed in names.)


Also add a function for the reverse

unicodedata.codepoint('?') => 'U+03BB'


def codepoint(c):
    return 'U+{:04X}'.format(ord(c))

----------
components: Unicode
messages: 194075
nosy: ezio.melotti, stevenjd
priority: normal
severity: normal
status: open
title: Enhanced \N{} escapes for Unicode strings
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug  1 16:14:55 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 01 Aug 2013 14:14:55 +0000
Subject: [issue18214] Stop purging modules which are garbage collected before
	shutdown
In-Reply-To: <1375362735.69.0.489638925149.issue18214@psf.upfronthosting.co.za>
Message-ID: <51FA6D57.8070101@gmail.com>


Richard Oudkerk added the comment:

Yes, I agree the patch is ok.

It would be would be much simpler to keep track of the module dicts if 
they were weakrefable.  Alternatively, at shutdown a weakrefable object 
with a reference to the module dict could be inserted in to each module 
dict.  We could then use those to find orphaned module dicts.  But I 
doubt it is worth the extra effort.

----------

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

From report at bugs.python.org  Thu Aug  1 17:02:40 2013
From: report at bugs.python.org (Tim Golden)
Date: Thu, 01 Aug 2013 15:02:40 +0000
Subject: [issue9035] os.path.ismount on windows doesn't support windows
	mount	points
In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>
Message-ID: <1375369360.66.0.688170660483.issue9035@psf.upfronthosting.co.za>


Tim Golden added the comment:

Fixed. Thanks for the patch

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

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

From report at bugs.python.org  Thu Aug  1 17:03:36 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 01 Aug 2013 15:03:36 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <20130801091230.7b13c883@anarchist>
Message-ID: <CAP7+vJL1dN4UzEF_iTwzTmzrNodOwUoVxK+A+etwSqB+heJZPg@mail.gmail.com>


Guido van Rossum added the comment:

Thanks a bundle, Nick!

----------

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

From report at bugs.python.org  Thu Aug  1 17:14:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 15:14:06 +0000
Subject: [issue18214] Stop purging modules which are garbage collected before
	shutdown
In-Reply-To: <1371221979.53.0.00385452158182.issue18214@psf.upfronthosting.co.za>
Message-ID: <1375370046.78.0.645712211442.issue18214@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, let's attack the rest separately then :)
And thanks a lot for testing!

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

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

From report at bugs.python.org  Thu Aug  1 17:17:55 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Thu, 01 Aug 2013 15:17:55 +0000
Subject: [issue18615] sndhdr.whathdr could return a namedtuple
Message-ID: <1375370275.79.0.808837089288.issue18615@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Both sndhdr.whathdr an sndhdr.what returns a tuple with various information, while it could return a namedtuple. I attached a patched for this, with tests as well.

----------
components: Library (Lib)
files: sndhdr.patch
keywords: patch
messages: 194080
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: sndhdr.whathdr could return a namedtuple
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31110/sndhdr.patch

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

From report at bugs.python.org  Thu Aug  1 17:42:50 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Aug 2013 15:42:50 +0000
Subject: [issue16111] Python 2.7.3 Windows MSI installer installs the VC++ 9
	dlls directly to WinSxS folder
In-Reply-To: <1349201780.49.0.563700308951.issue16111@psf.upfronthosting.co.za>
Message-ID: <1375371770.74.0.0531211757687.issue16111@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

This is not true. Installing the modules into the SxS folder using the Merge Module (msm) is also a recommended way of installing the DLLs.

I fail to see a problem in this report.

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

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

From report at bugs.python.org  Thu Aug  1 17:44:14 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Aug 2013 15:44:14 +0000
Subject: [issue3778] python uninstaller leave registry entries
In-Reply-To: <1220562494.43.0.987039023455.issue3778@psf.upfronthosting.co.za>
Message-ID: <1375371854.11.0.672860648349.issue3778@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Nobody has contributed a patch in five years, so it apparently is pretty hard.

----------

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

From report at bugs.python.org  Thu Aug  1 17:56:02 2013
From: report at bugs.python.org (Derek Wilson)
Date: Thu, 01 Aug 2013 15:56:02 +0000
Subject: [issue18616] enable more ssl socket options with
	get_server_certificate
Message-ID: <1375372562.92.0.356754094449.issue18616@psf.upfronthosting.co.za>


New submission from Derek Wilson:

ssl.get_server_certificate does not allow advanced options like what ciphers to use (for ssl2 for instance) or SNI for virtual hosts with multiple ssl sites on one IP address.

Adding **kwargs enables any current and future SSLSocket options to be passed along to the underlying connection. wrap_socket doesn't include all the options (npn and sni for instance), so I use SSLSocket instead.

----------
components: Extension Modules
files: ssl_get_server_certificate_kwargs.patch
keywords: patch
messages: 194083
nosy: underrun
priority: normal
severity: normal
status: open
title: enable more ssl socket options with get_server_certificate
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31111/ssl_get_server_certificate_kwargs.patch

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

From report at bugs.python.org  Thu Aug  1 18:31:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Aug 2013 16:31:30 +0000
Subject: [issue18569] Set PATHEXT in the Windows installer
In-Reply-To: <1374912463.83.0.476685307572.issue18569@psf.upfronthosting.co.za>
Message-ID: <3c5cTF27Cvz7Lkn@mail.python.org>


Roundup Robot added the comment:

New changeset 2a38e4da6ce8 by Martin v. L?wis in branch 'default':
Issue #18569: The installer now adds .py to the PATHEXT variable
http://hg.python.org/cpython/rev/2a38e4da6ce8

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Aug  1 18:32:43 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Aug 2013 16:32:43 +0000
Subject: [issue18569] Set PATHEXT in the Windows installer
In-Reply-To: <1374912463.83.0.476685307572.issue18569@psf.upfronthosting.co.za>
Message-ID: <1375374763.11.0.336099169989.issue18569@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Thanks for the patch. It works fine (with the expected limitation that you need to restart running shells for this to take effect).

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

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

From report at bugs.python.org  Thu Aug  1 18:45:06 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 01 Aug 2013 16:45:06 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za>
Message-ID: <1375375506.16.0.964446779363.issue18472@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I think the current wording about line length makes it too easy to adopt 99 instead of 79.  I propose to go back to 79 only, and add this before the paragraph starting with "The preferred way of wrapping long lines ..."

"""
Some teams strongly prefer a longer line length.  For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the line nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters.
"""

----------

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

From report at bugs.python.org  Thu Aug  1 18:46:11 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 01 Aug 2013 16:46:11 +0000
Subject: [issue18614] Enhanced \N{} escapes for Unicode strings
In-Reply-To: <1375365245.12.0.441428484785.issue18614@psf.upfronthosting.co.za>
Message-ID: <1375375571.12.0.559855334061.issue18614@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

I've attached a patch for this.

----------
keywords: +patch
nosy: +mrabarnett
Added file: http://bugs.python.org/file31112/issue18614.patch

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

From report at bugs.python.org  Thu Aug  1 18:58:38 2013
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 01 Aug 2013 16:58:38 +0000
Subject: [issue18617] TLS and Intermediate Certificates
Message-ID: <1375376317.99.0.429350247521.issue18617@psf.upfronthosting.co.za>


New submission from Donald Stufft:

Currently the Python SSL module requires the full chain, including all intermediaries, to be served in order to validate a TLS connection. This isn't *wrong* however a number of folks have had issues trying to setup a custom PyPI index in pip due to missing them. The believed the problem with validation to be in pip/Python because it works in their browser.

Essentially browsers have the ability to download missing intermediate certs using an url found inside the AIA data. This is slow and isn't generally recommended that you rely on it for any particular site. However it does mean that TLS connections work in more situations.

At the least this should probably be documented, and possibly the Python library be enhanced to be more browser like in this regard.

----------
components: Library (Lib)
messages: 194088
nosy: dstufft
priority: normal
severity: normal
status: open
title: TLS and Intermediate Certificates
type: enhancement

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

From report at bugs.python.org  Thu Aug  1 19:00:56 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 01 Aug 2013 17:00:56 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za>
Message-ID: <1375376456.21.0.641644474143.issue18472@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

See proposed patch at https://codereview.appspot.com/12269044/ .

----------

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

From report at bugs.python.org  Thu Aug  1 19:09:05 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 01 Aug 2013 17:09:05 +0000
Subject: [issue18617] TLS and Intermediate Certificates
In-Reply-To: <1375376317.99.0.429350247521.issue18617@psf.upfronthosting.co.za>
Message-ID: <1375376945.26.0.000835466375547.issue18617@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thx!

Let's update the docs for 2.7 to 3.4 first. 

For AIA intermediate cert retrieval we have to use OpenSSL's verify hook. It's a pain to implement all necessary bits and hard to use, though. :(

----------
nosy: +christian.heimes
versions: +Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Aug  1 19:31:28 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 01 Aug 2013 17:31:28 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1375378288.18.0.687807032585.issue16248@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

The fix in 2.6, 2.7, 3.1 and 3.2 branches introduced UnboundLocalError occurring when a non-None baseName parameter is passed.
At least a part of fa82071bb7e1 should be backported to 2.6, 2.7, 3.1 and 3.2 branches.

$ python2.7 -c 'import Tkinter; print(repr(Tkinter.Tk(baseName="some_name")))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python2.7/lib-tk/Tkinter.py", line 1748, in __init__
    if not sys.flags.ignore_environment:
UnboundLocalError: local variable 'sys' referenced before assignment
$ python3.2 -c 'import tkinter; print(repr(tkinter.Tk(baseName="some_name")))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.2/tkinter/__init__.py", line 1734, in __init__
    if not sys.flags.ignore_environment:
UnboundLocalError: local variable 'sys' referenced before assignment

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

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

From report at bugs.python.org  Thu Aug  1 19:41:18 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 01 Aug 2013 17:41:18 +0000
Subject: [issue18517] "xxlimited" extension declared incorrectly in setup.py
In-Reply-To: <1374393760.41.0.977042124577.issue18517@psf.upfronthosting.co.za>
Message-ID: <1375378878.36.0.355284029686.issue18517@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


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

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

From report at bugs.python.org  Thu Aug  1 19:47:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 17:47:43 +0000
Subject: [issue18618] Need an atexit.register equivalent that also works in
	subinterps
Message-ID: <1375379263.55.0.273685957163.issue18618@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Callbacks registered with atexit.register() are only called at shutdown of the main interpreter. For some purposes (perhaps most of them, arguably), you actually want to execute the callbacks at subinterpreter shutdown too.

----------
messages: 194092
nosy: pitrou, sbt
priority: normal
severity: normal
status: open
title: Need an atexit.register equivalent that also works in subinterps

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

From report at bugs.python.org  Thu Aug  1 19:47:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 17:47:58 +0000
Subject: [issue18618] Need an atexit.register equivalent that also works in
	subinterps
In-Reply-To: <1375379263.55.0.273685957163.issue18618@psf.upfronthosting.co.za>
Message-ID: <1375379278.08.0.128705658783.issue18618@psf.upfronthosting.co.za>


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


----------
components: +Interpreter Core, Library (Lib)
priority: normal -> low
type:  -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Thu Aug  1 20:01:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 18:01:02 +0000
Subject: [issue18618] Need an atexit.register equivalent that also works in
	subinterps
In-Reply-To: <1375379263.55.0.273685957163.issue18618@psf.upfronthosting.co.za>
Message-ID: <1375380062.88.0.0658141371217.issue18618@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(note that weakref.finalize indirectly suffers from this problem)

----------

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

From report at bugs.python.org  Thu Aug  1 20:03:55 2013
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 01 Aug 2013 18:03:55 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1375380235.14.0.035243219761.issue16248@psf.upfronthosting.co.za>


Larry Hastings added the comment:

You're talking about a new bug.  Please open a new issue.

I'm closing this issue right now because I want to cut a Python 3.4 alpha release tomorrow, and this bug is marked Python 3.4 and "release blocker".

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

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

From report at bugs.python.org  Thu Aug  1 20:06:04 2013
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 01 Aug 2013 18:06:04 +0000
Subject: [issue17998] internal error in regular expression engine
In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za>
Message-ID: <1375380364.95.0.738353862845.issue17998@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I'm downgrading this to "deferred blocker".  I'm sure we'll get it fixed for Python 3.4 final, but in the meantime there's no sense in holding up Python 3.4a1 for it.

----------
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Thu Aug  1 20:08:18 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 01 Aug 2013 18:08:18 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1375380498.13.0.246213299662.issue16248@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

UnboundLocalError is effect of partially incorrect fix for this bug.
It is better to update Versions field.

----------
resolution: fixed -> 
status: closed -> open
versions: +Python 3.1 -Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Aug  1 20:08:55 2013
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 01 Aug 2013 18:08:55 +0000
Subject: [issue18257] Two copies of python-config
In-Reply-To: <1371567872.42.0.116049773773.issue18257@psf.upfronthosting.co.za>
Message-ID: <1375380535.39.0.436473255007.issue18257@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Thanks, Matthias!  Now I can cut 3.4a1 on time.  :)

----------

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

From report at bugs.python.org  Thu Aug  1 20:14:12 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 01 Aug 2013 18:14:12 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za>
Message-ID: <1375380852.51.0.0632244943243.issue18472@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

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

From report at bugs.python.org  Thu Aug  1 20:20:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 18:20:15 +0000
Subject: [issue18619] atexit leaks callbacks in subinterpreters
Message-ID: <1375381215.71.0.728082521631.issue18619@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

atexit uses PEP 3121 module initialization, and by this scheme each subinterpreter gets a separate module state. However, atexit's m_free doesn't actually decref the callbacks: it only frees the callbacks array, thinking the callbacks were already decref'ed when run. This is ok at main interpreter shutdown, but not at subinterpreter shutdown (see issue 18618).

----------
components: Interpreter Core, Library (Lib)
messages: 194098
nosy: Robin.Schreiber, pitrou, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: atexit leaks callbacks in subinterpreters
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug  1 20:23:49 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 01 Aug 2013 18:23:49 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za>
Message-ID: <1375381429.96.0.0494241993953.issue18472@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe added the comment:

@Guido am glad for the patch; it's a nice compromise

----------

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

From report at bugs.python.org  Thu Aug  1 20:47:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 18:47:23 +0000
Subject: [issue18619] atexit leaks callbacks in subinterpreters
In-Reply-To: <1375381215.71.0.728082521631.issue18619@psf.upfronthosting.co.za>
Message-ID: <1375382843.42.0.579747708265.issue18619@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch. It also enables GC on the atexit module.

----------
keywords: +patch
Added file: http://bugs.python.org/file31113/atexit_leaks.patch

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

From report at bugs.python.org  Thu Aug  1 20:56:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Aug 2013 18:56:20 +0000
Subject: [issue18619] atexit leaks callbacks in subinterpreters
In-Reply-To: <1375381215.71.0.728082521631.issue18619@psf.upfronthosting.co.za>
Message-ID: <3c5ghN11v3z7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 71b63a32b1e3 by Antoine Pitrou in branch 'default':
Issue #18619: Fix atexit leaking callbacks registered from sub-interpreters, and make it GC-aware.
http://hg.python.org/cpython/rev/71b63a32b1e3

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Aug  1 20:57:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 18:57:05 +0000
Subject: [issue18619] atexit leaks callbacks in subinterpreters
In-Reply-To: <1375381215.71.0.728082521631.issue18619@psf.upfronthosting.co.za>
Message-ID: <1375383425.29.0.132145507737.issue18619@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The patch was simple enough that I decided to push it as-is :)
Don't hesitate to make comments if you want, though.

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

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

From report at bugs.python.org  Thu Aug  1 21:05:17 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Aug 2013 19:05:17 +0000
Subject: [issue18608] Avoid keeping a strong reference to locale in the _io
	module
In-Reply-To: <1375305631.67.0.684843179592.issue18608@psf.upfronthosting.co.za>
Message-ID: <3c5gth6Ytjz7Ll1@mail.python.org>


Roundup Robot added the comment:

New changeset 1c9aa4f68f2b by Antoine Pitrou in branch 'default':
Issue #18608: Avoid keeping a strong reference to the locale module inside the _io module.
http://hg.python.org/cpython/rev/1c9aa4f68f2b

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Aug  1 21:05:24 2013
From: report at bugs.python.org (Stephen Paul Chappell)
Date: Thu, 01 Aug 2013 19:05:24 +0000
Subject: [issue18558] Iterable glossary entry needs clarification
In-Reply-To: <1374796651.89.0.668716719647.issue18558@psf.upfronthosting.co.za>
Message-ID: <1375383924.01.0.00621420986944.issue18558@psf.upfronthosting.co.za>


Stephen Paul Chappell added the comment:

If my program needed to know if an object is iterable, it would be tempting to define and call the following function instead of using collections.abc.Iterable:

    def iterable(obj):
        try:
            iter(obj)
        except TypeError:
            return False
        return True

Something tells me that is not what the author of collections.abc.Iterable intended.

----------

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

From report at bugs.python.org  Thu Aug  1 21:05:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 19:05:47 +0000
Subject: [issue18608] Avoid keeping a strong reference to locale in the _io
	module
In-Reply-To: <1375305631.67.0.684843179592.issue18608@psf.upfronthosting.co.za>
Message-ID: <1375383947.1.0.987923623438.issue18608@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks Brett for reviewing. This is now pushed.

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

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

From report at bugs.python.org  Thu Aug  1 21:14:54 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Aug 2013 19:14:54 +0000
Subject: [issue18589] cross-referencing doesn't work between the extending
	guide and c-api
In-Reply-To: <1375122124.66.0.67649436332.issue18589@psf.upfronthosting.co.za>
Message-ID: <3c5h5n4G35z7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset a381721299a3 by Antoine Pitrou in branch '3.3':
Issue #18589: fix hyperlinking of type slots (tp_*)
http://hg.python.org/cpython/rev/a381721299a3

New changeset 36ff479e429c by Antoine Pitrou in branch 'default':
Issue #18589: fix hyperlinking of type slots (tp_*)
http://hg.python.org/cpython/rev/36ff479e429c

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Aug  1 21:17:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Aug 2013 19:17:32 +0000
Subject: [issue18589] cross-referencing doesn't work between the extending
	guide and c-api
In-Reply-To: <1375122124.66.0.67649436332.issue18589@psf.upfronthosting.co.za>
Message-ID: <3c5h8q6c5xz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset bb546f6d8ab4 by Antoine Pitrou in branch '2.7':
Issue #18589: fix hyperlinking of type slots (tp_*)
http://hg.python.org/cpython/rev/bb546f6d8ab4

----------

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

From report at bugs.python.org  Thu Aug  1 21:17:52 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 19:17:52 +0000
Subject: [issue18589] cross-referencing doesn't work between the extending
	guide and c-api
In-Reply-To: <1375122124.66.0.67649436332.issue18589@psf.upfronthosting.co.za>
Message-ID: <1375384672.2.0.200283013599.issue18589@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Aug  1 21:54:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 19:54:02 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <1375386842.25.0.82519149348.issue10241@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, the patch doesn't apply cleanly but looks good regardless.
(although I wonder whether you really reclaim significant stuff here: most C extension dicts should be mostly references to C methods and types)

----------
assignee: loewis -> 
nosy: +pitrou
type: behavior -> resource usage
versions: +Python 3.4

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

From report at bugs.python.org  Thu Aug  1 22:06:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 20:06:02 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <1375387562.76.0.308525813578.issue10241@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I will still empty modules_by_index rather than Py_CLEAR it, though.

----------

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

From report at bugs.python.org  Thu Aug  1 22:07:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Aug 2013 20:07:15 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <3c5jGB3hcsz7LjV@mail.python.org>


Roundup Robot added the comment:

New changeset 62658d9d8926 by Antoine Pitrou in branch 'default':
Issue #10241: Clear extension module dict copies at interpreter shutdown.
http://hg.python.org/cpython/rev/62658d9d8926

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Aug  1 22:07:49 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 20:07:49 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <1375387669.07.0.736852818983.issue10241@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Aug  1 22:12:44 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 20:12:44 +0000
Subject: [issue18214] Stop purging modules which are garbage collected before
	shutdown
In-Reply-To: <1371221979.53.0.00385452158182.issue18214@psf.upfronthosting.co.za>
Message-ID: <1375387964.82.0.0258941277841.issue18214@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

By the way, you may be interested to learn that the patch in issue10241 has made things quite a bit better now: C extension modules can be collected much earlier.

----------

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

From report at bugs.python.org  Thu Aug  1 22:25:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Aug 2013 20:25:42 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <3c5jgT3rlcz7LkD@mail.python.org>


Roundup Robot added the comment:

New changeset 0f17aed78168 by Antoine Pitrou in branch '2.7':
Fix tkinter regression introduced by the security fix in #16248.
http://hg.python.org/cpython/rev/0f17aed78168

----------

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

From report at bugs.python.org  Thu Aug  1 22:26:32 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Aug 2013 20:26:32 +0000
Subject: [issue18558] Iterable glossary entry needs clarification
In-Reply-To: <1374796651.89.0.668716719647.issue18558@psf.upfronthosting.co.za>
Message-ID: <1375388792.26.0.533463547564.issue18558@psf.upfronthosting.co.za>


R. David Murray added the comment:

That would give you a false positive, though.  It would return True for the 'y' in my example, which is not iterable.  So Iterable's behavior here is an example of the Python design rule "resist the temptation to guess".

As Terry said, new classes should implement an __iter__ method.  The __getitem__ iteration support is for backward compatibility.

----------

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

From report at bugs.python.org  Thu Aug  1 22:27:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 20:27:07 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1375388827.85.0.531998330436.issue16248@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I've committed a fix to 2.7 (I hope it's really a fix, since I don't know how to test it).
I'll let Benjamin and Barry decide whether to backport to 2.6 and 3.2.
As for 3.1, it's pretty much dead.

----------
priority: release blocker -> deferred blocker
stage:  -> committed/rejected
versions:  -Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Aug  1 22:30:44 2013
From: report at bugs.python.org (Chris Curvey)
Date: Thu, 01 Aug 2013 20:30:44 +0000
Subject: [issue18620] multiprocessing page leaves out important part of Pool
	example
Message-ID: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>


New submission from Chris Curvey:

on http://docs.python.org/2/library/multiprocessing.html, there is a bit about how to use a Pool properly, which looks like this

pool = Pool(processes=4)              # start 4 worker processes
result = pool.apply_async(f, [10])

What this neglects to mention is that only one process will get any of the work.  If you really want four processes in the pool to work, you have to call apply_async four times.  For example:

results = []
pool = Pool(processes=4)
for i in xrange(4):
    results.append(pool.apply_async(f, [10]))

hat tip to http://stackoverflow.com/questions/12483512/python-multiprocessing-apply-async-only-uses-one-process

----------
assignee: docs at python
components: Documentation
messages: 194115
nosy: Chris.Curvey, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing page leaves out important part of Pool example
type: enhancement

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

From report at bugs.python.org  Thu Aug  1 22:40:31 2013
From: report at bugs.python.org (Catalin Iacob)
Date: Thu, 01 Aug 2013 20:40:31 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1375389631.59.0.4510977545.issue1294959@psf.upfronthosting.co.za>


Changes by Catalin Iacob <iacobcatalin at gmail.com>:


----------
nosy: +catalin.iacob

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

From report at bugs.python.org  Thu Aug  1 22:41:45 2013
From: report at bugs.python.org (John Jefferies)
Date: Thu, 01 Aug 2013 20:41:45 +0000
Subject: [issue18306] os.stat gives exception for Windows junctions in v3.3
In-Reply-To: <1375355375.68.0.308421150629.issue18306@psf.upfronthosting.co.za>
Message-ID: <51FAC853.6080805@ntlworld.com>


John Jefferies added the comment:

On 01/08/2013 12:09, Tim Golden wrote:
> Tim Golden added the comment:
>
> I propose to close this one: using Python 3.3 on Win7 I can successfully stat NTFS Junctions. Is there any remaining issue?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue18306>
> _______________________________________

The original issue remains for me on v3.3.2. I can stat junctions in my 
user directory, but not in system directories. In v3.2 I can do that 
provided I am running with elevated privilege. If it's fixed in the next 
version that's great.

------------
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>>
 >>> import os
 >>> os.stat(r'C:\Windows\System32\config\systemprofile\SendTo')
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
FileNotFoundError: [WinError 2] The system cannot find the file 
specified: 'C:\\Windows\\System32\\config\\systemprofile\\SendTo'
 >>>
------------

Regards

John

----------

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

From report at bugs.python.org  Thu Aug  1 22:49:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 20:49:56 +0000
Subject: [issue18621] site.py keeps too much stuff alive when it patches
	builtins
Message-ID: <1375390196.76.0.0867903823381.issue18621@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The site module patches the builtins module unless Python is run with -S. Unfortunately, this means the builtins dict then keeps the site module globals alive until the end of interpreter shutdown, preventing the garbage collection of many other objects or modules.

Attached patch isolates those patched builtins inside a separate module "_sitebuiltins".

----------
components: Library (Lib)
files: sitebuiltins.patch
keywords: patch
messages: 194117
nosy: pitrou, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: site.py keeps too much stuff alive when it patches builtins
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file31114/sitebuiltins.patch

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

From report at bugs.python.org  Thu Aug  1 22:55:41 2013
From: report at bugs.python.org (Catalin Iacob)
Date: Thu, 01 Aug 2013 20:55:41 +0000
Subject: [issue15631] Python 3.3/3.4 installation issue on OpenSUSE lib/lib64
	folders
In-Reply-To: <1344794304.26.0.478120841355.issue15631@psf.upfronthosting.co.za>
Message-ID: <1375390541.98.0.965779742371.issue15631@psf.upfronthosting.co.za>


Catalin Iacob added the comment:

In reply to msg168184, LIBDIR is set to include lib64 instead of lib because openSUSE explicitly does it that way in their multilib implementation.

More specifically, the CONFIG_SITE environment variable is set to /usr/share/site/x86_64-unknown-linux-gnu which contains, among more stuff:

catalin at opensuse:~/hacking/cpython> cat $CONFIG_SITE  | grep libdir
# If user did not specify libdir, guess the correct target:
if test "$libdir" = '${exec_prefix}/lib' ; then
                libdir='${exec_prefix}/lib64'


/usr/share/site/x86_64-unknown-linux-gnu is owned by package site-config whose README says:

site-config: Site Paths Configuration for autoconf Based configure Scripts
==========================================================================

Site configuration for autoconf based configure scripts provides smart
defaults for paths that are not specified.

All autoconf based configure scripts will automatically resource site
script using CONFIG_SITE environment variable. It works without any
explicit user interaction.

Currently implemented features:


Automatic libdir setup to $exec_prefix/lib or $exec_prefix/lib64
----------------------------------------------------------------

Depending on architecture, site script should correctly and
automatically switch between lib and lib64 libdir.


libexecdir setup to $exec_prefix/lib
------------------------------------

Upstream libexecdir defaults to $exec_prefix/libexec. This directory is
not part of FHS 2.2, so we change it to $exec_prefix/lib (yes, it is
correct to set it to $exec_prefix/lib even for bi-arch platforms). Most
projects add package name to this path, so you most probably get what
FHS 2.2 expects.

----------
nosy: +catalin.iacob

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

From report at bugs.python.org  Thu Aug  1 23:04:17 2013
From: report at bugs.python.org (Michael Foord)
Date: Thu, 01 Aug 2013 21:04:17 +0000
Subject: [issue18622] reset_mock on mock created by mock_open causes infinite
	recursion
Message-ID: <1375391057.28.0.108463427813.issue18622@psf.upfronthosting.co.za>


New submission from Michael Foord:

As reported at: http://code.google.com/p/mock/issues/detail?id=209

>>> from unittest import mock
[107971 refs]
>>> mock.mock_open
<function mock_open at 0x10cff9d20>
[107974 refs]
>>> a = mock.mock_open()
[109965 refs]
>>> a.reset_mock()
...

----------
assignee: michael.foord
components: Library (Lib)
keywords: easy
messages: 194119
nosy: michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: reset_mock on mock created by mock_open causes infinite recursion
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Aug  1 23:23:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 21:23:29 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <1375392209.12.0.898502235376.issue10241@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Reopening. This seems to produce segfaults on several of the buildbots, e.g.:
http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/8947
http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%203.x/builds/1257
http://buildbot.python.org/all/builders/x86%20Gentoo%203.x/builds/4671

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

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

From report at bugs.python.org  Thu Aug  1 23:39:39 2013
From: report at bugs.python.org (=?utf-8?q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 01 Aug 2013 21:39:39 +0000
Subject: [issue18605] 2.7: test_threading hangs on Solaris 9
In-Reply-To: <1375254182.2.0.923446047018.issue18605@psf.upfronthosting.co.za>
Message-ID: <1375393179.55.0.844100486853.issue18605@psf.upfronthosting.co.za>


Maciej Blizi?ski added the comment:

Here's the output. After that output -- it hangs.

== CPython 2.7.5 (default, Jul 30 2013, 01:41:03) [GCC 4.6.3]
==   Solaris-2.9-sun4u-sparc-32bit-ELF big-endian
==   /home/maciej/src/opencsw/pkg/lang-python/python/branches/python-2.7/work/solaris9-sparc/build-isa-sparcv8/Python-2.7.5/build/test_python_28299
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
test_threading
test_acquire_contended (test.test_threading.LockTests) ... ok
test_acquire_destroy (test.test_threading.LockTests) ... ok
test_acquire_release (test.test_threading.LockTests) ... ok
test_constructor (test.test_threading.LockTests) ... ok
test_different_thread (test.test_threading.LockTests) ... ok
test_reacquire (test.test_threading.LockTests) ... ok
test_thread_leak (test.test_threading.LockTests) ... ok
test_try_acquire (test.test_threading.LockTests) ... ok
test_try_acquire_contended (test.test_threading.LockTests) ... ok
test_with (test.test_threading.LockTests) ... ok
test__is_owned (test.test_threading.RLockTests) ... ok
test_acquire_contended (test.test_threading.RLockTests) ... ok
test_acquire_destroy (test.test_threading.RLockTests) ... ok
test_acquire_release (test.test_threading.RLockTests) ... ok
test_constructor (test.test_threading.RLockTests) ... ok
test_different_thread (test.test_threading.RLockTests) ... ok
test_reacquire (test.test_threading.RLockTests) ... ok
test_release_unacquired (test.test_threading.RLockTests) ... ok
test_thread_leak (test.test_threading.RLockTests) ... ok
test_try_acquire (test.test_threading.RLockTests) ... ok
test_try_acquire_contended (test.test_threading.RLockTests) ... ok
test_with (test.test_threading.RLockTests) ... ok
test_is_set (test.test_threading.EventTests) ... ok
test_notify (test.test_threading.EventTests) ... ok
test_timeout (test.test_threading.EventTests) ... ok
test__is_owned (test.test_threading.ConditionAsRLockTests) ... ok
test_acquire_contended (test.test_threading.ConditionAsRLockTests) ... ok
test_acquire_destroy (test.test_threading.ConditionAsRLockTests) ... ok
test_acquire_release (test.test_threading.ConditionAsRLockTests) ... ok
test_constructor (test.test_threading.ConditionAsRLockTests) ... ok
test_different_thread (test.test_threading.ConditionAsRLockTests) ... ok
test_reacquire (test.test_threading.ConditionAsRLockTests) ... ok
test_release_unacquired (test.test_threading.ConditionAsRLockTests) ... ok
test_thread_leak (test.test_threading.ConditionAsRLockTests) ... ok
test_try_acquire (test.test_threading.ConditionAsRLockTests) ... ok
test_try_acquire_contended (test.test_threading.ConditionAsRLockTests) ... ok
test_with (test.test_threading.ConditionAsRLockTests) ... ok
test_acquire (test.test_threading.ConditionTests) ... ok
test_notify (test.test_threading.ConditionTests) ... ok
test_timeout (test.test_threading.ConditionTests) ... ok
test_unacquired_notify (test.test_threading.ConditionTests) ... ok
test_unacquired_wait (test.test_threading.ConditionTests) ... ok
test_acquire (test.test_threading.SemaphoreTests) ... ok
test_acquire_contended (test.test_threading.SemaphoreTests) ... ok
test_acquire_destroy (test.test_threading.SemaphoreTests) ... ok
test_constructor (test.test_threading.SemaphoreTests) ... ok
test_default_value (test.test_threading.SemaphoreTests) ... ok
test_release_unacquired (test.test_threading.SemaphoreTests) ... ok
test_try_acquire (test.test_threading.SemaphoreTests) ... ok
test_try_acquire_contended (test.test_threading.SemaphoreTests) ... ok
test_with (test.test_threading.SemaphoreTests) ... ok
test_acquire (test.test_threading.BoundedSemaphoreTests) ... ok
test_acquire_contended (test.test_threading.BoundedSemaphoreTests) ... ok
test_acquire_destroy (test.test_threading.BoundedSemaphoreTests) ... ok
test_constructor (test.test_threading.BoundedSemaphoreTests) ... ok
test_default_value (test.test_threading.BoundedSemaphoreTests) ... ok
test_recursion_limit (test.test_threading.BoundedSemaphoreTests) ... skipped 'test macosx problem'
test_release_unacquired (test.test_threading.BoundedSemaphoreTests) ... ok
test_try_acquire (test.test_threading.BoundedSemaphoreTests) ... ok
test_try_acquire_contended (test.test_threading.BoundedSemaphoreTests) ... ok
test_with (test.test_threading.BoundedSemaphoreTests) ... ok
test_PyThreadState_SetAsyncExc (test.test_threading.ThreadTests) ...     started worker thread
    trying nonsensical thread id
    waiting for worker thread to get started
    verifying worker hasn't exited
    attempting to raise asynch exception in worker
    waiting for worker to say it caught the exception
    all OK -- joining worker
ok
test_dummy_thread_after_fork (test.test_threading.ThreadTests) ... ok
test_enumerate_after_join (test.test_threading.ThreadTests) ... ok
test_finalize_runnning_thread (test.test_threading.ThreadTests) ... ok
test_finalize_with_trace (test.test_threading.ThreadTests) ... ok
test_foreign_thread (test.test_threading.ThreadTests) ... ok
test_ident_of_no_threading_threads (test.test_threading.ThreadTests) ... ok
test_join_nondaemon_on_shutdown (test.test_threading.ThreadTests) ... ok
test_limbo_cleanup (test.test_threading.ThreadTests) ... ok
test_no_refcycle_through_target (test.test_threading.ThreadTests) ... ok
test_various_ops (test.test_threading.ThreadTests) ... task <thread 0> will run for 22.1 usec
1 tasks are runningtask <thread 1> will run for 20.0 usec

2 tasks are running
task <thread 2> will run for 84.1 usec
3 tasks are running
task <thread 3> will run for 66.9 usec
task <thread 4> will run for 59.7 usec
task <thread 5> will run for 70.5 usec
task <thread 6> will run for 82.3 usec
task <thread 7> will run for 62.1 usec
task <thread 8> will run for 4.9 usec
task <thread 9> will run for 85.3 usec
waiting for all tasks to complete
task <thread 0> done
<thread 0> is finished. 2 tasks are running
task <thread 1> done3 task tasks are running<thread 2>

<thread 1> is finished. 2 tasks are running
 done3 tasks are running

<thread 2> is finished. 2 tasks are running
3 tasks are running
tasktask <thread 5> task <thread 4>done  
done<thread 3> 
done<thread 4> is finished. 2 tasks are running

<thread 3> is finished. 1 tasks are running
2 tasks are running
3 tasks are running
<thread 5> is finished. 2 tasks are running
3 tasks are running
task <thread 6> done
<thread 6> is finished. 2 tasks are running
3task <thread 8>task  <thread 7>tasks are running  
done
done<thread 7> is finished. 2 tasks are running

<thread 8> is finished. 1 tasks are running
task <thread 9> done
<thread 9> is finished. 0 tasks are running
all tasks done
ok
test_various_ops_large_stack (test.test_threading.ThreadTests) ... with 1MB thread stack size...
task <thread 0> will run for 26.1 usec
1 task <thread 1> will run for 80.6 usec
 task <thread 2> will run for 83.7 usec
tasks are running
 task <thread 3> will run for 33.4 usec2 tasks are running
3 
tasks are running
 task <thread 4> will run for 14.3 usec
task <thread 5> will run for 34.0 usec
task <thread 6> will run for 3.4 usec
task <thread 7> will run for 83.4 usec
task <thread 8> will run for 49.6 usec
task <thread 9> will run for 57.3 usec
 waiting for all tasks to complete
task <thread 0> done
<thread 0> is finished. 2 tasks are running
3 task <thread 1> done
tasks are running
<thread 1> is finished. 2 tasks are running
3 tasks are running
task <thread 2> done
<thread 2> is finished. 2 tasks are running
3 tasks are running
task <thread 3> done
<thread 3> is finished. 2 tasks are running
3 tasks are running
task <thread 4> done
<thread 4> is finished. 2 tasks are running
3 tasks are running
task <thread 5> done
<thread 5> is finished. 2 tasks are running
3 tasks are running
task <thread 6> done
<thread 6> is finished. 2 tasks are running
3 tasks are running
task <thread 7> done
<thread 7> is finished. 2 tasks are running
task <thread 8> done
<thread 8> is finished. 1 tasks are running
task <thread 9> done
<thread 9> is finished. 0 tasks are running
all tasks done
ok
test_various_ops_small_stack (test.test_threading.ThreadTests) ... with 256kB thread stack size...
task <thread 0> will run for 17.3 usec
1 tasks are running
task <thread 1> will run for 95.0 usec
2 tasks are runningtask <thread 2> will run for 6.9 usec

3 tasks are running
task <thread 3> will run for 0.0 usec
task <thread 4> will run for 7.7 usec
task <thread 5> will run for 57.2 usec
task <thread 6> will run for 91.7 usec
 task <thread 7> will run for 40.6 usec
tasktask <thread 8> will run for 92.3 usec
 <thread 0> donetask <thread 9> will run for 44.3 usec
 waiting for all tasks to complete
<thread 0> is finished. 2 tasks are running
task <thread 1> 
done
<thread 1> is finished. 1 tasks are running
2 task <thread 2>tasks are running
 done3 task tasks are running<thread 3>

 done
<thread 3> is finished. 2 tasks are running
<thread 2> is finished. 1 tasks are running
2 tasks are running
3 tasks are running
task <thread 4> done
<thread 4> is finished. 2 tasks are running
3 tasks are running
task <thread 5> done
<thread 5> is finished. 2 tasks are running
 task <thread 6> done
<thread 6> is finished. 1 tasks are running
2 tasks are running
3 tasks are running
task <thread 7> done
<thread 7> is finished. 2 tasks are running
task <thread 9> done
<thread 9> is finished. 1 tasks are running
task <thread 8> done
<thread 8> is finished. 0 tasks are running
all tasks done
ok
test_1_join_on_shutdown (test.test_threading.ThreadJoinOnShutdown) ... ok
test_2_join_in_forked_process (test.test_threading.ThreadJoinOnShutdown) ... ok
test_3_join_in_forked_from_thread (test.test_threading.ThreadJoinOnShutdown) ...

----------

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

From report at bugs.python.org  Thu Aug  1 23:46:12 2013
From: report at bugs.python.org (Stephen Paul Chappell)
Date: Thu, 01 Aug 2013 21:46:12 +0000
Subject: [issue18558] Iterable glossary entry needs clarification
In-Reply-To: <1374796651.89.0.668716719647.issue18558@psf.upfronthosting.co.za>
Message-ID: <1375393572.01.0.442284358787.issue18558@psf.upfronthosting.co.za>


Stephen Paul Chappell added the comment:

Maybe this would have been more appropriate as a question on StackOverflow:

What is the proper way of asking if an object is iterable if it does not support the iterator protocol but does support the old getitem protocol? One might argue that it is better to ask for forgiveness rather than permission, but that does not really answer the question.

My impression of collections.abc.Iterable is that programmers can use it to ask if an object is iterable. Some argue that it is better to ask for forgiveness rather that permission and would suggest pretending that an object is iterable until it is proven otherwise. However, what do we use collections.abc.Iterable?s for then?

The true question is really, ?What is the proper way of asking if an object is iterable if it does not support the iterator protocol but does support the old getitem protocol?? More generically, how can you ask an object if it supports ANY iteration protocol? The query probably should have been posted on StackOverflow and not here.

This may not be a problem with collections.abc.Iterable, and thus the issue should be closed. However, the previous question remains, and it is apparent that it cannot be answered with the abstract class as it currently is. Maybe the solution is to just ask for forgiveness where appropriate.

----------

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

From report at bugs.python.org  Thu Aug  1 23:58:10 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 01 Aug 2013 21:58:10 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <1375394290.24.0.513706159196.issue10241@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


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

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

From report at bugs.python.org  Fri Aug  2 00:04:55 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 01 Aug 2013 22:04:55 +0000
Subject: [issue18614] Enhanced \N{} escapes for Unicode strings
In-Reply-To: <1375365245.12.0.441428484785.issue18614@psf.upfronthosting.co.za>
Message-ID: <1375394695.69.0.946219924984.issue18614@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree with the proposal.

Some of the code seems redundant with code we already have.
In Python, I would write

def codepoint_from_U_notation(name, namelen):
  if not (4 <= namelen <= 6): raise <wrong length>
  return chr(int(name, 16))

maybe with try-except to re-write error messages like
ValueError: invalid literal for int() with base 16: '99x3'
ValueError: chr() arg not in range(0x110000)

My point is that we already have code to convert hex strings to int; I presume PyUnicode_FromOrdinal(code) is the C version of 'chr' that already checks the max value.

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

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

From report at bugs.python.org  Fri Aug  2 00:07:03 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 01 Aug 2013 22:07:03 +0000
Subject: [issue18023] msi product code for 2.7.5150 not in Tools/msi/uuids.py
In-Reply-To: <1369079762.11.0.597354582837.issue18023@psf.upfronthosting.co.za>
Message-ID: <1375394823.38.0.606602277175.issue18023@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I have now added the uuid.

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

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

From report at bugs.python.org  Fri Aug  2 00:12:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 22:12:28 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
Message-ID: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

_SuppressCoreFiles in test_subprocess is a useful facility for other tests, for instance test_faulthandler (which has its own logic) or test_capi (which actually happily dumps core in one of its subtests).
It could probably be factored out into test.support.

----------
components: Tests
keywords: easy
messages: 194125
nosy: ezio.melotti, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Factor out the _SuppressCoreFiles context manager
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug  2 00:15:16 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Aug 2013 22:15:16 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>
Message-ID: <1375395316.65.0.752034557399.issue18623@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Aug  2 00:31:08 2013
From: report at bugs.python.org (Ned Deily)
Date: Thu, 01 Aug 2013 22:31:08 +0000
Subject: [issue16463] testConnectTimeout of test_timeout
	TCPTimeoutTestCasefailures fails intermittently
In-Reply-To: <1352757217.25.0.912881014186.issue16463@psf.upfronthosting.co.za>
Message-ID: <1375396268.06.0.269486862523.issue16463@psf.upfronthosting.co.za>


Ned Deily added the comment:

Also fails occasionally on OS X 3.3 and 3.x with much smaller deltas:

======================================================================
FAIL: testConnectTimeout (test.test_timeout.TCPTimeoutTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.3.bolen-tiger/build/Lib/test/test_timeout.py", line 222, in testConnectTimeout
    self._sock_operation(1, 0.001, 'connect', self.addr_remote)
  File "/Users/db3l/buildarea/3.3.bolen-tiger/build/Lib/test/test_timeout.py", line 126, in _sock_operation
    self.assertLess(delta, timeout + self.fuzz)
AssertionError: 2.0828001499176025 not less than 2.001

======================================================================
FAIL: testConnectTimeout (test.test_timeout.TCPTimeoutTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_timeout.py", line 222, in testConnectTimeout
    self._sock_operation(1, 0.001, 'connect', self.addr_remote)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_timeout.py", line 126, in _sock_operation
    self.assertLess(delta, timeout + self.fuzz)
AssertionError: 2.0782082080841064 not less than 2.001

----------
nosy: +ned.deily, trent
stage:  -> needs patch
title: test_timeout failure on the RHEL buildbot -> testConnectTimeout of test_timeout TCPTimeoutTestCasefailures fails intermittently
versions:  -Python 3.2

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

From report at bugs.python.org  Fri Aug  2 00:32:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 22:32:15 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <1375396335.82.0.432900350427.issue10241@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I managed to get a core dump locally. Interestingly, it may be that the _tk module is the culprit. The backtrace is the following:

#0  0x00007ff6c5e14aab in raise () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x000000000044e57e in faulthandler_fatal_error (signum=11) at ./Modules/faulthandler.c:305
#2  <signal handler called>
#3  0x00000000004c085e in _Py_Dealloc (op=<unknown at remote 0x7ff6bca2ac20>) at Objects/object.c:1873
#4  0x00000000004a8085 in free_keys_object (keys=0x3100ab0) at Objects/dictobject.c:378
#5  0x00000000004ab0e8 in dict_dealloc (mp=0x7ff6be6194b8) at Objects/dictobject.c:1400
#6  0x00000000004c0860 in _Py_Dealloc (
    op={'children': <unknown at remote 0x7ff6bc9ab3d8>, 'master': None, 'tk': <unknown at remote 0x7ff6bca2ac20>, '_tkloaded': 1, '_tclCommands': None}) at Objects/object.c:1873
#7  0x00000000004d7ac7 in subtype_dealloc (
    self=<Tk(children=<unknown at remote 0x7ff6bc9ab3d8>, master=None, tk=<unknown at remote 0x7ff6bca2ac20>, _tkloaded=1, _tclCommands=None) at remote 0x7ff6bc9a7dc0>) at Objects/typeobject.c:1049
#8  0x00000000004c0860 in _Py_Dealloc (
    op=<Tk(children=<unknown at remote 0x7ff6bc9ab3d8>, master=None, tk=<unknown at remote 0x7ff6bca2ac20>, _tkloaded=1, _tclCommands=None) at remote 0x7ff6bc9a7dc0>) at Objects/object.c:1873
#9  0x00000000004a8085 in free_keys_object (keys=0x3100e40) at Objects/dictobject.c:378
#10 0x00000000004aac8f in PyDict_Clear (op={}) at Objects/dictobject.c:1291
#11 0x00000000004dd9c8 in type_clear (type=0x14f45b8) at Objects/typeobject.c:2981
#12 0x000000000043a703 in delete_garbage (collectable=0x7fffab364300, old=0x8de7c0 <generations+64>) at Modules/gcmodule.c:854
#13 0x000000000043ac9d in collect (generation=2, n_collected=0x0, n_uncollectable=0x0, nofail=1) at Modules/gcmodule.c:1020
#14 0x000000000043bfa3 in _PyGC_CollectNoFail () at Modules/gcmodule.c:1619
#15 0x00000000005c6cb6 in PyImport_Cleanup () at Python/import.c:420
#16 0x000000000041d992 in Py_Finalize () at Python/pythonrun.c:552
#17 0x000000000042392b in Py_Exit (sts=0) at Python/pythonrun.c:2474
#18 0x000000000042114b in handle_system_exit () at Python/pythonrun.c:1673
#19 0x0000000000421176 in PyErr_PrintEx (set_sys_last_vars=1) at Python/pythonrun.c:1683
#20 0x0000000000420ddd in PyErr_Print () at Python/pythonrun.c:1590
#21 0x0000000000437fc4 in RunModule (modname=0xf4d570 L"test", set_argv0=1) at Modules/main.c:227
#22 0x0000000000439279 in Py_Main (argc=18, argv=0xf4c020) at Modules/main.c:715
#23 0x00000000004199b5 in main (argc=18, argv=0x7fffab364908) at ./Modules/python.c:69

----------

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

From report at bugs.python.org  Fri Aug  2 00:34:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 22:34:14 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>
Message-ID: <1375396454.14.0.499553880831.issue18623@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, and the recursion limit tests in test_sys dump core too...

----------

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

From report at bugs.python.org  Fri Aug  2 00:49:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Aug 2013 22:49:43 +0000
Subject: [issue18408] Fixes crashes found by pyfailmalloc
In-Reply-To: <1373314243.02.0.649080681154.issue18408@psf.upfronthosting.co.za>
Message-ID: <3c5msg0kZsz7Ljc@mail.python.org>


Roundup Robot added the comment:

New changeset de1ea7f84e08 by Victor Stinner in branch 'default':
Issue #18609, #18408: _ctypes_add_traceback() now clears the current exception
http://hg.python.org/cpython/rev/de1ea7f84e08

----------

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

From report at bugs.python.org  Fri Aug  2 00:49:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Aug 2013 22:49:44 +0000
Subject: [issue18609] test_ctypes failure on AIX in
	PyEval_CallObjectWithKeywords
In-Reply-To: <1375305877.13.0.891928742401.issue18609@psf.upfronthosting.co.za>
Message-ID: <3c5msg67gpz7Ljc@mail.python.org>


Roundup Robot added the comment:

New changeset de1ea7f84e08 by Victor Stinner in branch 'default':
Issue #18609, #18408: _ctypes_add_traceback() now clears the current exception
http://hg.python.org/cpython/rev/de1ea7f84e08

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Aug  2 00:50:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 22:50:59 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <1375397459.11.0.0602476120234.issue10241@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

_tkinter uses PyType_FromSpec() to create its types and then adds them to the module dict without increfing them, so there may be a refcount issue explaining that those types get garbage collected before all their instances die.

----------

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

From report at bugs.python.org  Fri Aug  2 00:56:38 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Aug 2013 22:56:38 +0000
Subject: [issue18609] test_ctypes failure on AIX in
	PyEval_CallObjectWithKeywords
In-Reply-To: <1375305877.13.0.891928742401.issue18609@psf.upfronthosting.co.za>
Message-ID: <1375397798.7.0.825717532043.issue18609@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue is not a bug, but a new assertion added by myself for the issue #18408. The idea is to not call a Python function with an exception set, because the exception may be cleared or replaced (ex: hasattr() clears the current exception if an attribute is not found).

I didn't see this specific issue because AIX is using a special locale setting. Its locale encoding is an alias of the ISO-8859-1 which is not known by PyUnicode_Decode().

I'm waiting for the buildbot to see if my changeset fixed the issue. If it does, I will also add a fast-path for the "iso8859-1" alias of the ISO-8859-1 codec in PyUnicode_Decode(). So the AIX buildbot will also use the C implementation of the codec.

----------

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

From report at bugs.python.org  Fri Aug  2 01:00:07 2013
From: report at bugs.python.org (=?utf-8?q?Maciej_Blizi=C5=84ski?=)
Date: Thu, 01 Aug 2013 23:00:07 +0000
Subject: [issue18605] 2.7: test_threading hangs on Solaris 9
In-Reply-To: <1375254182.2.0.923446047018.issue18605@psf.upfronthosting.co.za>
Message-ID: <1375398007.45.0.628972001828.issue18605@psf.upfronthosting.co.za>


Maciej Blizi?ski added the comment:

Test results for sources pulled from the mercurial repository: they hang in the same place.

== CPython 3.4.0a0 (default, Aug 2 2013, 00:38:45) [GCC 4.6.3]
==   Solaris-2.9-sun4u-sparc-32bit-ELF big-endian
==   /home/maciej/src/cpython/build/test_python_19419
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)
[1/1] test_threading
test_abort (test.test_threading.BarrierTests) ... ok
test_abort_and_reset (test.test_threading.BarrierTests) ... ok
test_action (test.test_threading.BarrierTests) ... ok
test_barrier (test.test_threading.BarrierTests) ... ok
test_barrier_10 (test.test_threading.BarrierTests) ... ok
test_default_timeout (test.test_threading.BarrierTests) ... ok
test_reset (test.test_threading.BarrierTests) ... ok
test_single_thread (test.test_threading.BarrierTests) ... ok
test_timeout (test.test_threading.BarrierTests) ... ok
test_wait_return (test.test_threading.BarrierTests) ... ok
test_acquire (test.test_threading.BoundedSemaphoreTests) ... ok
test_acquire_contended (test.test_threading.BoundedSemaphoreTests) ... ok
test_acquire_destroy (test.test_threading.BoundedSemaphoreTests) ... ok
test_acquire_timeout (test.test_threading.BoundedSemaphoreTests) ... ok
test_constructor (test.test_threading.BoundedSemaphoreTests) ... ok
test_default_value (test.test_threading.BoundedSemaphoreTests) ... ok
test_release_unacquired (test.test_threading.BoundedSemaphoreTests) ... ok
test_try_acquire (test.test_threading.BoundedSemaphoreTests) ... ok
test_try_acquire_contended (test.test_threading.BoundedSemaphoreTests) ... ok
test_with (test.test_threading.BoundedSemaphoreTests) ... ok
test__is_owned (test.test_threading.CRLockTests) ... ok
test_acquire_contended (test.test_threading.CRLockTests) ... ok
test_acquire_destroy (test.test_threading.CRLockTests) ... ok
test_acquire_release (test.test_threading.CRLockTests) ... ok
test_constructor (test.test_threading.CRLockTests) ... ok
test_different_thread (test.test_threading.CRLockTests) ... ok
test_reacquire (test.test_threading.CRLockTests) ... ok
test_release_save_unacquired (test.test_threading.CRLockTests) ... ok
test_release_unacquired (test.test_threading.CRLockTests) ... ok
test_repr (test.test_threading.CRLockTests) ... ok
test_thread_leak (test.test_threading.CRLockTests) ... ok
test_timeout (test.test_threading.CRLockTests) ... ok
test_try_acquire (test.test_threading.CRLockTests) ... ok
test_try_acquire_contended (test.test_threading.CRLockTests) ... ok
test_with (test.test_threading.CRLockTests) ... ok
test__is_owned (test.test_threading.ConditionAsRLockTests) ... ok
test_acquire_contended (test.test_threading.ConditionAsRLockTests) ... ok
test_acquire_destroy (test.test_threading.ConditionAsRLockTests) ... ok
test_acquire_release (test.test_threading.ConditionAsRLockTests) ... ok
test_constructor (test.test_threading.ConditionAsRLockTests) ... ok
test_different_thread (test.test_threading.ConditionAsRLockTests) ... ok
test_reacquire (test.test_threading.ConditionAsRLockTests) ... ok
test_release_save_unacquired (test.test_threading.ConditionAsRLockTests) ... ok
test_release_unacquired (test.test_threading.ConditionAsRLockTests) ... ok
test_repr (test.test_threading.ConditionAsRLockTests) ... ok
test_thread_leak (test.test_threading.ConditionAsRLockTests) ... ok
test_timeout (test.test_threading.ConditionAsRLockTests) ... ok
test_try_acquire (test.test_threading.ConditionAsRLockTests) ... ok
test_try_acquire_contended (test.test_threading.ConditionAsRLockTests) ... ok
test_with (test.test_threading.ConditionAsRLockTests) ... ok
test_acquire (test.test_threading.ConditionTests) ... ok
test_notify (test.test_threading.ConditionTests) ... ok
test_timeout (test.test_threading.ConditionTests) ... ok
test_unacquired_notify (test.test_threading.ConditionTests) ... ok
test_unacquired_wait (test.test_threading.ConditionTests) ... ok
test_waitfor (test.test_threading.ConditionTests) ... ok
test_waitfor_timeout (test.test_threading.ConditionTests) ... ok
test_is_set (test.test_threading.EventTests) ... ok
test_notify (test.test_threading.EventTests) ... ok
test_set_and_clear (test.test_threading.EventTests) ... ok
test_timeout (test.test_threading.EventTests) ... ok
test_acquire_contended (test.test_threading.LockTests) ... ok
test_acquire_destroy (test.test_threading.LockTests) ... ok
test_acquire_release (test.test_threading.LockTests) ... ok
test_constructor (test.test_threading.LockTests) ... ok
test_different_thread (test.test_threading.LockTests) ... ok
test_reacquire (test.test_threading.LockTests) ... ok
test_repr (test.test_threading.LockTests) ... ok
test_state_after_timeout (test.test_threading.LockTests) ... ok
test_thread_leak (test.test_threading.LockTests) ... ok
test_timeout (test.test_threading.LockTests) ... ok
test_try_acquire (test.test_threading.LockTests) ... ok
test_try_acquire_contended (test.test_threading.LockTests) ... ok
test_with (test.test_threading.LockTests) ... ok
test__is_owned (test.test_threading.PyRLockTests) ... ok
test_acquire_contended (test.test_threading.PyRLockTests) ... ok
test_acquire_destroy (test.test_threading.PyRLockTests) ... ok
test_acquire_release (test.test_threading.PyRLockTests) ... ok
test_constructor (test.test_threading.PyRLockTests) ... ok
test_different_thread (test.test_threading.PyRLockTests) ... ok
test_reacquire (test.test_threading.PyRLockTests) ... ok
test_release_save_unacquired (test.test_threading.PyRLockTests) ... ok
test_release_unacquired (test.test_threading.PyRLockTests) ... ok
test_repr (test.test_threading.PyRLockTests) ... ok
test_thread_leak (test.test_threading.PyRLockTests) ... ok
test_timeout (test.test_threading.PyRLockTests) ... ok
test_try_acquire (test.test_threading.PyRLockTests) ... ok
test_try_acquire_contended (test.test_threading.PyRLockTests) ... ok
test_with (test.test_threading.PyRLockTests) ... ok
test_acquire (test.test_threading.SemaphoreTests) ... ok
test_acquire_contended (test.test_threading.SemaphoreTests) ... ok
test_acquire_destroy (test.test_threading.SemaphoreTests) ... ok
test_acquire_timeout (test.test_threading.SemaphoreTests) ... ok
test_constructor (test.test_threading.SemaphoreTests) ... ok
test_default_value (test.test_threading.SemaphoreTests) ... ok
test_release_unacquired (test.test_threading.SemaphoreTests) ... ok
test_try_acquire (test.test_threading.SemaphoreTests) ... ok
test_try_acquire_contended (test.test_threading.SemaphoreTests) ... ok
test_with (test.test_threading.SemaphoreTests) ... ok
test_1_join_on_shutdown (test.test_threading.ThreadJoinOnShutdown) ... ok
test_2_join_in_forked_process (test.test_threading.ThreadJoinOnShutdown) ... ok
test_3_join_in_forked_from_thread (test.test_threading.ThreadJoinOnShutdown) ...

----------

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

From report at bugs.python.org  Fri Aug  2 01:04:29 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Aug 2013 23:04:29 +0000
Subject: [issue18624] Add alias for iso-8859-8-i which is the same as
	iso-8859-8
Message-ID: <1375398269.06.0.0330535739148.issue18624@psf.upfronthosting.co.za>


New submission from R. David Murray:

Emails and web pages may specify a character set of iso-8859-8-i, which has exactly the same code points as iso-8859-8. The -i has to do with how bi-directional text is handled, but doesn't affect the encoding: http://lists.w3.org/Archives/Public/www-validator/2001Apr/0008.html

----------
components: Unicode, email
keywords: easy
messages: 194134
nosy: barry, ezio.melotti, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Add alias for iso-8859-8-i which is the same as iso-8859-8
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug  2 01:29:18 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Aug 2013 23:29:18 +0000
Subject: [issue18558] Iterable glossary entry needs clarification
In-Reply-To: <1374796651.89.0.668716719647.issue18558@psf.upfronthosting.co.za>
Message-ID: <1375399758.79.0.488038477513.issue18558@psf.upfronthosting.co.za>


R. David Murray added the comment:

?What is the proper way of asking if an object is iterable if it does not support the iterator protocol but does support the old getitem protocol??

The *only* answer to that question is to try to iterate it, and see if you get a KeyError on "0".  Since this results in obtaining the first element if it *is* iterable, and in the general case you cannot "reset" an iterable, there is no way to look before you leap.  You have to catch the error after it occurs.

This question and answer probably do belong on Stack Overflow or python-list, but the glossary entry still needs improvement, since the Iterable docs reference it :)

----------

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

From report at bugs.python.org  Fri Aug  2 01:35:54 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Aug 2013 23:35:54 +0000
Subject: [issue18519] test_sqlite crashes on OS X tiger 3.x buildbot
In-Reply-To: <1374400670.71.0.678852160853.issue18519@psf.upfronthosting.co.za>
Message-ID: <1375400154.08.0.824485161104.issue18519@psf.upfronthosting.co.za>


STINNER Victor added the comment:

ned> The changes for this issue appear to have changed the behavior of test_sqlite.
David> Heh, that's the kind of behavior change I was worried about :(

I don't understand why the test is failing, nor why it is only failing on one specific buildbot. Does it mean that 5/0 does not raise an exception on this specific buildbot?

I don't understand the relation between my changesets and this failure.

----------

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

From report at bugs.python.org  Fri Aug  2 01:44:13 2013
From: report at bugs.python.org (Kevin Harms)
Date: Thu, 01 Aug 2013 23:44:13 +0000
Subject: [issue14956] custom PYTHONPATH may break apps embedding Python
In-Reply-To: <1338321412.45.0.331737203349.issue14956@psf.upfronthosting.co.za>
Message-ID: <1375400653.72.0.512111597617.issue14956@psf.upfronthosting.co.za>


Kevin Harms added the comment:

As far as I can tell, this issue is not resolved. It would be very nice for the C API to have the equivalent for -E for security reasons. I would like to make a setgid binary and do not want users to be able to set PYTHON* variables to force loading of custom code.

----------
nosy: +Kevin.Harms

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

From report at bugs.python.org  Fri Aug  2 01:48:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Aug 2013 23:48:32 +0000
Subject: [issue18519] test_sqlite crashes on OS X tiger 3.x buildbot
In-Reply-To: <1374400670.71.0.678852160853.issue18519@psf.upfronthosting.co.za>
Message-ID: <3c5p9X1JG2zNPH@mail.python.org>


Roundup Robot added the comment:

New changeset c73f4dced6aa by Victor Stinner in branch 'default':
Issue #18519: Fix test_sqlite on old versions of libsqlite3
http://hg.python.org/cpython/rev/c73f4dced6aa

----------

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

From report at bugs.python.org  Fri Aug  2 01:54:04 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Aug 2013 23:54:04 +0000
Subject: [issue18625] ks_c-5601-1987 is used by microsoft when it really means
	cp949
Message-ID: <1375401244.03.0.758628896825.issue18625@psf.upfronthosting.co.za>


New submission from R. David Murray:

When Microsoft handles Korean text, it uses its own code page, cp949, which is a superset of ks_c-5601-1987.  But when talking to the rest of the world, it claims that the character set name is ks_c-5601-1987.  This means that text claimed to be in ks_c-5601-1987 in email messages (and probably on web pages) can't always be decoded using the codec that ks_c-5601-1987 maps to (euc_kr). [*]

This problem shows up in the real world in email.  If non euc_kr characters are used, email will try blow up when trying to decode the ostensibly ks_c-5601-1987 text.  (I'm not sure if it will also blow up trying to encode it, I'm not sure what characters the two codecs cover.)

I'm not sure what the best solution is, but one possibility would be to add a "fixup" table to email that would cause it to decode ostensibly ks_c-5601-1987 text using the cp949 codec.  Since cp949 is a superset, this should at least solve the input side.

[*] Some relevant standards discussion:
   
    http://lists.w3.org/Archives/Public/ietf-charsets/2001AprJun/0033.html

>From this, it isn't clear why we map ks_c-5601-1987 to euc_kr, since they at least appear to be different codecs.  I haven't looked at the relevant RFCs to see what the differences are, though.

----------
components: Unicode, email
messages: 194139
nosy: barry, ezio.melotti, r.david.murray
priority: normal
severity: normal
status: open
title: ks_c-5601-1987 is used by microsoft when it really means cp949
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug  2 02:02:46 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Aug 2013 00:02:46 +0000
Subject: [issue18519] test_sqlite crashes on OS X tiger 3.x buildbot
In-Reply-To: <3c5p9X1JG2zNPH@mail.python.org>
Message-ID: <CAMpsgwZesCVHmi=HeLa=nTV8kGO_f4wz1KFJecVdJcoCebmDuQ@mail.gmail.com>


STINNER Victor added the comment:

> I don't understand the relation between my changesets and this failure.

Ok, I found the reason in the definition of the
_sqlite3_result_error() function. This function behave differently on
old sqlite versions: it raises a new exception. The issue should now
be fixed, can you please try on your Tiger box?

----------

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

From report at bugs.python.org  Fri Aug  2 02:08:09 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 02 Aug 2013 00:08:09 +0000
Subject: [issue18519] test_sqlite crashes on OS X tiger 3.x buildbot
In-Reply-To: <1374400670.71.0.678852160853.issue18519@psf.upfronthosting.co.za>
Message-ID: <1375402089.71.0.471760343372.issue18519@psf.upfronthosting.co.za>


Ned Deily added the comment:

c73f4dced6aa appears to fix the problem on 10.4 Tiger.  Thanks!

----------

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

From report at bugs.python.org  Fri Aug  2 02:09:28 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Aug 2013 00:09:28 +0000
Subject: [issue18519] test_sqlite crashes on OS X tiger 3.x buildbot
In-Reply-To: <1374400670.71.0.678852160853.issue18519@psf.upfronthosting.co.za>
Message-ID: <1375402168.16.0.972336366861.issue18519@psf.upfronthosting.co.za>


STINNER Victor added the comment:

There is no more known bug, i'm closing this issue.

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

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

From report at bugs.python.org  Fri Aug  2 02:32:30 2013
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 02 Aug 2013 00:32:30 +0000
Subject: [issue17145] memoryview(array.array)
In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>
Message-ID: <1375403550.77.0.697244610446.issue17145@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Bump. If the patch (or request) is invalid, might be worthwhile closing this issue (although I still think it's valid ;)).

----------

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

From report at bugs.python.org  Fri Aug  2 03:12:20 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 02 Aug 2013 01:12:20 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za>
Message-ID: <1375405940.66.0.319351095064.issue18472@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Patch applied.

----------

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

From report at bugs.python.org  Fri Aug  2 03:21:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Aug 2013 01:21:50 +0000
Subject: [issue17899] os.listdir() leaks FDs if invoked on FD pointing to a
	non-directory
In-Reply-To: <1367608586.39.0.0815102318744.issue17899@psf.upfronthosting.co.za>
Message-ID: <3c5rF94n90z7LkP@mail.python.org>


Roundup Robot added the comment:

New changeset e51cbc45f4ca by Larry Hastings in branch 'default':
Issue #17899: Fix rare file descriptor leak in os.listdir().
http://hg.python.org/cpython/rev/e51cbc45f4ca

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Aug  2 04:39:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Aug 2013 02:39:13 +0000
Subject: [issue17899] os.listdir() leaks FDs if invoked on FD pointing to a
	non-directory
In-Reply-To: <1367608586.39.0.0815102318744.issue17899@psf.upfronthosting.co.za>
Message-ID: <3c5syT22m2zQ7y@mail.python.org>


Roundup Robot added the comment:

New changeset bf68711bc939 by Larry Hastings in branch '3.3':
Issue #17899: Fix rare file descriptor leak in os.listdir().
http://hg.python.org/cpython/rev/bf68711bc939

----------

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

From report at bugs.python.org  Fri Aug  2 04:39:59 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 02 Aug 2013 02:39:59 +0000
Subject: [issue17899] os.listdir() leaks FDs if invoked on FD pointing to a
	non-directory
In-Reply-To: <1367608586.39.0.0815102318744.issue17899@psf.upfronthosting.co.za>
Message-ID: <1375411199.31.0.0628584984594.issue17899@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Marking as closed/fixed.

----------
assignee:  -> larry
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Aug  2 05:12:40 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Aug 2013 03:12:40 +0000
Subject: [issue18626] Make "python -m inspect <name>" dump the source of a
	module
Message-ID: <1375413160.45.0.218073630788.issue18626@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

"python -m inspect <name>" doesn't currently do anything.

It would be handy if this:

    python -m inspect site

Was roughly equivalent to:

    python -c "import inspect, site; print(inspect.getsource(site))"

Even better would be if it understood entry point notation so you could use "modname:qualname" to get the source code of a particular item within a module.

----------
components: Library (Lib)
messages: 194148
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Make "python -m inspect <name>" dump the source of a module
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug  2 06:38:09 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Aug 2013 04:38:09 +0000
Subject: [issue17557] test_getgroups of test_posix can fail on OS X 10.8 if
	more than 16 groups
In-Reply-To: <1364378141.47.0.183536890409.issue17557@psf.upfronthosting.co.za>
Message-ID: <3c5wbh5MnBz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset 6d3b7e0559a0 by Ned Deily in branch '2.7':
Issue #17557: Fix os.getgroups() to work with the modified behavior of
http://hg.python.org/cpython/rev/6d3b7e0559a0

New changeset 0a4afa8833b5 by Ned Deily in branch '3.3':
Issue #17557: Fix os.getgroups() to work with the modified behavior of
http://hg.python.org/cpython/rev/0a4afa8833b5

New changeset 634a8e8816d4 by Ned Deily in branch 'default':
Issue #17557: merge from 3.3
http://hg.python.org/cpython/rev/634a8e8816d4

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Aug  2 06:43:31 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 02 Aug 2013 04:43:31 +0000
Subject: [issue17557] test_getgroups of test_posix can fail on OS X 10.8 if
	more than 16 groups
In-Reply-To: <1364378141.47.0.183536890409.issue17557@psf.upfronthosting.co.za>
Message-ID: <1375418611.85.0.118548824879.issue17557@psf.upfronthosting.co.za>


Ned Deily added the comment:

Committed patch (with slight modifications) for release in 2.7.6, 3.3.3, and 3.4.0.  Thanks again, Mateusz.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.2

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

From report at bugs.python.org  Fri Aug  2 06:43:38 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 02 Aug 2013 04:43:38 +0000
Subject: [issue18627] Typo in Modules/hashlib.h
Message-ID: <1375418618.45.0.59595383081.issue18627@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Got typo in Modules/hashlib.h. See this patch for detail:

--- a/Modules/hashlib.h	Wed Jul 31 20:48:26 2013 -0400
+++ b/Modules/hashlib.h	Fri Aug 02 12:39:00 2013 +0800
@@ -2,7 +2,7 @@
 
 /*
  * Given a PyObject* obj, fill in the Py_buffer* viewp with the result
- * of PyObject_GetBuffer.  Sets and exception and issues a return NULL
+ * of PyObject_GetBuffer.  Sets an exception and issues a return NULL
  * on any errors.
  */
 #define GET_BUFFER_VIEW_OR_ERROUT(obj, viewp) do { \

----------
assignee: docs at python
components: Documentation
messages: 194151
nosy: docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Typo in Modules/hashlib.h
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug  2 06:49:44 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Aug 2013 04:49:44 +0000
Subject: [issue18628] PEP 8 and encodings
Message-ID: <1375418984.87.0.318628832877.issue18628@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Three related doc change proposals. The Versions only apply to the third as the first two are for PEP 8.

1. PEP 8 has a section entitled "Encodings (PEP 263)" with a link to the verbose PEP. I think it would be better if it were "Source Encoding" with a link to the 'current' Reference Manual section 2.1.4. Encoding declarations. The latter gets right to the point.

2. This section twice uses the informal and undefined term 'coding cookie'. It is not in the ref manual section above, nor in the glossary, nor in the index. (Dave Angel asked about the definition on python-list. Before searching on the web, he first thought it meant BOM.) I suggest changing "a coding cookie" to "an encoding declaration".

3. The index has several entries that begin with 'encode', including one that just says 'encodings'. The last is the one that points to 2.1.4., but one would only guess by process of elimination. I think 'encoding (source file)' or 'encoding declarations (source file)' would be clearer.

----------
assignee: docs at python
components: Documentation
messages: 194152
nosy: docs at python, ncoghlan, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: PEP 8 and encodings
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Aug  2 06:53:11 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 02 Aug 2013 04:53:11 +0000
Subject: [issue18626] Make "python -m inspect <name>" dump the source of a
	module
In-Reply-To: <1375413160.45.0.218073630788.issue18626@psf.upfronthosting.co.za>
Message-ID: <1375419191.08.0.571987948186.issue18626@psf.upfronthosting.co.za>


Eric Snow added the comment:

At the risk of unnecessary complication, there is also other information that could be output, depending on the referenced object (module vs. class/func via qualname).  For instance, a module's __file__ would be handy.  So, the output could have a "header" with the relevant info, followed by a blank line, and then the source code.

I suppose something like that could be added later with a commandline option, like "python -m inspect --info site", rather than being default behavior.  Then this issue can stay focused on the simpler idea. :)

Regardless, your proposal sounds good to me.  I don't see any other meaningful use for "-m inspect".

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

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

From report at bugs.python.org  Fri Aug  2 07:13:54 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Aug 2013 05:13:54 +0000
Subject: [issue18627] Typo in Modules/hashlib.h
In-Reply-To: <1375418618.45.0.59595383081.issue18627@psf.upfronthosting.co.za>
Message-ID: <3c5xNx6Tc7z7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset 3716d64f846b by Ned Deily in branch '3.3':
Issue #18627: Fix typo noticed by Vajrasky Kok.
http://hg.python.org/cpython/rev/3716d64f846b

New changeset 454e9db1c750 by Ned Deily in branch 'default':
Closes #18627: merge from 3.3
http://hg.python.org/cpython/rev/454e9db1c750

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

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

From report at bugs.python.org  Fri Aug  2 07:14:55 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 02 Aug 2013 05:14:55 +0000
Subject: [issue18627] Typo in Modules/hashlib.h
In-Reply-To: <1375418618.45.0.59595383081.issue18627@psf.upfronthosting.co.za>
Message-ID: <1375420495.54.0.707371648291.issue18627@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
versions: +Python 3.3

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

From report at bugs.python.org  Fri Aug  2 07:51:19 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 02 Aug 2013 05:51:19 +0000
Subject: [issue18550] internal_setblocking() doesn't check return value of
	fcntl()
In-Reply-To: <1374694779.19.0.0902694218162.issue18550@psf.upfronthosting.co.za>
Message-ID: <1375422679.04.0.630929896378.issue18550@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

It's a bit tedious, but not too bad. The attached patch appears to work, but needs review (especially for the Windows and VMS branches in internal_setblocking.

This changes the return value of internal_setblocking, it was unconditionally 1 and is now -1 if the call fails and 0 otherwise.

----------
keywords: +needs review, patch
nosy: +ronaldoussoren
stage: needs patch -> patch review

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

From report at bugs.python.org  Fri Aug  2 07:55:55 2013
From: report at bugs.python.org (Valerie Lambert)
Date: Fri, 02 Aug 2013 05:55:55 +0000
Subject: [issue4885] mmap enhancement request
In-Reply-To: <1231445893.72.0.162990779773.issue4885@psf.upfronthosting.co.za>
Message-ID: <1375422955.52.0.0724329124788.issue4885@psf.upfronthosting.co.za>


Valerie Lambert added the comment:

I've uploaded a patch to make mmap_obj support weakref. A test is included in the patch.

----------
keywords: +patch
nosy: +lambertv
Added file: http://bugs.python.org/file31115/issue-4885.patch

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

From report at bugs.python.org  Fri Aug  2 08:54:03 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Aug 2013 06:54:03 +0000
Subject: [issue18517] "xxlimited" extension declared incorrectly in setup.py
In-Reply-To: <1374393760.41.0.977042124577.issue18517@psf.upfronthosting.co.za>
Message-ID: <3c5zcV4yQjz7LjV@mail.python.org>


Roundup Robot added the comment:

New changeset e5607874e8ff by Ned Deily in branch '3.3':
Issue #18517: Move definition of "xxlimited" extension to detect_modules().
http://hg.python.org/cpython/rev/e5607874e8ff

New changeset 1d832bc857e2 by Ned Deily in branch 'default':
Issue #18517: merge from 3.3
http://hg.python.org/cpython/rev/1d832bc857e2

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Aug  2 08:56:00 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 06:56:00 +0000
Subject: [issue16945] rewrite CGIHTTPRequestHandler to always use subprocess
In-Reply-To: <1358000083.64.0.0773347996342.issue16945@psf.upfronthosting.co.za>
Message-ID: <1375426560.53.0.600896599241.issue16945@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Marking #10496 as a dependency (since it could prevent Python from running  with low level privileges).

----------
dependencies: +Python startup should not require passwd entry

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

From report at bugs.python.org  Fri Aug  2 09:05:03 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 02 Aug 2013 07:05:03 +0000
Subject: [issue18517] "xxlimited" extension declared incorrectly in setup.py
In-Reply-To: <1374393760.41.0.977042124577.issue18517@psf.upfronthosting.co.za>
Message-ID: <1375427103.6.0.226161344631.issue18517@psf.upfronthosting.co.za>


Ned Deily added the comment:

On further reflection, only building on a debug build partially defeats part of the reason for building xxlimited; the current setup.py skips building in the debug case.  Perhaps another approach would be to comment out the build in setup.py and instead add a new test case that builds xxlimited, similar to how test_distutils builds xxmodule. In any case, I've applied the original patch for 3.3.3 and 3.4.0 and closing this issue.  Feel free to reopen if anyone wants to pursue this further.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3

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

From report at bugs.python.org  Fri Aug  2 09:07:35 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 07:07:35 +0000
Subject: [issue18418] Thread.isAlive() sometimes True after fork
In-Reply-To: <1373408030.66.0.77258289483.issue18418@psf.upfronthosting.co.za>
Message-ID: <1375427255.41.0.51637343076.issue18418@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

I've posted another review (not sure you receive notifications).

----------

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

From report at bugs.python.org  Fri Aug  2 09:08:28 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 07:08:28 +0000
Subject: [issue10496] Python startup should not require passwd entry
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1375427308.82.0.0624143240035.issue10496@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
keywords: +needs review

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

From report at bugs.python.org  Fri Aug  2 10:02:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Aug 2013 08:02:27 +0000
Subject: [issue18325] test_kqueue fails in OpenBSD
In-Reply-To: <1372452616.96.0.640334462237.issue18325@psf.upfronthosting.co.za>
Message-ID: <3c617Q5tJcz7Llj@mail.python.org>


Roundup Robot added the comment:

New changeset 8205e72b5cfc by Charles-Fran?ois Natali in branch '2.7':
Issue #18325: Fix a test_kqueue failure on OpenBSD: kevent's data and event
http://hg.python.org/cpython/rev/8205e72b5cfc

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Aug  2 10:22:55 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Aug 2013 08:22:55 +0000
Subject: [issue18325] test_kqueue fails in OpenBSD
In-Reply-To: <1372452616.96.0.640334462237.issue18325@psf.upfronthosting.co.za>
Message-ID: <3c61b303vXz7LkQ@mail.python.org>


Roundup Robot added the comment:

New changeset 78db41e4c6a9 by Charles-Fran?ois Natali in branch '3.3':
Issue #18325: Fix a test_kqueue failure on OpenBSD: kevent's data and event
http://hg.python.org/cpython/rev/78db41e4c6a9

New changeset 1287d4c9cd39 by Charles-Fran?ois Natali in branch 'default':
Issue #18325: Fix a test_kqueue failure on OpenBSD: kevent's data and event
http://hg.python.org/cpython/rev/1287d4c9cd39

----------

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

From report at bugs.python.org  Fri Aug  2 10:23:53 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 02 Aug 2013 08:23:53 +0000
Subject: [issue18625] ks_c-5601-1987 is used by microsoft when it really means
	cp949
In-Reply-To: <1375401244.03.0.758628896825.issue18625@psf.upfronthosting.co.za>
Message-ID: <1375431833.93.0.815706556181.issue18625@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

The alias was added by Hye-Shik Chang:

http://hg.python.org/cpython-fullhistory/annotate/887ce39f95f2/Lib/encodings/aliases.py#198

I've added him to the nosy list.

If the alias don't match, we'd have to add a codec for the mismatching encoding to maintain compatibility (provided the mismatching encoding is still in use).

----------
nosy: +hyeshik.chang, lemburg

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

From report at bugs.python.org  Fri Aug  2 10:30:36 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 08:30:36 +0000
Subject: [issue1611154] os.path.exists("file/") failure on Solaris 9
Message-ID: <1375432236.35.0.213394956079.issue1611154@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


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

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

From report at bugs.python.org  Fri Aug  2 10:34:06 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 08:34:06 +0000
Subject: [issue17070] PEP 433: Use the new cloexec to improve security and
	avoid bugs
In-Reply-To: <1359464957.74.0.458887600287.issue17070@psf.upfronthosting.co.za>
Message-ID: <1375432446.52.0.46740016055.issue17070@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Time to close this one, since the PEP has been superseeded by PEP 446?

----------

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

From report at bugs.python.org  Fri Aug  2 10:37:18 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 02 Aug 2013 08:37:18 +0000
Subject: [issue18624] Add alias for iso-8859-8-i which is the same as
	iso-8859-8
In-Reply-To: <1375398269.06.0.0330535739148.issue18624@psf.upfronthosting.co.za>
Message-ID: <1375432638.63.0.125195794096.issue18624@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Here's a usable reference:

http://www.w3.org/TR/html4/struct/dirlang.html#bidi88598

+1 on adding the alias.

Also see

http://lists.gnu.org/archive/html/lynx-dev/2012-02/msg00041.html

for how Lynx does this.

The URL also mentions "iso-8859-8-e", which should probably also be aliased to "iso-8859-8". Both names only apply to visual display characteristics of the text; the encoding is the same.

----------
nosy: +lemburg

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

From report at bugs.python.org  Fri Aug  2 10:57:03 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 08:57:03 +0000
Subject: [issue11757] test_subprocess.test_communicate_timeout_large_ouput
	failure on select(): negative timeout?
In-Reply-To: <1301869705.52.0.173979620005.issue11757@psf.upfronthosting.co.za>
Message-ID: <1375433823.19.0.647717593817.issue11757@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
status: pending -> closed

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

From report at bugs.python.org  Fri Aug  2 10:59:19 2013
From: report at bugs.python.org (Michael Foord)
Date: Fri, 02 Aug 2013 08:59:19 +0000
Subject: [issue18622] reset_mock on mock created by mock_open causes infinite
	recursion
In-Reply-To: <1375391057.28.0.108463427813.issue18622@psf.upfronthosting.co.za>
Message-ID: <1375433959.37.0.622075627105.issue18622@psf.upfronthosting.co.za>


Michael Foord added the comment:

The best way to solve this seems to be to track a set of visited ids (mocks we've reset) and not recurse into mocks we've already done. This is similar to the patch proposed on the google code issue - but not identical as that uses a list and has it as the default argument to reset_mock.

----------

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

From report at bugs.python.org  Fri Aug  2 10:59:35 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 08:59:35 +0000
Subject: [issue12999] _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED usage on Solaris
In-Reply-To: <1316244012.97.0.109004277803.issue12999@psf.upfronthosting.co.za>
Message-ID: <1375433975.12.0.843459390404.issue12999@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

OK, let's close then.
We can still re-open if this pops up again.

----------
status: pending -> closed

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

From report at bugs.python.org  Fri Aug  2 11:14:29 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 09:14:29 +0000
Subject: [issue10897] UNIX mmap unnecessarily dup() file descriptor
In-Reply-To: <1294845379.76.0.427887707002.issue10897@psf.upfronthosting.co.za>
Message-ID: <1375434869.07.0.399202279328.issue10897@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

I changed my mind, and think we should keep the current behavior: it guarantees resize() won't break, and doesn't cost much. One extra FD per mmap is not a huge hit. If that's a problem, then the user can raise the RLIMIT_NOFILE.

----------

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

From report at bugs.python.org  Fri Aug  2 11:18:02 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 09:18:02 +0000
Subject: [issue12588] test_capi.test_subinterps() failed on OpenBSD (powerpc)
In-Reply-To: <1311111401.9.0.18298571301.issue12588@psf.upfronthosting.co.za>
Message-ID: <1375435082.56.0.516887027886.issue12588@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


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

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

From report at bugs.python.org  Fri Aug  2 11:20:45 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 09:20:45 +0000
Subject: [issue18325] test_kqueue fails in OpenBSD
In-Reply-To: <1372452616.96.0.640334462237.issue18325@psf.upfronthosting.co.za>
Message-ID: <1375435245.63.0.421771243036.issue18325@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Should be fixed now.
Thanks for the report, and sorry for the delay!

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

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

From report at bugs.python.org  Fri Aug  2 11:24:05 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 09:24:05 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1375435445.7.0.250081619299.issue16038@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

So, what now?

----------

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

From report at bugs.python.org  Fri Aug  2 11:30:27 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 09:30:27 +0000
Subject: [issue16635] Interpreter not closing stdout/stderr on exit
In-Reply-To: <1354887230.33.0.111304282824.issue16635@psf.upfronthosting.co.za>
Message-ID: <1375435827.5.0.261238693473.issue16635@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


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

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

From report at bugs.python.org  Fri Aug  2 11:42:30 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Aug 2013 09:42:30 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1375405940.66.0.319351095064.issue18472@psf.upfronthosting.co.za>
Message-ID: <CADiSq7csLmvr_Y6xBdFLnTbXwnJdQyC-xGsYpH9+abcxYoviEQ@mail.gmail.com>


Nick Coghlan added the comment:

I like the new wording, but was there a missing "hg push" here? (Not seeing
the update on hg.python.org/peps)

----------

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

From report at bugs.python.org  Fri Aug  2 11:56:46 2013
From: report at bugs.python.org (Lorenz Huedepohl)
Date: Fri, 02 Aug 2013 09:56:46 +0000
Subject: [issue10897] UNIX mmap unnecessarily dup() file descriptor
In-Reply-To: <1294845379.76.0.427887707002.issue10897@psf.upfronthosting.co.za>
Message-ID: <1375437406.22.0.387314184319.issue10897@psf.upfronthosting.co.za>


Lorenz Huedepohl added the comment:

> If that's a problem, then the user can raise the RLIMIT_NOFILE.

This can only be raised (above the hard limit) by a privileged process,
so I would be out of luck there, as I could not convince my sysadmins
to raise this further.

Anyway, I don't really care anymore, I use my own, patched mmap module
since I filed this bug. I don't quite understand why this module made
an attempt to convert a simple mmap() to something more complex, with
hidden state and resize() methods and whatnot :) - but it has been done,
and I understand that you have to maintain backwards compatibility.

Still, it would be nice if there was some way to get the result of a
plain and simple mmap() as a buffer.

Meanwhile, I will just use my own module, so feel free to close this if
you feel like it :)

----------

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

From report at bugs.python.org  Fri Aug  2 12:20:55 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Aug 2013 10:20:55 +0000
Subject: [issue18628] PEP 8 and encodings
In-Reply-To: <1375418984.87.0.318628832877.issue18628@psf.upfronthosting.co.za>
Message-ID: <1375438855.38.0.270553464584.issue18628@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee: docs at python -> ncoghlan

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

From report at bugs.python.org  Fri Aug  2 12:22:45 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Aug 2013 10:22:45 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za>
Message-ID: <1375438965.04.0.428693984675.issue18472@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I applied Guido's update in http://hg.python.org/peps/rev/82e24ac40255

I'm not sure what happened with Guido's "Patch applied" above, but I wanted to include Terry's encoding fixes from #18628, so I figured it made sense to ensure this was included first.

----------

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

From report at bugs.python.org  Fri Aug  2 12:32:14 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Aug 2013 10:32:14 +0000
Subject: [issue18628] Better index entry for encoding declarations
In-Reply-To: <1375418984.87.0.318628832877.issue18628@psf.upfronthosting.co.za>
Message-ID: <1375439534.67.0.220882919968.issue18628@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I changed the section heading in PEP 8 to "Source File Encoding" and the sole remaining use of "a coding cookie" to "an encoding declaration". No link, since it would need separate links for Python 2 and 3, and that just gets messing. Now it uses the right terminology, it should be easier to look up.

So, this is now just a regular docs bug for Terry's third point about the (lack of a suitable) index entry :)

----------
assignee: ncoghlan -> docs at python
title: PEP 8 and encodings -> Better index entry for encoding declarations

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

From report at bugs.python.org  Fri Aug  2 14:49:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Aug 2013 12:49:29 +0000
Subject: [issue4885] mmap enhancement request
In-Reply-To: <1231445893.72.0.162990779773.issue4885@psf.upfronthosting.co.za>
Message-ID: <1375447769.65.0.942478659206.issue4885@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Aug  2 15:33:34 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 02 Aug 2013 13:33:34 +0000
Subject: [issue16499] CLI option for isolated mode
In-Reply-To: <1353248771.63.0.703024605939.issue16499@psf.upfronthosting.co.za>
Message-ID: <1375450414.35.0.926215216519.issue16499@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Nick,

you have deferred PEP 432 [1]. Do you mind if I check in the isolate mode for 3.4 and help you with PEP 432 for 3.5?


[1] http://www.python.org/dev/peps/pep-0432/#pep-deferral

----------

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

From report at bugs.python.org  Fri Aug  2 16:33:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Aug 2013 14:33:55 +0000
Subject: [issue4885] mmap enhancement request
In-Reply-To: <1231445893.72.0.162990779773.issue4885@psf.upfronthosting.co.za>
Message-ID: <1375454035.97.0.330917067637.issue4885@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks Valerie. I've tested your patch and it looks good to me.
Have you signed and sent a contributor's agreement?
http://www.python.org/psf/contrib/

----------

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

From report at bugs.python.org  Fri Aug  2 16:37:42 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Aug 2013 14:37:42 +0000
Subject: [issue18624] Add alias for iso-8859-8-i which is the same as
	iso-8859-8
In-Reply-To: <1375398269.06.0.0330535739148.issue18624@psf.upfronthosting.co.za>
Message-ID: <1375454262.69.0.534466060897.issue18624@psf.upfronthosting.co.za>


R. David Murray added the comment:

I got the impression from what I read that -e included additional control sequences, but perhaps I misunderstood and that only meant that the data stream was expected to *use* additional control sequences but the control codes themselves are part of the base codec?

I'm specifically thinking of this statement from the linked reference:

"Because HTML uses the Unicode bidirectionality algorithm, conforming documents encoded using ISO 8859-8 must be labeled as "ISO-8859-8-i". Explicit directional control is also possible with HTML, but cannot be expressed with ISO 8859-8, so "ISO-8859-8-e" should not be used."

The "cannot be expressed" seems to imply there are differences in the codec.

----------

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

From report at bugs.python.org  Fri Aug  2 17:14:16 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 02 Aug 2013 15:14:16 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za>
Message-ID: <1375456456.17.0.0567419957463.issue18472@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Sorry, I forgot the push. I had to do a little merge dance and also fixed one typo (a redundant 'line') and now it's hopefully pushed.

----------

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

From report at bugs.python.org  Fri Aug  2 17:16:53 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 15:16:53 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1375456613.31.0.987002581332.issue16853@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Here's a patch, based on the version in tulip's repo.
I've added doc update and tests.

I also made the following changes:
- BaseSelector is an abstract base class (so one could imagine user code implementing its own selector on top of it)
- SelectorKey is a named tuple: I think that's better than a class, because SelectorKeys can be returned to the user (register(), get_info(), etc), and we don't want him to mess with them. Also, we get a nice repr() for free
- since SelectorKey is immutable, I added a get_keys() method, which returns all the keys registered. Since it's a dict values, the user can't mess with it

This get_keys() method superseedes the registered_count() method, which can be simply replaced with len(selector.get_keys()). We could probably remove it? It also sort of superseedes the get_info() method: I don't remember, why was it needed?

Would it be possible to get it into 3.4?

----------
keywords: +needs review
Added file: http://bugs.python.org/file31116/selector-9.diff

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

From report at bugs.python.org  Fri Aug  2 17:16:54 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Aug 2013 15:16:54 +0000
Subject: [issue16499] CLI option for isolated mode
In-Reply-To: <1353248771.63.0.703024605939.issue16499@psf.upfronthosting.co.za>
Message-ID: <1375456614.6.0.834151435495.issue16499@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Yep, sounds good to me ("don't wait for PEP 432" is what I meant to imply above, but I wasn't very clear about it)

----------

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

From report at bugs.python.org  Fri Aug  2 17:22:11 2013
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 02 Aug 2013 15:22:11 +0000
Subject: [issue18629] future division breaks timedelta division by integer
Message-ID: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone:

datetime.timedelta instances are divisible by integers on Python 2.7, but not when __future__.division has been turned on:


exarkun at top:~$ ~/Projects/cpython/2.7/python -c '
from datetime import timedelta
print timedelta(seconds=3) / 2
'
0:00:01.500000
exarkun at top:~$ ~/Projects/cpython/2.7/python -c '
from __future__ import division
from datetime import timedelta
print timedelta(seconds=3) / 2
'
Traceback (most recent call last):
  File "<string>", line 4, in <module>
TypeError: unsupported operand type(s) for /: 'datetime.timedelta' and 'int'
exarkun at top:~$ ~/Projects/cpython/2.7/python
Python 2.7.5+ (2.7:8205e72b5cfc, Aug  2 2013, 11:12:04) 

This presents a minor barrier to Python 3 transitions, since it prevents the use of __future__.division in a module trying to retain Python 2 compatibility where timedelta division is used.

----------
components: Library (Lib)
messages: 194181
nosy: exarkun
priority: normal
severity: normal
status: open
title: future division breaks timedelta division by integer
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug  2 18:16:14 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 02 Aug 2013 16:16:14 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1375460174.15.0.394950893193.issue16853@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Thanks!  We should make sure this makes it into alpha 2.  Could you also prepare a patch for Tulip itself?  That way I can make sure Tulip works with either its own or the stdlib implementation.

One thought: would it be better if the selectors ended up in a separate module rather than extending 'select'?

----------

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

From report at bugs.python.org  Fri Aug  2 18:21:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Aug 2013 16:21:16 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375460476.41.0.86686348873.issue18629@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

You're just looking for floor division:

$ python -Qnew
Python 2.7.4 (default, Apr 19 2013, 18:28:01) 
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1/2
0.5
>>> from datetime import timedelta
>>> print timedelta(seconds=3) // 2
0:00:01.500000

----------
nosy: +pitrou

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

From report at bugs.python.org  Fri Aug  2 18:22:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Aug 2013 16:22:38 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1375460174.15.0.394950893193.issue16853@psf.upfronthosting.co.za>
Message-ID: <1722601135.39249419.1375460552816.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> One thought: would it be better if the selectors ended up in a
> separate module rather than extending 'select'?

IMHO they're fine in select. It's quite the natural place for them.

----------

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

From report at bugs.python.org  Fri Aug  2 18:27:12 2013
From: report at bugs.python.org (David Edelsohn)
Date: Fri, 02 Aug 2013 16:27:12 +0000
Subject: [issue18609] test_ctypes failure on AIX in
	PyEval_CallObjectWithKeywords
In-Reply-To: <1375305877.13.0.891928742401.issue18609@psf.upfronthosting.co.za>
Message-ID: <1375460832.2.0.901336475477.issue18609@psf.upfronthosting.co.za>


David Edelsohn added the comment:

Thanks. The patch seems to return the tests to the expected failures and Python does not crash.

----------

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

From report at bugs.python.org  Fri Aug  2 19:05:15 2013
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 02 Aug 2013 17:05:15 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375463115.11.0.701437280093.issue18629@psf.upfronthosting.co.za>


Jean-Paul Calderone added the comment:

Hm.  Maybe I am.  Yet isn't true division implemented for this pair of types in Python 3?  I'm not sure why it shouldn't be implemented for them in Python 2.

Also that raises another question.  Does a result of one and one half seconds make sense as the result of a floor division operation?

----------

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

From report at bugs.python.org  Fri Aug  2 19:12:04 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 02 Aug 2013 17:12:04 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za>
Message-ID: <1375463524.89.0.156546355607.issue18585@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

A function like this often gets called to truncate lots of lines. Unfortunately for many use-cases, the part truncated is the most significant part of the line. E.g.:

Scanning file:
/home/fred/documents/datafil...
/home/fred/documents/datafil...
/home/fred/documents/datafil...
/home/fred/documents/datafil...


It's often better in cases like this to truncate in the middle:

Scanning file:
/home/fred/doc...datafile01.txt
/home/fred/doc...datafile02.txt
/home/fred/doc...datafile03.txt
/home/fred/doc...datafile04.txt

(I believe Mac OS-X routinely truncates long lines in the middle in this way.)

Perhaps there could be an argument controlling where to truncate (left, right or centre). A good use-case for the new Enums, perhaps? :-)

----------
nosy: +stevenjd

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

From report at bugs.python.org  Fri Aug  2 19:19:04 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 02 Aug 2013 17:19:04 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za>
Message-ID: <1375463944.76.0.282905026356.issue18585@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Bike-shedding here... why "(...)"? Is it common to use round brackets for this purpose? In English-speaking countries, it is usual to use square brackets for editorial comments, including ellipsis "[...]".

Either way, if you wanted to be more Unicode aware, you could save two characters by using \N{HORIZONTAL ELLIPSIS} "(?)" as the default.

----------

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

From report at bugs.python.org  Fri Aug  2 19:40:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Aug 2013 17:40:43 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375463944.76.0.282905026356.issue18585@psf.upfronthosting.co.za>
Message-ID: <1375465235.2527.1.camel@fsol>


Antoine Pitrou added the comment:

> Bike-shedding here... why "(...)"? Is it common to use round brackets
> for this purpose? In English-speaking countries, it is usual to use
> square brackets for editorial comments, including ellipsis "[...]".

Ah, really? French uses "[...]" but I thought English-speaking people,
being different, used "(...)". So I'll change it.

> Either way, if you wanted to be more Unicode aware, you could save two
> characters by using \N{HORIZONTAL ELLIPSIS} "(?)" as the default.

I'd rather stay on the ASCII side of things here.
(also, the ellipsis character doesn't often look nice)

----------

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

From report at bugs.python.org  Fri Aug  2 19:46:22 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 02 Aug 2013 17:46:22 +0000
Subject: [issue18586] Allow running benchmarks for Python 3 from same directory
In-Reply-To: <1375112281.72.0.724142875294.issue18586@psf.upfronthosting.co.za>
Message-ID: <1375465582.69.0.759269308637.issue18586@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

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

From report at bugs.python.org  Fri Aug  2 20:08:04 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 18:08:04 +0000
Subject: [issue18630] mingw: exclude unix only modules
Message-ID: <1375466884.41.0.796204643285.issue18630@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules.

----------
components: Build
files: 0013-MINGW-exclude-unix-only-modules.patch
keywords: patch
messages: 194191
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: exclude unix only modules
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31119/0013-MINGW-exclude-unix-only-modules.patch

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

From report at bugs.python.org  Fri Aug  2 20:11:37 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 18:11:37 +0000
Subject: [issue18631] mingw: setup msvcrt and _winapi modules
Message-ID: <1375467097.24.0.168691156888.issue18631@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules.

----------
components: Build
files: 0014-MINGW-setup-msvcrt-and-_winapi-modules.patch
keywords: patch
messages: 194192
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: setup msvcrt and _winapi modules
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31120/0014-MINGW-setup-msvcrt-and-_winapi-modules.patch

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

From report at bugs.python.org  Fri Aug  2 20:15:27 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 18:15:27 +0000
Subject: [issue18632] mingw: build extensions with GCC
Message-ID: <1375467327.02.0.323723692344.issue18632@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules.
Now more simple version of previous patch.

----------
components: Build
files: 0015-MINGW-build-extensions-with-GCC.patch
keywords: patch
messages: 194193
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: build extensions with GCC
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31121/0015-MINGW-build-extensions-with-GCC.patch

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

From report at bugs.python.org  Fri Aug  2 20:40:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Aug 2013 18:40:41 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <3c6HHr2RdGzSY5@mail.python.org>


Roundup Robot added the comment:

New changeset 314a872f54e1 by Antoine Pitrou in branch 'default':
Backout 62658d9d8926 (issue #10241): it causes a crash at shutdown when deallocating a Tkapp object.
http://hg.python.org/cpython/rev/314a872f54e1

----------

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

From report at bugs.python.org  Fri Aug  2 20:42:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Aug 2013 18:42:08 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <1375468928.86.0.0430312533221.issue10241@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I backed out the changeset in time for the Alpha 1 release.
Further investigation should perhaps be made on the tkinter issue, but it's a bit cumbersome: you need a full test run in non-parallel mode to exhibit the segfault.

----------
stage: committed/rejected -> 

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

From report at bugs.python.org  Fri Aug  2 20:44:22 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 18:44:22 +0000
Subject: [issue18632] mingw: build extensions with GCC
In-Reply-To: <1375467327.02.0.323723692344.issue18632@psf.upfronthosting.co.za>
Message-ID: <1375469062.24.0.286283145019.issue18632@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Removed file: http://bugs.python.org/file31121/0015-MINGW-build-extensions-with-GCC.patch

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

From report at bugs.python.org  Fri Aug  2 20:46:04 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 18:46:04 +0000
Subject: [issue18632] mingw: build extensions with GCC
In-Reply-To: <1375467327.02.0.323723692344.issue18632@psf.upfronthosting.co.za>
Message-ID: <1375469164.31.0.589775176909.issue18632@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

Attached up to date version of patch.

----------
Added file: http://bugs.python.org/file31122/0015-MINGW-build-extensions-with-GCC.patch

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

From report at bugs.python.org  Fri Aug  2 20:55:02 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 18:55:02 +0000
Subject: [issue18633] mingw: use Mingw32CCompiler as default compiler for
	mingw* build
Message-ID: <1375469702.92.0.916914527806.issue18633@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules: improved version based  on get_platform()

----------
components: Build, Cross-Build
files: 0016-MINGW-use-Mingw32CCompiler-as-default-compiler-for-m.patch
keywords: patch
messages: 194197
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: use Mingw32CCompiler as default compiler for  mingw* build
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31123/0016-MINGW-use-Mingw32CCompiler-as-default-compiler-for-m.patch

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

From report at bugs.python.org  Fri Aug  2 21:16:45 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 19:16:45 +0000
Subject: [issue18634] mingw find import library
Message-ID: <1375471005.24.0.423283634636.issue18634@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules: required by setup.py on hosts with installed only shared (DLL) packages.

----------
components: Build, Cross-Build
files: 0017-MINGW-find-import-library.patch
keywords: patch
messages: 194198
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw find import library
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31124/0017-MINGW-find-import-library.patch

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

From report at bugs.python.org  Fri Aug  2 21:34:16 2013
From: report at bugs.python.org (Chris Lambacher)
Date: Fri, 02 Aug 2013 19:34:16 +0000
Subject: [issue18635] Enum sets _member_type_ to instantiated values but not
	the class
Message-ID: <1375472056.62.0.564467694147.issue18635@psf.upfronthosting.co.za>


New submission from Chris Lambacher:

It would be useful to set the discovered member_type to the Enum class and not just the instance. Attached is a patch to add _member_type_ to the enum_class.

----------
files: enum_member_type_on_class.patch
keywords: patch
messages: 194199
nosy: lambacck
priority: normal
severity: normal
status: open
title: Enum sets _member_type_ to instantiated values but not the class
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31125/enum_member_type_on_class.patch

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

From report at bugs.python.org  Fri Aug  2 21:35:16 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 19:35:16 +0000
Subject: [issue18636] mingw: setup _ssl module
Message-ID: <1375472116.92.0.328904140064.issue18636@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules.

----------
components: Build, Cross-Build, Extension Modules
files: 0018-MINGW-setup-_ssl-module.patch
keywords: patch
messages: 194200
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: setup _ssl module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31126/0018-MINGW-setup-_ssl-module.patch

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

From report at bugs.python.org  Fri Aug  2 21:38:29 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 19:38:29 +0000
Subject: [issue18637] mingw: export _PyNode_SizeOf as PyAPI for parser module
Message-ID: <1375472309.41.0.38535995821.issue18637@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules.

----------
components: Extension Modules, Interpreter Core
files: 0019-MINGW-export-_PyNode_SizeOf-as-PyAPI-for-parser-modu.patch
keywords: patch
messages: 194201
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: export _PyNode_SizeOf as PyAPI for parser module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31127/0019-MINGW-export-_PyNode_SizeOf-as-PyAPI-for-parser-modu.patch

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

From report at bugs.python.org  Fri Aug  2 21:42:01 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 19:42:01 +0000
Subject: [issue18638] mingw: generalization of posix build in sysconfig.py
Message-ID: <1375472521.36.0.980902141673.issue18638@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules: improved patch

----------
components: Build, Cross-Build
files: 0020-MINGW-generalization-of-posix-build-in-sysconfig.py.patch
keywords: patch
messages: 194202
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: generalization of posix build in sysconfig.py
versions: Python 3.4
Added file: http://bugs.python.org/file31128/0020-MINGW-generalization-of-posix-build-in-sysconfig.py.patch

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

From report at bugs.python.org  Fri Aug  2 21:45:43 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 19:45:43 +0000
Subject: [issue18639] mingw: avoid circular dependency from time module during
	native build of extentions
Message-ID: <1375472743.5.0.167328971816.issue18639@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules: patch is not required in cross-build environment.

----------
assignee: eric.araujo
components: Build, Distutils, Extension Modules
files: 0021-MINGW-avoid-circular-dependency-from-time-module-dur.patch
keywords: patch
messages: 194203
nosy: eric.araujo, rpetrov, tarek
priority: normal
severity: normal
status: open
title: mingw: avoid circular dependency from time module during native build of extentions
versions: Python 3.4
Added file: http://bugs.python.org/file31129/0021-MINGW-avoid-circular-dependency-from-time-module-dur.patch

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

From report at bugs.python.org  Fri Aug  2 21:49:19 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 19:49:19 +0000
Subject: [issue18640] mingw: generalization of posix build in
	distutils/sysconfig.py
Message-ID: <1375472959.93.0.699092056169.issue18640@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules: improved patch

----------
assignee: eric.araujo
components: Build, Cross-Build, Distutils, Extension Modules
files: 0022-MINGW-generalization-of-posix-build-in-distutils-sys.patch
keywords: patch
messages: 194204
nosy: eric.araujo, rpetrov, tarek
priority: normal
severity: normal
status: open
title: mingw: generalization of posix build in distutils/sysconfig.py
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31130/0022-MINGW-generalization-of-posix-build-in-distutils-sys.patch

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

From report at bugs.python.org  Fri Aug  2 21:52:05 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 19:52:05 +0000
Subject: [issue18641] mingw: customize site
Message-ID: <1375473125.37.0.800889135942.issue18641@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules: improved patch

----------
components: Build, Cross-Build, Extension Modules
files: 0023-MINGW-customize-site.patch
keywords: patch
messages: 194205
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: customize site
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31131/0023-MINGW-customize-site.patch

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

From report at bugs.python.org  Fri Aug  2 22:06:02 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 02 Aug 2013 20:06:02 +0000
Subject: [issue18635] Enum sets _member_type_ to instantiated values but not
	the class
In-Reply-To: <1375472056.62.0.564467694147.issue18635@psf.upfronthosting.co.za>
Message-ID: <1375473962.43.0.203883077075.issue18635@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman
nosy: +ethan.furman

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

From report at bugs.python.org  Fri Aug  2 22:13:50 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 02 Aug 2013 20:13:50 +0000
Subject: [issue18635] Enum sets _member_type_ to instantiated values but not
	the class
In-Reply-To: <1375472056.62.0.564467694147.issue18635@psf.upfronthosting.co.za>
Message-ID: <1375474430.1.0.56528035515.issue18635@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Ah, so the Enum class has the mixin class as wall as / instead of the Enum member (which should find it via normal attribute lookup).

I have no problem with that.  I'll need to make a couple more changes to the code, add a test, etc., etc.

It won't make the first alpha, but should be ready for the second.

----------
nosy: +barry, eli.bendersky

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

From report at bugs.python.org  Fri Aug  2 19:59:46 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 17:59:46 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1375460174.15.0.394950893193.issue16853@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2LYxuEbmg6VosWy-wbCYf3AePWdzKV5SYhX3CEmD6CKQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Thanks!  We should make sure this makes it into alpha 2.  Could you also
> prepare a patch for Tulip itself?  That way I can make sure Tulip works with
> either its own or the stdlib implementation.

Sure, here's a patch (tulip_selector_stdlib.diff).

It seems to work fine, but I'm getting random errors even with vanilla tulip:
"""
======================================================================
FAIL: test_run_until_complete_timeout (events_test.EPollEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/events_test.py", line 194, in test_run_until_complete_timeout
    self.assertTrue(0.009 <= t2-t1 <= 0.018, t2-t1)
AssertionError: False is not true : 0.0055361779959639534
"""

Looks like the timeouts check may be a bit too tight?

I'm also updating the patch a bit:
- when a timeout < 0 is passed to select(), it's treated as timeout ==
0, i.e. polling. It fixes a common kind of nasty bugs in user code
where when calculating timeouts, if you end up passing a negative
value, it can either be interpreted as an infinite wait, or can raise
EINVAL
- previously, upon EINTR (InterruptedError), select() would return an
empty list. That can be a problem if the user specified a timeout,
because you end up returning too early. Thanks to a decorator,
select() now retries upon EINTR, re-calculating the timeout. I also
added a test for this.

I'm pretty happy with the state now, so I think it's ready for review.
There are a couple points I'd like more specific feedback:
- is the registered_count() method still useful, now that get_keys()
can return all the keys?
- same thing for get_info(), it feels redundant
- the documentation ;-)

----------
Added file: http://bugs.python.org/file31117/selector-11.diff
Added file: http://bugs.python.org/file31118/tulip_selector_stdlib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________
-------------- next part --------------
diff -r 1287d4c9cd39 Lib/select.py
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Lib/select.py	Fri Aug 02 19:45:03 2013 +0200
@@ -0,0 +1,435 @@
+"""Select module.
+
+This module supports asynchronous I/O on multiple file descriptors.
+"""
+
+
+from abc import ABCMeta, abstractmethod
+from collections import namedtuple
+import functools
+from _select import *
+import sys
+try:
+    from time import monotonic as time
+except ImportError:
+    from time import time as time
+
+
+# generic events, that must be mapped to implementation-specific ones
+EVENT_READ = (1 << 0)
+EVENT_WRITE = (1 << 1)
+
+
+def _fileobj_to_fd(fileobj):
+    """Return a file descriptor from a file object.
+
+    Parameters:
+    fileobj -- file descriptor, or any object with a `fileno()` method
+
+    Returns:
+    corresponding file descriptor
+    """
+    if isinstance(fileobj, int):
+        fd = fileobj
+    else:
+        try:
+            fd = int(fileobj.fileno())
+        except (ValueError, TypeError):
+            raise ValueError("Invalid file object: {!r}".format(fileobj))
+    return fd
+
+
+def _select_interrupt_wrapper(func):
+    """InterruptedError-safe wrapper for select(), taking the (optional)
+    timeout into account."""
+    @functools.wraps(func)
+    def wrapper(self, timeout=None):
+        if timeout is not None and timeout > 0:
+            deadline = time() + timeout
+        while True:
+            try:
+                return func(self, timeout)
+            except InterruptedError:
+                if timeout is not None:
+                    if timeout > 0:
+                        timeout = deadline - time()
+                    if timeout <= 0:
+                        # timeout expired
+                        return []
+
+    return wrapper
+
+
+SelectorKey = namedtuple('SelectorKey', ['fileobj', 'fd', 'events', 'data'])
+"""Object used internally to associate a file object to its backing file
+descriptor, selected event mask and attached data."""
+
+
+class BaseSelector(metaclass=ABCMeta):
+    """Base selector class.
+
+    A selector supports registering file objects to be monitored for specific
+    I/O events.
+
+    A file object is a file descriptor or any object with a `fileno()` method.
+    An arbitrary object can be attached to the file object, which can be used
+    for example to store context information, a callback, etc.
+
+    A selector can use various implementations (select(), poll(), epoll()...)
+    depending on the platform. The default `Selector` class uses the most
+    performant implementation on the current platform.
+    """
+
+    def __init__(self):
+        # this maps file descriptors to keys
+        self._fd_to_key = {}
+        # this maps file objects to keys - for fast (un)registering
+        self._fileobj_to_key = {}
+
+    def register(self, fileobj, events, data=None):
+        """Register a file object.
+
+        Parameters:
+        fileobj -- file object
+        events  -- events to monitor (bitwise mask of EVENT_READ|EVENT_WRITE)
+        data    -- attached data
+
+        Returns:
+        SelectorKey instance
+        """
+        if (not events) or (events & ~(EVENT_READ | EVENT_WRITE)):
+            raise ValueError("Invalid events: {}".format(events))
+
+        if fileobj in self._fileobj_to_key:
+            raise ValueError("{!r} is already registered".format(fileobj))
+
+        key = SelectorKey(fileobj, _fileobj_to_fd(fileobj), events, data)
+        self._fd_to_key[key.fd] = key
+        self._fileobj_to_key[fileobj] = key
+        return key
+
+    def unregister(self, fileobj):
+        """Unregister a file object.
+
+        Parameters:
+        fileobj -- file object
+
+        Returns:
+        SelectorKey instance
+        """
+        try:
+            key = self._fileobj_to_key[fileobj]
+            del self._fd_to_key[key.fd]
+            del self._fileobj_to_key[fileobj]
+        except KeyError:
+            raise ValueError("{!r} is not registered".format(fileobj))
+        return key
+
+    def modify(self, fileobj, events, data=None):
+        """Change a registered file object monitored events or attached data.
+
+        Parameters:
+        fileobj -- file object
+        events  -- events to monitor (bitwise mask of EVENT_READ|EVENT_WRITE)
+        data    -- attached data
+        """
+        # TODO: Subclasses can probably optimize this even further.
+        try:
+            key = self._fileobj_to_key[fileobj]
+        except KeyError:
+            raise ValueError("{!r} is not registered".format(fileobj))
+        if events != key.events or data != key.data:
+            # TODO: If only the data changed, use a shortcut that only
+            # updates the data.
+            self.unregister(fileobj)
+            return self.register(fileobj, events, data)
+        else:
+            return key
+
+    @abstractmethod
+    def select(self, timeout=None):
+        """Perform the actual selection, until some monitored file objects are
+        ready or a timeout expires.
+
+        Parameters:
+        timeout -- if timeout > 0, this specifies the maximum wait time, in
+                   seconds
+                   if timeout <= 0, the select() call won't block, and will
+                   report the currently ready file objects
+                   if timeout is None, select() will block until a monitored
+                   file object becomes ready
+
+        Returns:
+        list of (fileobj, events, attached data) for ready file objects
+        `events` is a bitwise mask of EVENT_READ|EVENT_WRITE
+        """
+        raise NotImplementedError()
+
+    def close(self):
+        """Close the selector.
+
+        This must be called to make sure that any underlying resource is freed.
+        """
+        self._fd_to_key.clear()
+        self._fileobj_to_key.clear()
+
+    def get_keys(self):
+        """Return the set of SelectorKey for all the file objects
+        registered."""
+        return self._fd_to_key.values()
+
+    def get_info(self, fileobj):
+        """Return information about a registered file object.
+
+        Returns:
+        (events, data) associated to this file object
+
+        Raises KeyError if the file object is not registered.
+        """
+        try:
+            key = self._fileobj_to_key[fileobj]
+        except KeyError:
+            raise KeyError("{} is not registered".format(fileobj))
+        return key.events, key.data
+
+    def registered_count(self):
+        """Return the number of registered file objects.
+
+        Returns:
+        number of currently registered file objects
+        """
+        return len(self.get_keys())
+
+    def __enter__(self):
+        return self
+
+    def __exit__(self, *args):
+        self.close()
+
+    def _key_from_fd(self, fd):
+        """Return the key associated to a given file descriptor.
+
+        Parameters:
+        fd -- file descriptor
+
+        Returns:
+        corresponding key, or None if not found
+        """
+        try:
+            return self._fd_to_key[fd]
+        except KeyError:
+            return None
+
+
+class SelectSelector(BaseSelector):
+    """Select-based selector."""
+
+    def __init__(self):
+        super().__init__()
+        self._readers = set()
+        self._writers = set()
+
+    def register(self, fileobj, events, data=None):
+        key = super().register(fileobj, events, data)
+        if events & EVENT_READ:
+            self._readers.add(key.fd)
+        if events & EVENT_WRITE:
+            self._writers.add(key.fd)
+        return key
+
+    def unregister(self, fileobj):
+        key = super().unregister(fileobj)
+        self._readers.discard(key.fd)
+        self._writers.discard(key.fd)
+        return key
+
+    @_select_interrupt_wrapper
+    def select(self, timeout=None):
+        timeout = None if timeout is None else max(timeout, 0)
+        r, w, _ = self._select(self._readers, self._writers, [], timeout)
+        r = set(r)
+        w = set(w)
+        ready = []
+        for fd in r | w:
+            events = 0
+            if fd in r:
+                events |= EVENT_READ
+            if fd in w:
+                events |= EVENT_WRITE
+
+            key = self._key_from_fd(fd)
+            if key:
+                ready.append((key.fileobj, events & key.events, key.data))
+        return ready
+
+    if sys.platform == 'win32':
+        def _select(self, r, w, _, timeout=None):
+            r, w, x = select(r, w, w, timeout)
+            return r, w + x, []
+    else:
+        from _select import select as _select
+
+
+if 'poll' in globals():
+
+    # TODO: Implement poll() for Windows with workaround for
+    # brokenness in WSAPoll() (Richard Oudkerk, see
+    # http://bugs.python.org/issue16507).
+
+    class PollSelector(BaseSelector):
+        """Poll-based selector."""
+
+        def __init__(self):
+            super().__init__()
+            self._poll = poll()
+
+        def register(self, fileobj, events, data=None):
+            key = super().register(fileobj, events, data)
+            poll_events = 0
+            if events & EVENT_READ:
+                poll_events |= POLLIN
+            if events & EVENT_WRITE:
+                poll_events |= POLLOUT
+            self._poll.register(key.fd, poll_events)
+            return key
+
+        def unregister(self, fileobj):
+            key = super().unregister(fileobj)
+            self._poll.unregister(key.fd)
+            return key
+
+        @_select_interrupt_wrapper
+        def select(self, timeout=None):
+            timeout = None if timeout is None else max(int(1000 * timeout), 0)
+            ready = []
+            fd_event_list = self._poll.poll(timeout)
+            for fd, event in fd_event_list:
+                events = 0
+                if event & ~POLLIN:
+                    events |= EVENT_WRITE
+                if event & ~POLLOUT:
+                    events |= EVENT_READ
+
+                key = self._key_from_fd(fd)
+                if key:
+                    ready.append((key.fileobj, events & key.events, key.data))
+            return ready
+
+
+if 'epoll' in globals():
+
+    class EpollSelector(BaseSelector):
+        """Epoll-based selector."""
+
+        def __init__(self):
+            super().__init__()
+            self._epoll = epoll()
+
+        def fileno(self):
+            return self._epoll.fileno()
+
+        def register(self, fileobj, events, data=None):
+            key = super().register(fileobj, events, data)
+            epoll_events = 0
+            if events & EVENT_READ:
+                epoll_events |= EPOLLIN
+            if events & EVENT_WRITE:
+                epoll_events |= EPOLLOUT
+            self._epoll.register(key.fd, epoll_events)
+            return key
+
+        def unregister(self, fileobj):
+            key = super().unregister(fileobj)
+            self._epoll.unregister(key.fd)
+            return key
+
+        @_select_interrupt_wrapper
+        def select(self, timeout=None):
+            timeout = -1 if timeout is None else max(timeout, 0)
+            max_ev = len(self.get_keys())
+            ready = []
+            fd_event_list = self._epoll.poll(timeout, max_ev)
+            for fd, event in fd_event_list:
+                events = 0
+                if event & ~EPOLLIN:
+                    events |= EVENT_WRITE
+                if event & ~EPOLLOUT:
+                    events |= EVENT_READ
+
+                key = self._key_from_fd(fd)
+                if key:
+                    ready.append((key.fileobj, events & key.events, key.data))
+            return ready
+
+        def close(self):
+            super().close()
+            self._epoll.close()
+
+
+if 'kqueue' in globals():
+
+    class KqueueSelector(BaseSelector):
+        """Kqueue-based selector."""
+
+        def __init__(self):
+            super().__init__()
+            self._kqueue = kqueue()
+
+        def fileno(self):
+            return self._kqueue.fileno()
+
+        def unregister(self, fileobj):
+            key = super().unregister(fileobj)
+            if key.events & EVENT_READ:
+                kev = kevent(key.fd, KQ_FILTER_READ, KQ_EV_DELETE)
+                self._kqueue.control([kev], 0, 0)
+            if key.events & EVENT_WRITE:
+                kev = kevent(key.fd, KQ_FILTER_WRITE, KQ_EV_DELETE)
+                self._kqueue.control([kev], 0, 0)
+            return key
+
+        def register(self, fileobj, events, data=None):
+            key = super().register(fileobj, events, data)
+            if events & EVENT_READ:
+                kev = kevent(key.fd, KQ_FILTER_READ, KQ_EV_ADD)
+                self._kqueue.control([kev], 0, 0)
+            if events & EVENT_WRITE:
+                kev = kevent(key.fd, KQ_FILTER_WRITE, KQ_EV_ADD)
+                self._kqueue.control([kev], 0, 0)
+            return key
+
+        @_select_interrupt_wrapper
+        def select(self, timeout=None):
+            timeout = None if timeout is None else max(timeout, 0)
+            max_ev = len(self.get_keys())
+            ready = []
+            kev_list = self._kqueue.control(None, max_ev, timeout)
+            for kev in kev_list:
+                fd = kev.ident
+                flag = kev.filter
+                events = 0
+                if flag == KQ_FILTER_READ:
+                    events |= EVENT_READ
+                if flag == KQ_FILTER_WRITE:
+                    events |= EVENT_WRITE
+
+                key = self._key_from_fd(fd)
+                if key:
+                    ready.append((key.fileobj, events & key.events, key.data))
+            return ready
+
+        def close(self):
+            super().close()
+            self._kqueue.close()
+
+
+# Choose the best implementation: roughly, epoll|kqueue > poll > select.
+# select() also can't accept a FD > FD_SETSIZE (usually around 1024)
+if 'KqueueSelector' in globals():
+    DefaultSelector = KqueueSelector
+elif 'EpollSelector' in globals():
+    DefaultSelector = EpollSelector
+elif 'PollSelector' in globals():
+    DefaultSelector = PollSelector
+else:
+    DefaultSelector = SelectSelector
diff -r 1287d4c9cd39 Lib/test/test_select.py
--- a/Lib/test/test_select.py	Fri Aug 02 10:22:07 2013 +0200
+++ b/Lib/test/test_select.py	Fri Aug 02 19:45:03 2013 +0200
@@ -1,9 +1,28 @@
 import errno
 import os
+import random
 import select
+import signal
 import sys
 import unittest
 from test import support
+try:
+    from time import monotonic as time
+except ImportError:
+    from time import time as time
+try:
+    import resource
+except ImportError:
+    resource = None
+
+
+def find_ready_matching(ready, flag):
+    match = []
+    for fd, mode, data in ready:
+        if mode & flag:
+            match.append(fd)
+    return match
+
 
 @unittest.skipIf((sys.platform[:3]=='win'),
                  "can't easily test on this system")
@@ -75,9 +94,379 @@
         a[:] = [F()] * 10
         self.assertEqual(select.select([], a, []), ([], a[:5], []))
 
+
+class BaseSelectorTestCase(unittest.TestCase):
+
+    def test_register(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = os.pipe()
+        self.addCleanup(os.close, rd)
+        self.addCleanup(os.close, wr)
+        rdo = os.fdopen(rd, "rb", closefd=False)
+
+        key = s.register(rdo, select.EVENT_READ, "data")
+        self.assertIsInstance(key, select.SelectorKey)
+        self.assertEqual(key.fileobj, rdo)
+        self.assertEqual(key.fd, rd)
+        self.assertEqual(key.data, "data")
+
+        # register an unknown event
+        self.assertRaises(ValueError, s.register, 0, 999999)
+
+        # register twice
+        self.assertRaises(ValueError, s.register, rdo, select.EVENT_READ)
+
+    def test_unregister(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = os.pipe()
+        self.addCleanup(os.close, rd)
+        self.addCleanup(os.close, wr)
+
+        s.register(rd, select.EVENT_READ)
+        s.unregister(rd)
+        self.assertFalse(s.get_keys())
+
+        # unregister an unknown file obj
+        self.assertRaises(ValueError, s.unregister, 999999)
+
+        # unregister twice
+        self.assertRaises(ValueError, s.unregister, rd)
+
+    def test_modify(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = os.pipe()
+        self.addCleanup(os.close, rd)
+        self.addCleanup(os.close, wr)
+
+        key = s.register(rd, select.EVENT_READ)
+
+        # modify events
+        key2 = s.modify(rd, select.EVENT_WRITE)
+        self.assertNotEqual(key.events, key2.events)
+        self.assertEqual((select.EVENT_WRITE, None), s.get_info(rd))
+
+        s.unregister(rd)
+
+        # modify data
+        d1 = object()
+        d2 = object()
+
+        key = s.register(rd, select.EVENT_READ, d1)
+        key2 = s.modify(rd, select.EVENT_READ, d2)
+        self.assertEqual(key.events, key2.events)
+        self.assertNotEqual(key.data, key2.data)
+        self.assertEqual((select.EVENT_READ, d2), s.get_info(rd))
+
+        # modify unknown file obj
+        self.assertRaises(ValueError, s.modify, 999999, select.EVENT_READ)
+
+    def test_close(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = os.pipe()
+        self.addCleanup(os.close, rd)
+        self.addCleanup(os.close, wr)
+
+        s.register(rd, select.EVENT_READ)
+        s.register(wr, select.EVENT_WRITE)
+
+        s.close()
+        self.assertFalse(s.get_keys())
+
+    def test_get_keys(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = os.pipe()
+        self.addCleanup(os.close, rd)
+        self.addCleanup(os.close, wr)
+        rdo = os.fdopen(rd, "rb", closefd=False)
+        wro = os.fdopen(wr, "wb", closefd=False)
+
+        s.register(rdo, select.EVENT_READ, "rdo")
+        s.register(wro, select.EVENT_WRITE, "wro")
+
+        self.assertEqual(set(s.get_keys()),
+                set([select.SelectorKey(rdo, rd, select.EVENT_READ, "rdo"),
+                     select.SelectorKey(wro, wr, select.EVENT_WRITE, "wro")]))
+
+        s.close()
+        self.assertFalse(s.get_keys())
+
+    def test_get_info(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = os.pipe()
+        self.addCleanup(os.close, rd)
+        self.addCleanup(os.close, wr)
+
+        s.register(rd, select.EVENT_READ, "data")
+        self.assertEqual((select.EVENT_READ, "data"), s.get_info(rd))
+ 
+        # unknown file obj
+        self.assertRaises(KeyError, s.get_info, 999999)
+
+    def test_registered_count(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = os.pipe()
+        self.addCleanup(os.close, rd)
+        self.addCleanup(os.close, wr)
+
+        self.assertEqual(0, s.registered_count())
+
+        s.register(rd, select.EVENT_READ)
+        s.register(wr, select.EVENT_WRITE)
+        self.assertEqual(2, s.registered_count())
+
+        s.unregister(rd)
+        s.unregister(wr)
+        self.assertEqual(0, s.registered_count())
+
+    def test_context_manager(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = os.pipe()
+        self.addCleanup(os.close, rd)
+        self.addCleanup(os.close, wr)
+
+        with s as sel:
+            sel.register(rd, select.EVENT_READ)
+            sel.register(wr, select.EVENT_WRITE)
+
+        self.assertFalse(s.get_keys())
+
+    @unittest.skipUnless(hasattr(select.DefaultSelector, 'fileno'),
+                        'test needs DefaultSelector.fileno()')
+    def test_fileno(self):
+        self.assertIsInstance(select.DefaultSelector().fileno(), int)
+
+    def test_selector(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        NUM_PIPES = 12
+        MSG = b" This is a test."
+        MSG_LEN = len(MSG)
+        readers = []
+        writers = []
+        r2w = {}
+        w2r = {}
+
+        for i in range(NUM_PIPES):
+            rd, wr = os.pipe()
+            s.register(rd, select.EVENT_READ)
+            s.register(wr, select.EVENT_WRITE)
+            readers.append(rd)
+            writers.append(wr)
+            r2w[rd] = wr
+            w2r[wr] = rd
+
+        bufs = []
+
+        while writers:
+            ready = s.select()
+            ready_writers = find_ready_matching(ready, select.EVENT_WRITE)
+            if not ready_writers:
+                self.fail("no pipes ready for writing")
+            wr = random.choice(ready_writers)
+            os.write(wr, MSG)
+
+            ready = s.select()
+            ready_readers = find_ready_matching(ready, select.EVENT_READ)
+            if not ready_readers:
+                self.fail("no pipes ready for reading")
+            self.assertEqual([w2r[wr]], ready_readers)
+            rd = ready_readers[0]
+            buf = os.read(rd, MSG_LEN)
+            self.assertEqual(len(buf), MSG_LEN)
+            bufs.append(buf)
+            os.close(r2w[rd]) ; os.close(rd)
+            s.unregister(r2w[rd])
+            s.unregister(rd)
+            writers.remove(r2w[rd])
+
+        self.assertEqual(bufs, [MSG] * NUM_PIPES)
+
+    def test_multi_timeout(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        cmd = 'for i in 0 1 2 3 4 5 6 7 8 9; do echo testing...; sleep 1; done'
+        p = os.popen(cmd, 'r')
+        s.register(p.fileno(), select.EVENT_READ, p)
+
+        for tout in (0, 1, 2, 4, 8, 16) + (None,)*10:
+            if support.verbose:
+                print('timeout =', tout)
+
+            ready = s.select(tout)
+            if not ready:
+                continue
+            eof_seen = False
+            for fileobj, evt, data in ready:
+                if fileobj == p.fileno() and evt & select.EVENT_READ:
+                    while True:
+                        line = p.readline()
+                        if support.verbose:
+                            print(repr(line))
+                        if not line:
+                            if support.verbose:
+                                print('EOF')
+                            eof_seen = True
+                            break
+            if not eof_seen:
+                self.fail('Unexpected return values from select(): %r' % ready)
+        p.close()
+
+    def test_below_fd_setsize(self):
+        # No implementation should have a problem with less than FD_SETSIZE
+        # file descriptors. To be conservative, let's say 64.
+        NUM_FDS = 64
+
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        r, w = os.pipe()
+        self.addCleanup(os.close, r)
+        self.addCleanup(os.close, w)
+
+        for i in range(NUM_FDS):
+            fd = os.dup(w)
+            self.addCleanup(os.close, fd)
+
+            s.register(fd, select.EVENT_WRITE)
+        self.assertEquals(NUM_FDS, len(s.select()))
+
+    def test_timeout(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = os.pipe()
+        self.addCleanup(os.close, rd)
+        self.addCleanup(os.close, wr)
+
+        s.register(wr, select.EVENT_WRITE)
+        self.assertEqual(1, len(s.select(0)))
+        self.assertEqual(1, len(s.select(-1)))
+ 
+        s.unregister(wr)
+        s.register(rd, select.EVENT_READ)
+        self.assertEqual(0, len(s.select(0)))
+        self.assertEqual(0, len(s.select(-1)))
+
+    @unittest.skipUnless(hasattr(signal, "alarm"),
+                         "signal.alarm() required for this test")
+    def test_interrupted(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = os.pipe()
+        self.addCleanup(os.close, rd)
+        self.addCleanup(os.close, wr)
+
+        orig_alrm_handler = signal.signal(signal.SIGALRM, lambda *args: None)
+        self.addCleanup(signal.alarm, 0)
+        self.addCleanup(signal.signal, signal.SIGALRM, orig_alrm_handler)
+
+        signal.alarm(1)
+
+        s.register(rd, select.EVENT_READ)
+        t = time()
+        self.assertEqual([], s.select(2))
+        self.assertTrue(1.7 < time() - t < 3)
+
+
+class ScalableSelectorMixIn:
+
+    @unittest.skipUnless(resource, "Test needs resource module")
+    def test_above_fd_setsize(self):
+        # A scalable implementation should have no problem with more than
+        # FD_SETSIZE file descriptors. Since we don't know the value, we just
+        # try to set the soft RLIMIT_NOFILE to the hard RLIMIT_NOFILE ceiling.
+        try:
+            soft, hard = resource.getrlimit(resource.RLIMIT_NOFILE)
+            resource.setrlimit(resource.RLIMIT_NOFILE, (hard, hard))
+            self.addCleanup(resource.setrlimit, resource.RLIMIT_NOFILE,
+                            (soft, hard))
+            NUM_FDS = hard
+        except OSError:
+            NUM_FDS = soft
+
+        # guard for already allocated FDs (stdin, stdout...)
+        NUM_FDS -= 32
+
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        r, w = os.pipe()
+        self.addCleanup(os.close, r)
+        self.addCleanup(os.close, w)
+
+        for i in range(NUM_FDS):
+            try:
+                fd = os.dup(w)
+            except OSError as e:
+                if e.errno == errno.EMFILE:
+                    # too many FD, skip
+                    self.skipTest("FD limit reached")
+                raise
+
+            self.addCleanup(os.close, fd)
+            s.register(fd, select.EVENT_WRITE)
+
+        self.assertEquals(NUM_FDS, len(s.select()))
+
+
+class SelectorTestCase(BaseSelectorTestCase):
+
+    SELECTOR = select.DefaultSelector
+
+
+class SelectSelectorTestCase(BaseSelectorTestCase):
+
+    SELECTOR = select.SelectSelector
+
+
+ at unittest.skipUnless(hasattr(select, 'PollSelector'),
+                    "Test needs select.poll()")
+class PollSelectorTestCase(BaseSelectorTestCase, ScalableSelectorMixIn):
+
+    SELECTOR = getattr(select, 'PollSelector', None)
+
+
+ at unittest.skipUnless(hasattr(select, 'EpollSelector'),
+                     "Test needs select.epoll()")
+class EpollSelectorTestCase(BaseSelectorTestCase, ScalableSelectorMixIn):
+
+    SELECTOR = getattr(select, 'EpollSelector', None)
+
+
+ at unittest.skipUnless(hasattr(select, 'KqueueSelector'),
+                    "Test needs select.kqueue()")
+class KqueueSelectorTestCase(BaseSelectorTestCase, ScalableSelectorMixIn):
+
+    SELECTOR = getattr(select, 'KqueueSelector', None)
+
+
 def test_main():
-    support.run_unittest(SelectTestCase)
+    tests = [SelectTestCase]
+    tests.extend([SelectorTestCase, SelectSelectorTestCase,
+                  PollSelectorTestCase, EpollSelectorTestCase,
+                  KqueueSelectorTestCase])
+    support.run_unittest(*tests)
     support.reap_children()
 
+
 if __name__ == "__main__":
     test_main()
diff -r 1287d4c9cd39 Modules/Setup.dist
--- a/Modules/Setup.dist	Fri Aug 02 10:22:07 2013 +0200
+++ b/Modules/Setup.dist	Fri Aug 02 19:45:03 2013 +0200
@@ -188,7 +188,7 @@
 #fcntl fcntlmodule.c	# fcntl(2) and ioctl(2)
 #spwd spwdmodule.c		# spwd(3) 
 #grp grpmodule.c		# grp(3)
-#select selectmodule.c	# select(2); not on ancient System V
+#_select _selectmodule.c	# select(2); not on ancient System V
 
 # Memory-mapped files (also works on Win32).
 #mmap mmapmodule.c
diff -r 1287d4c9cd39 Modules/_selectmodule.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Modules/_selectmodule.c	Fri Aug 02 19:45:03 2013 +0200
@@ -0,0 +1,2334 @@
+/* select - Module containing unix select(2) call.
+   Under Unix, the file descriptors are small integers.
+   Under Win32, select only exists for sockets, and sockets may
+   have any value except INVALID_SOCKET.
+*/
+
+#include "Python.h"
+#include <structmember.h>
+
+#ifdef HAVE_SYS_DEVPOLL_H
+#include <sys/resource.h>
+#include <sys/devpoll.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#endif
+
+#ifdef __APPLE__
+    /* Perform runtime testing for a broken poll on OSX to make it easier
+     * to use the same binary on multiple releases of the OS.
+     */
+#undef HAVE_BROKEN_POLL
+#endif
+
+/* Windows #defines FD_SETSIZE to 64 if FD_SETSIZE isn't already defined.
+   64 is too small (too many people have bumped into that limit).
+   Here we boost it.
+   Users who want even more than the boosted limit should #define
+   FD_SETSIZE higher before this; e.g., via compiler /D switch.
+*/
+#if defined(MS_WINDOWS) && !defined(FD_SETSIZE)
+#define FD_SETSIZE 512
+#endif
+
+#if defined(HAVE_POLL_H)
+#include <poll.h>
+#elif defined(HAVE_SYS_POLL_H)
+#include <sys/poll.h>
+#endif
+
+#ifdef __sgi
+/* This is missing from unistd.h */
+extern void bzero(void *, int);
+#endif
+
+#ifdef HAVE_SYS_TYPES_H
+#include <sys/types.h>
+#endif
+
+#ifdef MS_WINDOWS
+#  define WIN32_LEAN_AND_MEAN
+#  include <winsock.h>
+#else
+#  define SOCKET int
+#  if defined(__VMS)
+#    include <socket.h>
+#  endif
+#endif
+
+/* list of Python objects and their file descriptor */
+typedef struct {
+    PyObject *obj;                           /* owned reference */
+    SOCKET fd;
+    int sentinel;                            /* -1 == sentinel */
+} pylist;
+
+static void
+reap_obj(pylist fd2obj[FD_SETSIZE + 1])
+{
+    int i;
+    for (i = 0; i < FD_SETSIZE + 1 && fd2obj[i].sentinel >= 0; i++) {
+        Py_XDECREF(fd2obj[i].obj);
+        fd2obj[i].obj = NULL;
+    }
+    fd2obj[0].sentinel = -1;
+}
+
+
+/* returns -1 and sets the Python exception if an error occurred, otherwise
+   returns a number >= 0
+*/
+static int
+seq2set(PyObject *seq, fd_set *set, pylist fd2obj[FD_SETSIZE + 1])
+{
+    int max = -1;
+    int index = 0;
+    Py_ssize_t i;
+    PyObject* fast_seq = NULL;
+    PyObject* o = NULL;
+
+    fd2obj[0].obj = (PyObject*)0;            /* set list to zero size */
+    FD_ZERO(set);
+
+    fast_seq = PySequence_Fast(seq, "arguments 1-3 must be sequences");
+    if (!fast_seq)
+        return -1;
+
+    for (i = 0; i < PySequence_Fast_GET_SIZE(fast_seq); i++)  {
+        SOCKET v;
+
+        /* any intervening fileno() calls could decr this refcnt */
+        if (!(o = PySequence_Fast_GET_ITEM(fast_seq, i)))
+            goto finally;
+
+        Py_INCREF(o);
+        v = PyObject_AsFileDescriptor( o );
+        if (v == -1) goto finally;
+
+#if defined(_MSC_VER)
+        max = 0;                             /* not used for Win32 */
+#else  /* !_MSC_VER */
+        if (!_PyIsSelectable_fd(v)) {
+            PyErr_SetString(PyExc_ValueError,
+                        "filedescriptor out of range in select()");
+            goto finally;
+        }
+        if (v > max)
+            max = v;
+#endif /* _MSC_VER */
+        FD_SET(v, set);
+
+        /* add object and its file descriptor to the list */
+        if (index >= FD_SETSIZE) {
+            PyErr_SetString(PyExc_ValueError,
+                          "too many file descriptors in select()");
+            goto finally;
+        }
+        fd2obj[index].obj = o;
+        fd2obj[index].fd = v;
+        fd2obj[index].sentinel = 0;
+        fd2obj[++index].sentinel = -1;
+    }
+    Py_DECREF(fast_seq);
+    return max+1;
+
+  finally:
+    Py_XDECREF(o);
+    Py_DECREF(fast_seq);
+    return -1;
+}
+
+/* returns NULL and sets the Python exception if an error occurred */
+static PyObject *
+set2list(fd_set *set, pylist fd2obj[FD_SETSIZE + 1])
+{
+    int i, j, count=0;
+    PyObject *list, *o;
+    SOCKET fd;
+
+    for (j = 0; fd2obj[j].sentinel >= 0; j++) {
+        if (FD_ISSET(fd2obj[j].fd, set))
+            count++;
+    }
+    list = PyList_New(count);
+    if (!list)
+        return NULL;
+
+    i = 0;
+    for (j = 0; fd2obj[j].sentinel >= 0; j++) {
+        fd = fd2obj[j].fd;
+        if (FD_ISSET(fd, set)) {
+            o = fd2obj[j].obj;
+            fd2obj[j].obj = NULL;
+            /* transfer ownership */
+            if (PyList_SetItem(list, i, o) < 0)
+                goto finally;
+
+            i++;
+        }
+    }
+    return list;
+  finally:
+    Py_DECREF(list);
+    return NULL;
+}
+
+#undef SELECT_USES_HEAP
+#if FD_SETSIZE > 1024
+#define SELECT_USES_HEAP
+#endif /* FD_SETSIZE > 1024 */
+
+static PyObject *
+select_select(PyObject *self, PyObject *args)
+{
+#ifdef SELECT_USES_HEAP
+    pylist *rfd2obj, *wfd2obj, *efd2obj;
+#else  /* !SELECT_USES_HEAP */
+    /* XXX: All this should probably be implemented as follows:
+     * - find the highest descriptor we're interested in
+     * - add one
+     * - that's the size
+     * See: Stevens, APitUE, $12.5.1
+     */
+    pylist rfd2obj[FD_SETSIZE + 1];
+    pylist wfd2obj[FD_SETSIZE + 1];
+    pylist efd2obj[FD_SETSIZE + 1];
+#endif /* SELECT_USES_HEAP */
+    PyObject *ifdlist, *ofdlist, *efdlist;
+    PyObject *ret = NULL;
+    PyObject *tout = Py_None;
+    fd_set ifdset, ofdset, efdset;
+    struct timeval tv, *tvp;
+    int imax, omax, emax, max;
+    int n;
+
+    /* convert arguments */
+    if (!PyArg_UnpackTuple(args, "select", 3, 4,
+                          &ifdlist, &ofdlist, &efdlist, &tout))
+        return NULL;
+
+    if (tout == Py_None)
+        tvp = (struct timeval *)0;
+    else if (!PyNumber_Check(tout)) {
+        PyErr_SetString(PyExc_TypeError,
+                        "timeout must be a float or None");
+        return NULL;
+    }
+    else {
+#ifdef MS_WINDOWS
+        time_t sec;
+        if (_PyTime_ObjectToTimeval(tout, &sec, &tv.tv_usec) == -1)
+            return NULL;
+        assert(sizeof(tv.tv_sec) == sizeof(long));
+#if SIZEOF_TIME_T > SIZEOF_LONG
+        if (sec > LONG_MAX) {
+            PyErr_SetString(PyExc_OverflowError,
+                            "timeout is too large");
+            return NULL;
+        }
+#endif
+        tv.tv_sec = (long)sec;
+#else
+        /* 64-bit OS X has struct timeval.tv_usec as an int (and thus still 4
+           bytes as required), but no longer defined by a long. */
+        long tv_usec;
+        if (_PyTime_ObjectToTimeval(tout, &tv.tv_sec, &tv_usec) == -1)
+            return NULL;
+        tv.tv_usec = tv_usec;
+#endif
+        if (tv.tv_sec < 0) {
+            PyErr_SetString(PyExc_ValueError, "timeout must be non-negative");
+            return NULL;
+        }
+        tvp = &tv;
+    }
+
+
+#ifdef SELECT_USES_HEAP
+    /* Allocate memory for the lists */
+    rfd2obj = PyMem_NEW(pylist, FD_SETSIZE + 1);
+    wfd2obj = PyMem_NEW(pylist, FD_SETSIZE + 1);
+    efd2obj = PyMem_NEW(pylist, FD_SETSIZE + 1);
+    if (rfd2obj == NULL || wfd2obj == NULL || efd2obj == NULL) {
+        if (rfd2obj) PyMem_DEL(rfd2obj);
+        if (wfd2obj) PyMem_DEL(wfd2obj);
+        if (efd2obj) PyMem_DEL(efd2obj);
+        return PyErr_NoMemory();
+    }
+#endif /* SELECT_USES_HEAP */
+    /* Convert sequences to fd_sets, and get maximum fd number
+     * propagates the Python exception set in seq2set()
+     */
+    rfd2obj[0].sentinel = -1;
+    wfd2obj[0].sentinel = -1;
+    efd2obj[0].sentinel = -1;
+    if ((imax=seq2set(ifdlist, &ifdset, rfd2obj)) < 0)
+        goto finally;
+    if ((omax=seq2set(ofdlist, &ofdset, wfd2obj)) < 0)
+        goto finally;
+    if ((emax=seq2set(efdlist, &efdset, efd2obj)) < 0)
+        goto finally;
+    max = imax;
+    if (omax > max) max = omax;
+    if (emax > max) max = emax;
+
+    Py_BEGIN_ALLOW_THREADS
+    n = select(max, &ifdset, &ofdset, &efdset, tvp);
+    Py_END_ALLOW_THREADS
+
+#ifdef MS_WINDOWS
+    if (n == SOCKET_ERROR) {
+        PyErr_SetExcFromWindowsErr(PyExc_OSError, WSAGetLastError());
+    }
+#else
+    if (n < 0) {
+        PyErr_SetFromErrno(PyExc_OSError);
+    }
+#endif
+    else {
+        /* any of these three calls can raise an exception.  it's more
+           convenient to test for this after all three calls... but
+           is that acceptable?
+        */
+        ifdlist = set2list(&ifdset, rfd2obj);
+        ofdlist = set2list(&ofdset, wfd2obj);
+        efdlist = set2list(&efdset, efd2obj);
+        if (PyErr_Occurred())
+            ret = NULL;
+        else
+            ret = PyTuple_Pack(3, ifdlist, ofdlist, efdlist);
+
+        Py_XDECREF(ifdlist);
+        Py_XDECREF(ofdlist);
+        Py_XDECREF(efdlist);
+    }
+
+  finally:
+    reap_obj(rfd2obj);
+    reap_obj(wfd2obj);
+    reap_obj(efd2obj);
+#ifdef SELECT_USES_HEAP
+    PyMem_DEL(rfd2obj);
+    PyMem_DEL(wfd2obj);
+    PyMem_DEL(efd2obj);
+#endif /* SELECT_USES_HEAP */
+    return ret;
+}
+
+#if defined(HAVE_POLL) && !defined(HAVE_BROKEN_POLL)
+/*
+ * poll() support
+ */
+
+typedef struct {
+    PyObject_HEAD
+    PyObject *dict;
+    int ufd_uptodate;
+    int ufd_len;
+    struct pollfd *ufds;
+} pollObject;
+
+static PyTypeObject poll_Type;
+
+/* Update the malloc'ed array of pollfds to match the dictionary
+   contained within a pollObject.  Return 1 on success, 0 on an error.
+*/
+
+static int
+update_ufd_array(pollObject *self)
+{
+    Py_ssize_t i, pos;
+    PyObject *key, *value;
+    struct pollfd *old_ufds = self->ufds;
+
+    self->ufd_len = PyDict_Size(self->dict);
+    PyMem_RESIZE(self->ufds, struct pollfd, self->ufd_len);
+    if (self->ufds == NULL) {
+        self->ufds = old_ufds;
+        PyErr_NoMemory();
+        return 0;
+    }
+
+    i = pos = 0;
+    while (PyDict_Next(self->dict, &pos, &key, &value)) {
+        assert(i < self->ufd_len);
+        /* Never overflow */
+        self->ufds[i].fd = (int)PyLong_AsLong(key);
+        self->ufds[i].events = (short)PyLong_AsLong(value);
+        i++;
+    }
+    assert(i == self->ufd_len);
+    self->ufd_uptodate = 1;
+    return 1;
+}
+
+PyDoc_STRVAR(poll_register_doc,
+"register(fd [, eventmask] ) -> None\n\n\
+Register a file descriptor with the polling object.\n\
+fd -- either an integer, or an object with a fileno() method returning an\n\
+      int.\n\
+events -- an optional bitmask describing the type of events to check for");
+
+static PyObject *
+poll_register(pollObject *self, PyObject *args)
+{
+    PyObject *o, *key, *value;
+    int fd;
+    short events = POLLIN | POLLPRI | POLLOUT;
+    int err;
+
+    if (!PyArg_ParseTuple(args, "O|h:register", &o, &events)) {
+        return NULL;
+    }
+
+    fd = PyObject_AsFileDescriptor(o);
+    if (fd == -1) return NULL;
+
+    /* Add entry to the internal dictionary: the key is the
+       file descriptor, and the value is the event mask. */
+    key = PyLong_FromLong(fd);
+    if (key == NULL)
+        return NULL;
+    value = PyLong_FromLong(events);
+    if (value == NULL) {
+        Py_DECREF(key);
+        return NULL;
+    }
+    err = PyDict_SetItem(self->dict, key, value);
+    Py_DECREF(key);
+    Py_DECREF(value);
+    if (err < 0)
+        return NULL;
+
+    self->ufd_uptodate = 0;
+
+    Py_INCREF(Py_None);
+    return Py_None;
+}
+
+PyDoc_STRVAR(poll_modify_doc,
+"modify(fd, eventmask) -> None\n\n\
+Modify an already registered file descriptor.\n\
+fd -- either an integer, or an object with a fileno() method returning an\n\
+      int.\n\
+events -- an optional bitmask describing the type of events to check for");
+
+static PyObject *
+poll_modify(pollObject *self, PyObject *args)
+{
+    PyObject *o, *key, *value;
+    int fd, events;
+    int err;
+
+    if (!PyArg_ParseTuple(args, "Oi:modify", &o, &events)) {
+        return NULL;
+    }
+
+    fd = PyObject_AsFileDescriptor(o);
+    if (fd == -1) return NULL;
+
+    /* Modify registered fd */
+    key = PyLong_FromLong(fd);
+    if (key == NULL)
+        return NULL;
+    if (PyDict_GetItem(self->dict, key) == NULL) {
+        errno = ENOENT;
+        PyErr_SetFromErrno(PyExc_OSError);
+        Py_DECREF(key);
+        return NULL;
+    }
+    value = PyLong_FromLong(events);
+    if (value == NULL) {
+        Py_DECREF(key);
+        return NULL;
+    }
+    err = PyDict_SetItem(self->dict, key, value);
+    Py_DECREF(key);
+    Py_DECREF(value);
+    if (err < 0)
+        return NULL;
+
+    self->ufd_uptodate = 0;
+
+    Py_INCREF(Py_None);
+    return Py_None;
+}
+
+
+PyDoc_STRVAR(poll_unregister_doc,
+"unregister(fd) -> None\n\n\
+Remove a file descriptor being tracked by the polling object.");
+
+static PyObject *
+poll_unregister(pollObject *self, PyObject *o)
+{
+    PyObject *key;
+    int fd;
+
+    fd = PyObject_AsFileDescriptor( o );
+    if (fd == -1)
+        return NULL;
+
+    /* Check whether the fd is already in the array */
+    key = PyLong_FromLong(fd);
+    if (key == NULL)
+        return NULL;
+
+    if (PyDict_DelItem(self->dict, key) == -1) {
+        Py_DECREF(key);
+        /* This will simply raise the KeyError set by PyDict_DelItem
+           if the file descriptor isn't registered. */
+        return NULL;
+    }
+
+    Py_DECREF(key);
+    self->ufd_uptodate = 0;
+
+    Py_INCREF(Py_None);
+    return Py_None;
+}
+
+PyDoc_STRVAR(poll_poll_doc,
+"poll( [timeout] ) -> list of (fd, event) 2-tuples\n\n\
+Polls the set of registered file descriptors, returning a list containing \n\
+any descriptors that have events or errors to report.");
+
+static PyObject *
+poll_poll(pollObject *self, PyObject *args)
+{
+    PyObject *result_list = NULL, *tout = NULL;
+    int timeout = 0, poll_result, i, j;
+    PyObject *value = NULL, *num = NULL;
+
+    if (!PyArg_UnpackTuple(args, "poll", 0, 1, &tout)) {
+        return NULL;
+    }
+
+    /* Check values for timeout */
+    if (tout == NULL || tout == Py_None)
+        timeout = -1;
+    else if (!PyNumber_Check(tout)) {
+        PyErr_SetString(PyExc_TypeError,
+                        "timeout must be an integer or None");
+        return NULL;
+    }
+    else {
+        tout = PyNumber_Long(tout);
+        if (!tout)
+            return NULL;
+        timeout = _PyLong_AsInt(tout);
+        Py_DECREF(tout);
+        if (timeout == -1 && PyErr_Occurred())
+            return NULL;
+    }
+
+    /* Ensure the ufd array is up to date */
+    if (!self->ufd_uptodate)
+        if (update_ufd_array(self) == 0)
+            return NULL;
+
+    /* call poll() */
+    Py_BEGIN_ALLOW_THREADS
+    poll_result = poll(self->ufds, self->ufd_len, timeout);
+    Py_END_ALLOW_THREADS
+
+    if (poll_result < 0) {
+        PyErr_SetFromErrno(PyExc_OSError);
+        return NULL;
+    }
+
+    /* build the result list */
+
+    result_list = PyList_New(poll_result);
+    if (!result_list)
+        return NULL;
+    else {
+        for (i = 0, j = 0; j < poll_result; j++) {
+            /* skip to the next fired descriptor */
+            while (!self->ufds[i].revents) {
+                i++;
+            }
+            /* if we hit a NULL return, set value to NULL
+               and break out of loop; code at end will
+               clean up result_list */
+            value = PyTuple_New(2);
+            if (value == NULL)
+                goto error;
+            num = PyLong_FromLong(self->ufds[i].fd);
+            if (num == NULL) {
+                Py_DECREF(value);
+                goto error;
+            }
+            PyTuple_SET_ITEM(value, 0, num);
+
+            /* The &0xffff is a workaround for AIX.  'revents'
+               is a 16-bit short, and IBM assigned POLLNVAL
+               to be 0x8000, so the conversion to int results
+               in a negative number. See SF bug #923315. */
+            num = PyLong_FromLong(self->ufds[i].revents & 0xffff);
+            if (num == NULL) {
+                Py_DECREF(value);
+                goto error;
+            }
+            PyTuple_SET_ITEM(value, 1, num);
+            if ((PyList_SetItem(result_list, j, value)) == -1) {
+                Py_DECREF(value);
+                goto error;
+            }
+            i++;
+        }
+    }
+    return result_list;
+
+  error:
+    Py_DECREF(result_list);
+    return NULL;
+}
+
+static PyMethodDef poll_methods[] = {
+    {"register",        (PyCFunction)poll_register,
+     METH_VARARGS,  poll_register_doc},
+    {"modify",          (PyCFunction)poll_modify,
+     METH_VARARGS,  poll_modify_doc},
+    {"unregister",      (PyCFunction)poll_unregister,
+     METH_O,        poll_unregister_doc},
+    {"poll",            (PyCFunction)poll_poll,
+     METH_VARARGS,  poll_poll_doc},
+    {NULL,              NULL}           /* sentinel */
+};
+
+static pollObject *
+newPollObject(void)
+{
+    pollObject *self;
+    self = PyObject_New(pollObject, &poll_Type);
+    if (self == NULL)
+        return NULL;
+    /* ufd_uptodate is a Boolean, denoting whether the
+       array pointed to by ufds matches the contents of the dictionary. */
+    self->ufd_uptodate = 0;
+    self->ufds = NULL;
+    self->dict = PyDict_New();
+    if (self->dict == NULL) {
+        Py_DECREF(self);
+        return NULL;
+    }
+    return self;
+}
+
+static void
+poll_dealloc(pollObject *self)
+{
+    if (self->ufds != NULL)
+        PyMem_DEL(self->ufds);
+    Py_XDECREF(self->dict);
+    PyObject_Del(self);
+}
+
+static PyTypeObject poll_Type = {
+    /* The ob_type field must be initialized in the module init function
+     * to be portable to Windows without using C++. */
+    PyVarObject_HEAD_INIT(NULL, 0)
+    "select.poll",              /*tp_name*/
+    sizeof(pollObject),         /*tp_basicsize*/
+    0,                          /*tp_itemsize*/
+    /* methods */
+    (destructor)poll_dealloc, /*tp_dealloc*/
+    0,                          /*tp_print*/
+    0,                          /*tp_getattr*/
+    0,                      /*tp_setattr*/
+    0,                          /*tp_reserved*/
+    0,                          /*tp_repr*/
+    0,                          /*tp_as_number*/
+    0,                          /*tp_as_sequence*/
+    0,                          /*tp_as_mapping*/
+    0,                          /*tp_hash*/
+    0,                          /*tp_call*/
+    0,                          /*tp_str*/
+    0,                          /*tp_getattro*/
+    0,                          /*tp_setattro*/
+    0,                          /*tp_as_buffer*/
+    Py_TPFLAGS_DEFAULT,         /*tp_flags*/
+    0,                          /*tp_doc*/
+    0,                          /*tp_traverse*/
+    0,                          /*tp_clear*/
+    0,                          /*tp_richcompare*/
+    0,                          /*tp_weaklistoffset*/
+    0,                          /*tp_iter*/
+    0,                          /*tp_iternext*/
+    poll_methods,               /*tp_methods*/
+};
+
+#ifdef HAVE_SYS_DEVPOLL_H
+typedef struct {
+    PyObject_HEAD
+    int fd_devpoll;
+    int max_n_fds;
+    int n_fds;
+    struct pollfd *fds;
+} devpollObject;
+
+static PyTypeObject devpoll_Type;
+
+static int devpoll_flush(devpollObject *self)
+{
+    int size, n;
+
+    if (!self->n_fds) return 0;
+
+    size = sizeof(struct pollfd)*self->n_fds;
+    self->n_fds = 0;
+
+    Py_BEGIN_ALLOW_THREADS
+    n = write(self->fd_devpoll, self->fds, size);
+    Py_END_ALLOW_THREADS
+
+    if (n == -1 ) {
+        PyErr_SetFromErrno(PyExc_IOError);
+        return -1;
+    }
+    if (n < size) {
+        /*
+        ** Data writed to /dev/poll is a binary data structure. It is not
+        ** clear what to do if a partial write occurred. For now, raise
+        ** an exception and see if we actually found this problem in
+        ** the wild.
+        ** See http://bugs.python.org/issue6397.
+        */
+        PyErr_Format(PyExc_IOError, "failed to write all pollfds. "
+                "Please, report at http://bugs.python.org/. "
+                "Data to report: Size tried: %d, actual size written: %d.",
+                size, n);
+        return -1;
+    }
+    return 0;
+}
+
+static PyObject *
+internal_devpoll_register(devpollObject *self, PyObject *args, int remove)
+{
+    PyObject *o;
+    int fd, events = POLLIN | POLLPRI | POLLOUT;
+
+    if (!PyArg_ParseTuple(args, "O|i:register", &o, &events)) {
+        return NULL;
+    }
+
+    fd = PyObject_AsFileDescriptor(o);
+    if (fd == -1) return NULL;
+
+    if (remove) {
+        self->fds[self->n_fds].fd = fd;
+        self->fds[self->n_fds].events = POLLREMOVE;
+
+        if (++self->n_fds == self->max_n_fds) {
+            if (devpoll_flush(self))
+                return NULL;
+        }
+    }
+
+    self->fds[self->n_fds].fd = fd;
+    self->fds[self->n_fds].events = events;
+
+    if (++self->n_fds == self->max_n_fds) {
+        if (devpoll_flush(self))
+            return NULL;
+    }
+
+    Py_RETURN_NONE;
+}
+
+PyDoc_STRVAR(devpoll_register_doc,
+"register(fd [, eventmask] ) -> None\n\n\
+Register a file descriptor with the polling object.\n\
+fd -- either an integer, or an object with a fileno() method returning an\n\
+      int.\n\
+events -- an optional bitmask describing the type of events to check for");
+
+static PyObject *
+devpoll_register(devpollObject *self, PyObject *args)
+{
+    return internal_devpoll_register(self, args, 0);
+}
+
+PyDoc_STRVAR(devpoll_modify_doc,
+"modify(fd[, eventmask]) -> None\n\n\
+Modify a possible already registered file descriptor.\n\
+fd -- either an integer, or an object with a fileno() method returning an\n\
+      int.\n\
+events -- an optional bitmask describing the type of events to check for");
+
+static PyObject *
+devpoll_modify(devpollObject *self, PyObject *args)
+{
+    return internal_devpoll_register(self, args, 1);
+}
+
+
+PyDoc_STRVAR(devpoll_unregister_doc,
+"unregister(fd) -> None\n\n\
+Remove a file descriptor being tracked by the polling object.");
+
+static PyObject *
+devpoll_unregister(devpollObject *self, PyObject *o)
+{
+    int fd;
+
+    fd = PyObject_AsFileDescriptor( o );
+    if (fd == -1)
+        return NULL;
+
+    self->fds[self->n_fds].fd = fd;
+    self->fds[self->n_fds].events = POLLREMOVE;
+
+    if (++self->n_fds == self->max_n_fds) {
+        if (devpoll_flush(self))
+            return NULL;
+    }
+
+    Py_RETURN_NONE;
+}
+
+PyDoc_STRVAR(devpoll_poll_doc,
+"poll( [timeout] ) -> list of (fd, event) 2-tuples\n\n\
+Polls the set of registered file descriptors, returning a list containing \n\
+any descriptors that have events or errors to report.");
+
+static PyObject *
+devpoll_poll(devpollObject *self, PyObject *args)
+{
+    struct dvpoll dvp;
+    PyObject *result_list = NULL, *tout = NULL;
+    int poll_result, i;
+    long timeout;
+    PyObject *value, *num1, *num2;
+
+    if (!PyArg_UnpackTuple(args, "poll", 0, 1, &tout)) {
+        return NULL;
+    }
+
+    /* Check values for timeout */
+    if (tout == NULL || tout == Py_None)
+        timeout = -1;
+    else if (!PyNumber_Check(tout)) {
+        PyErr_SetString(PyExc_TypeError,
+                        "timeout must be an integer or None");
+        return NULL;
+    }
+    else {
+        tout = PyNumber_Long(tout);
+        if (!tout)
+            return NULL;
+        timeout = PyLong_AsLong(tout);
+        Py_DECREF(tout);
+        if (timeout == -1 && PyErr_Occurred())
+            return NULL;
+    }
+
+    if ((timeout < -1) || (timeout > INT_MAX)) {
+        PyErr_SetString(PyExc_OverflowError,
+                        "timeout is out of range");
+        return NULL;
+    }
+
+    if (devpoll_flush(self))
+        return NULL;
+
+    dvp.dp_fds = self->fds;
+    dvp.dp_nfds = self->max_n_fds;
+    dvp.dp_timeout = timeout;
+
+    /* call devpoll() */
+    Py_BEGIN_ALLOW_THREADS
+    poll_result = ioctl(self->fd_devpoll, DP_POLL, &dvp);
+    Py_END_ALLOW_THREADS
+
+    if (poll_result < 0) {
+        PyErr_SetFromErrno(PyExc_IOError);
+        return NULL;
+    }
+
+    /* build the result list */
+
+    result_list = PyList_New(poll_result);
+    if (!result_list)
+        return NULL;
+    else {
+        for (i = 0; i < poll_result; i++) {
+            num1 = PyLong_FromLong(self->fds[i].fd);
+            num2 = PyLong_FromLong(self->fds[i].revents);
+            if ((num1 == NULL) || (num2 == NULL)) {
+                Py_XDECREF(num1);
+                Py_XDECREF(num2);
+                goto error;
+            }
+            value = PyTuple_Pack(2, num1, num2);
+            Py_DECREF(num1);
+            Py_DECREF(num2);
+            if (value == NULL)
+                goto error;
+            if ((PyList_SetItem(result_list, i, value)) == -1) {
+                Py_DECREF(value);
+                goto error;
+            }
+        }
+    }
+
+    return result_list;
+
+  error:
+    Py_DECREF(result_list);
+    return NULL;
+}
+
+static PyMethodDef devpoll_methods[] = {
+    {"register",        (PyCFunction)devpoll_register,
+     METH_VARARGS,  devpoll_register_doc},
+    {"modify",          (PyCFunction)devpoll_modify,
+     METH_VARARGS,  devpoll_modify_doc},
+    {"unregister",      (PyCFunction)devpoll_unregister,
+     METH_O,        devpoll_unregister_doc},
+    {"poll",            (PyCFunction)devpoll_poll,
+     METH_VARARGS,  devpoll_poll_doc},
+    {NULL,              NULL}           /* sentinel */
+};
+
+static devpollObject *
+newDevPollObject(void)
+{
+    devpollObject *self;
+    int fd_devpoll, limit_result;
+    struct pollfd *fds;
+    struct rlimit limit;
+
+    Py_BEGIN_ALLOW_THREADS
+    /*
+    ** If we try to process more that getrlimit()
+    ** fds, the kernel will give an error, so
+    ** we set the limit here. It is a dynamic
+    ** value, because we can change rlimit() anytime.
+    */
+    limit_result = getrlimit(RLIMIT_NOFILE, &limit);
+    if (limit_result != -1)
+        fd_devpoll = open("/dev/poll", O_RDWR);
+    Py_END_ALLOW_THREADS
+
+    if (limit_result == -1) {
+        PyErr_SetFromErrno(PyExc_OSError);
+        return NULL;
+    }
+    if (fd_devpoll == -1) {
+        PyErr_SetFromErrnoWithFilename(PyExc_IOError, "/dev/poll");
+        return NULL;
+    }
+
+    fds = PyMem_NEW(struct pollfd, limit.rlim_cur);
+    if (fds == NULL) {
+        close(fd_devpoll);
+        PyErr_NoMemory();
+        return NULL;
+    }
+
+    self = PyObject_New(devpollObject, &devpoll_Type);
+    if (self == NULL) {
+        close(fd_devpoll);
+        PyMem_DEL(fds);
+        return NULL;
+    }
+    self->fd_devpoll = fd_devpoll;
+    self->max_n_fds = limit.rlim_cur;
+    self->n_fds = 0;
+    self->fds = fds;
+
+    return self;
+}
+
+static void
+devpoll_dealloc(devpollObject *self)
+{
+    Py_BEGIN_ALLOW_THREADS
+    close(self->fd_devpoll);
+    Py_END_ALLOW_THREADS
+
+    PyMem_DEL(self->fds);
+
+    PyObject_Del(self);
+}
+
+static PyTypeObject devpoll_Type = {
+    /* The ob_type field must be initialized in the module init function
+     * to be portable to Windows without using C++. */
+    PyVarObject_HEAD_INIT(NULL, 0)
+    "select.devpoll",           /*tp_name*/
+    sizeof(devpollObject),      /*tp_basicsize*/
+    0,                          /*tp_itemsize*/
+    /* methods */
+    (destructor)devpoll_dealloc, /*tp_dealloc*/
+    0,                          /*tp_print*/
+    0,                          /*tp_getattr*/
+    0,                          /*tp_setattr*/
+    0,                          /*tp_reserved*/
+    0,                          /*tp_repr*/
+    0,                          /*tp_as_number*/
+    0,                          /*tp_as_sequence*/
+    0,                          /*tp_as_mapping*/
+    0,                          /*tp_hash*/
+    0,                          /*tp_call*/
+    0,                          /*tp_str*/
+    0,                          /*tp_getattro*/
+    0,                          /*tp_setattro*/
+    0,                          /*tp_as_buffer*/
+    Py_TPFLAGS_DEFAULT,         /*tp_flags*/
+    0,                          /*tp_doc*/
+    0,                          /*tp_traverse*/
+    0,                          /*tp_clear*/
+    0,                          /*tp_richcompare*/
+    0,                          /*tp_weaklistoffset*/
+    0,                          /*tp_iter*/
+    0,                          /*tp_iternext*/
+    devpoll_methods,            /*tp_methods*/
+};
+#endif  /* HAVE_SYS_DEVPOLL_H */
+
+
+
+PyDoc_STRVAR(poll_doc,
+"Returns a polling object, which supports registering and\n\
+unregistering file descriptors, and then polling them for I/O events.");
+
+static PyObject *
+select_poll(PyObject *self, PyObject *unused)
+{
+    return (PyObject *)newPollObject();
+}
+
+#ifdef HAVE_SYS_DEVPOLL_H
+PyDoc_STRVAR(devpoll_doc,
+"Returns a polling object, which supports registering and\n\
+unregistering file descriptors, and then polling them for I/O events.");
+
+static PyObject *
+select_devpoll(PyObject *self, PyObject *unused)
+{
+    return (PyObject *)newDevPollObject();
+}
+#endif
+
+
+#ifdef __APPLE__
+/*
+ * On some systems poll() sets errno on invalid file descriptors. We test
+ * for this at runtime because this bug may be fixed or introduced between
+ * OS releases.
+ */
+static int select_have_broken_poll(void)
+{
+    int poll_test;
+    int filedes[2];
+
+    struct pollfd poll_struct = { 0, POLLIN|POLLPRI|POLLOUT, 0 };
+
+    /* Create a file descriptor to make invalid */
+    if (pipe(filedes) < 0) {
+        return 1;
+    }
+    poll_struct.fd = filedes[0];
+    close(filedes[0]);
+    close(filedes[1]);
+    poll_test = poll(&poll_struct, 1, 0);
+    if (poll_test < 0) {
+        return 1;
+    } else if (poll_test == 0 && poll_struct.revents != POLLNVAL) {
+        return 1;
+    }
+    return 0;
+}
+#endif /* __APPLE__ */
+
+#endif /* HAVE_POLL */
+
+#ifdef HAVE_EPOLL
+/* **************************************************************************
+ *                      epoll interface for Linux 2.6
+ *
+ * Written by Christian Heimes
+ * Inspired by Twisted's _epoll.pyx and select.poll()
+ */
+
+#ifdef HAVE_SYS_EPOLL_H
+#include <sys/epoll.h>
+#endif
+
+typedef struct {
+    PyObject_HEAD
+    SOCKET epfd;                        /* epoll control file descriptor */
+} pyEpoll_Object;
+
+static PyTypeObject pyEpoll_Type;
+#define pyepoll_CHECK(op) (PyObject_TypeCheck((op), &pyEpoll_Type))
+
+static PyObject *
+pyepoll_err_closed(void)
+{
+    PyErr_SetString(PyExc_ValueError, "I/O operation on closed epoll fd");
+    return NULL;
+}
+
+static int
+pyepoll_internal_close(pyEpoll_Object *self)
+{
+    int save_errno = 0;
+    if (self->epfd >= 0) {
+        int epfd = self->epfd;
+        self->epfd = -1;
+        Py_BEGIN_ALLOW_THREADS
+        if (close(epfd) < 0)
+            save_errno = errno;
+        Py_END_ALLOW_THREADS
+    }
+    return save_errno;
+}
+
+static PyObject *
+newPyEpoll_Object(PyTypeObject *type, int sizehint, int flags, SOCKET fd)
+{
+    pyEpoll_Object *self;
+
+    assert(type != NULL && type->tp_alloc != NULL);
+    self = (pyEpoll_Object *) type->tp_alloc(type, 0);
+    if (self == NULL)
+        return NULL;
+
+    if (fd == -1) {
+        Py_BEGIN_ALLOW_THREADS
+#ifdef HAVE_EPOLL_CREATE1
+        if (flags)
+            self->epfd = epoll_create1(flags);
+        else
+#endif
+        self->epfd = epoll_create(sizehint);
+        Py_END_ALLOW_THREADS
+    }
+    else {
+        self->epfd = fd;
+    }
+    if (self->epfd < 0) {
+        Py_DECREF(self);
+        PyErr_SetFromErrno(PyExc_OSError);
+        return NULL;
+    }
+    return (PyObject *)self;
+}
+
+
+static PyObject *
+pyepoll_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
+{
+    int flags = 0, sizehint = FD_SETSIZE - 1;
+    static char *kwlist[] = {"sizehint", "flags", NULL};
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwds, "|ii:epoll", kwlist,
+                                     &sizehint, &flags))
+        return NULL;
+    if (sizehint < 0) {
+        PyErr_SetString(PyExc_ValueError, "negative sizehint");
+        return NULL;
+    }
+
+    return newPyEpoll_Object(type, sizehint, flags, -1);
+}
+
+
+static void
+pyepoll_dealloc(pyEpoll_Object *self)
+{
+    (void)pyepoll_internal_close(self);
+    Py_TYPE(self)->tp_free(self);
+}
+
+static PyObject*
+pyepoll_close(pyEpoll_Object *self)
+{
+    errno = pyepoll_internal_close(self);
+    if (errno < 0) {
+        PyErr_SetFromErrno(PyExc_OSError);
+        return NULL;
+    }
+    Py_RETURN_NONE;
+}
+
+PyDoc_STRVAR(pyepoll_close_doc,
+"close() -> None\n\
+\n\
+Close the epoll control file descriptor. Further operations on the epoll\n\
+object will raise an exception.");
+
+static PyObject*
+pyepoll_get_closed(pyEpoll_Object *self)
+{
+    if (self->epfd < 0)
+        Py_RETURN_TRUE;
+    else
+        Py_RETURN_FALSE;
+}
+
+static PyObject*
+pyepoll_fileno(pyEpoll_Object *self)
+{
+    if (self->epfd < 0)
+        return pyepoll_err_closed();
+    return PyLong_FromLong(self->epfd);
+}
+
+PyDoc_STRVAR(pyepoll_fileno_doc,
+"fileno() -> int\n\
+\n\
+Return the epoll control file descriptor.");
+
+static PyObject*
+pyepoll_fromfd(PyObject *cls, PyObject *args)
+{
+    SOCKET fd;
+
+    if (!PyArg_ParseTuple(args, "i:fromfd", &fd))
+        return NULL;
+
+    return newPyEpoll_Object((PyTypeObject*)cls, FD_SETSIZE - 1, 0, fd);
+}
+
+PyDoc_STRVAR(pyepoll_fromfd_doc,
+"fromfd(fd) -> epoll\n\
+\n\
+Create an epoll object from a given control fd.");
+
+static PyObject *
+pyepoll_internal_ctl(int epfd, int op, PyObject *pfd, unsigned int events)
+{
+    struct epoll_event ev;
+    int result;
+    int fd;
+
+    if (epfd < 0)
+        return pyepoll_err_closed();
+
+    fd = PyObject_AsFileDescriptor(pfd);
+    if (fd == -1) {
+        return NULL;
+    }
+
+    switch(op) {
+        case EPOLL_CTL_ADD:
+        case EPOLL_CTL_MOD:
+        ev.events = events;
+        ev.data.fd = fd;
+        Py_BEGIN_ALLOW_THREADS
+        result = epoll_ctl(epfd, op, fd, &ev);
+        Py_END_ALLOW_THREADS
+        break;
+        case EPOLL_CTL_DEL:
+        /* In kernel versions before 2.6.9, the EPOLL_CTL_DEL
+         * operation required a non-NULL pointer in event, even
+         * though this argument is ignored. */
+        Py_BEGIN_ALLOW_THREADS
+        result = epoll_ctl(epfd, op, fd, &ev);
+        if (errno == EBADF) {
+            /* fd already closed */
+            result = 0;
+            errno = 0;
+        }
+        Py_END_ALLOW_THREADS
+        break;
+        default:
+        result = -1;
+        errno = EINVAL;
+    }
+
+    if (result < 0) {
+        PyErr_SetFromErrno(PyExc_OSError);
+        return NULL;
+    }
+    Py_RETURN_NONE;
+}
+
+static PyObject *
+pyepoll_register(pyEpoll_Object *self, PyObject *args, PyObject *kwds)
+{
+    PyObject *pfd;
+    unsigned int events = EPOLLIN | EPOLLOUT | EPOLLPRI;
+    static char *kwlist[] = {"fd", "eventmask", NULL};
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|I:register", kwlist,
+                                     &pfd, &events)) {
+        return NULL;
+    }
+
+    return pyepoll_internal_ctl(self->epfd, EPOLL_CTL_ADD, pfd, events);
+}
+
+PyDoc_STRVAR(pyepoll_register_doc,
+"register(fd[, eventmask]) -> None\n\
+\n\
+Registers a new fd or raises an OSError if the fd is already registered.\n\
+fd is the target file descriptor of the operation.\n\
+events is a bit set composed of the various EPOLL constants; the default\n\
+is EPOLL_IN | EPOLL_OUT | EPOLL_PRI.\n\
+\n\
+The epoll interface supports all file descriptors that support poll.");
+
+static PyObject *
+pyepoll_modify(pyEpoll_Object *self, PyObject *args, PyObject *kwds)
+{
+    PyObject *pfd;
+    unsigned int events;
+    static char *kwlist[] = {"fd", "eventmask", NULL};
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwds, "OI:modify", kwlist,
+                                     &pfd, &events)) {
+        return NULL;
+    }
+
+    return pyepoll_internal_ctl(self->epfd, EPOLL_CTL_MOD, pfd, events);
+}
+
+PyDoc_STRVAR(pyepoll_modify_doc,
+"modify(fd, eventmask) -> None\n\
+\n\
+fd is the target file descriptor of the operation\n\
+events is a bit set composed of the various EPOLL constants");
+
+static PyObject *
+pyepoll_unregister(pyEpoll_Object *self, PyObject *args, PyObject *kwds)
+{
+    PyObject *pfd;
+    static char *kwlist[] = {"fd", NULL};
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwds, "O:unregister", kwlist,
+                                     &pfd)) {
+        return NULL;
+    }
+
+    return pyepoll_internal_ctl(self->epfd, EPOLL_CTL_DEL, pfd, 0);
+}
+
+PyDoc_STRVAR(pyepoll_unregister_doc,
+"unregister(fd) -> None\n\
+\n\
+fd is the target file descriptor of the operation.");
+
+static PyObject *
+pyepoll_poll(pyEpoll_Object *self, PyObject *args, PyObject *kwds)
+{
+    double dtimeout = -1.;
+    int timeout;
+    int maxevents = -1;
+    int nfds, i;
+    PyObject *elist = NULL, *etuple = NULL;
+    struct epoll_event *evs = NULL;
+    static char *kwlist[] = {"timeout", "maxevents", NULL};
+
+    if (self->epfd < 0)
+        return pyepoll_err_closed();
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwds, "|di:poll", kwlist,
+                                     &dtimeout, &maxevents)) {
+        return NULL;
+    }
+
+    if (dtimeout < 0) {
+        timeout = -1;
+    }
+    else if (dtimeout * 1000.0 > INT_MAX) {
+        PyErr_SetString(PyExc_OverflowError,
+                        "timeout is too large");
+        return NULL;
+    }
+    else {
+        timeout = (int)(dtimeout * 1000.0);
+    }
+
+    if (maxevents == -1) {
+        maxevents = FD_SETSIZE-1;
+    }
+    else if (maxevents < 1) {
+        PyErr_Format(PyExc_ValueError,
+                     "maxevents must be greater than 0, got %d",
+                     maxevents);
+        return NULL;
+    }
+
+    evs = PyMem_New(struct epoll_event, maxevents);
+    if (evs == NULL) {
+        Py_DECREF(self);
+        PyErr_NoMemory();
+        return NULL;
+    }
+
+    Py_BEGIN_ALLOW_THREADS
+    nfds = epoll_wait(self->epfd, evs, maxevents, timeout);
+    Py_END_ALLOW_THREADS
+    if (nfds < 0) {
+        PyErr_SetFromErrno(PyExc_OSError);
+        goto error;
+    }
+
+    elist = PyList_New(nfds);
+    if (elist == NULL) {
+        goto error;
+    }
+
+    for (i = 0; i < nfds; i++) {
+        etuple = Py_BuildValue("iI", evs[i].data.fd, evs[i].events);
+        if (etuple == NULL) {
+            Py_CLEAR(elist);
+            goto error;
+        }
+        PyList_SET_ITEM(elist, i, etuple);
+    }
+
+    error:
+    PyMem_Free(evs);
+    return elist;
+}
+
+PyDoc_STRVAR(pyepoll_poll_doc,
+"poll([timeout=-1[, maxevents=-1]]) -> [(fd, events), (...)]\n\
+\n\
+Wait for events on the epoll file descriptor for a maximum time of timeout\n\
+in seconds (as float). -1 makes poll wait indefinitely.\n\
+Up to maxevents are returned to the caller.");
+
+static PyObject *
+pyepoll_enter(pyEpoll_Object *self, PyObject *args)
+{
+    if (self->epfd < 0)
+        return pyepoll_err_closed();
+
+    Py_INCREF(self);
+    return (PyObject *)self;
+}
+
+static PyObject *
+pyepoll_exit(PyObject *self, PyObject *args)
+{
+    _Py_IDENTIFIER(close);
+
+    return _PyObject_CallMethodId(self, &PyId_close, NULL);
+}
+
+static PyMethodDef pyepoll_methods[] = {
+    {"fromfd",          (PyCFunction)pyepoll_fromfd,
+     METH_VARARGS | METH_CLASS, pyepoll_fromfd_doc},
+    {"close",           (PyCFunction)pyepoll_close,     METH_NOARGS,
+     pyepoll_close_doc},
+    {"fileno",          (PyCFunction)pyepoll_fileno,    METH_NOARGS,
+     pyepoll_fileno_doc},
+    {"modify",          (PyCFunction)pyepoll_modify,
+     METH_VARARGS | METH_KEYWORDS,      pyepoll_modify_doc},
+    {"register",        (PyCFunction)pyepoll_register,
+     METH_VARARGS | METH_KEYWORDS,      pyepoll_register_doc},
+    {"unregister",      (PyCFunction)pyepoll_unregister,
+     METH_VARARGS | METH_KEYWORDS,      pyepoll_unregister_doc},
+    {"poll",            (PyCFunction)pyepoll_poll,
+     METH_VARARGS | METH_KEYWORDS,      pyepoll_poll_doc},
+    {"__enter__",           (PyCFunction)pyepoll_enter,     METH_NOARGS,
+     NULL},
+    {"__exit__",           (PyCFunction)pyepoll_exit,     METH_VARARGS,
+     NULL},
+    {NULL,      NULL},
+};
+
+static PyGetSetDef pyepoll_getsetlist[] = {
+    {"closed", (getter)pyepoll_get_closed, NULL,
+     "True if the epoll handler is closed"},
+    {0},
+};
+
+PyDoc_STRVAR(pyepoll_doc,
+"select.epoll(sizehint=-1, flags=0)\n\
+\n\
+Returns an epolling object\n\
+\n\
+sizehint must be a positive integer or -1 for the default size. The\n\
+sizehint is used to optimize internal data structures. It doesn't limit\n\
+the maximum number of monitored events.");
+
+static PyTypeObject pyEpoll_Type = {
+    PyVarObject_HEAD_INIT(NULL, 0)
+    "select.epoll",                                     /* tp_name */
+    sizeof(pyEpoll_Object),                             /* tp_basicsize */
+    0,                                                  /* tp_itemsize */
+    (destructor)pyepoll_dealloc,                        /* tp_dealloc */
+    0,                                                  /* tp_print */
+    0,                                                  /* tp_getattr */
+    0,                                                  /* tp_setattr */
+    0,                                                  /* tp_reserved */
+    0,                                                  /* tp_repr */
+    0,                                                  /* tp_as_number */
+    0,                                                  /* tp_as_sequence */
+    0,                                                  /* tp_as_mapping */
+    0,                                                  /* tp_hash */
+    0,                                                  /* tp_call */
+    0,                                                  /* tp_str */
+    PyObject_GenericGetAttr,                            /* tp_getattro */
+    0,                                                  /* tp_setattro */
+    0,                                                  /* tp_as_buffer */
+    Py_TPFLAGS_DEFAULT,                                 /* tp_flags */
+    pyepoll_doc,                                        /* tp_doc */
+    0,                                                  /* tp_traverse */
+    0,                                                  /* tp_clear */
+    0,                                                  /* tp_richcompare */
+    0,                                                  /* tp_weaklistoffset */
+    0,                                                  /* tp_iter */
+    0,                                                  /* tp_iternext */
+    pyepoll_methods,                                    /* tp_methods */
+    0,                                                  /* tp_members */
+    pyepoll_getsetlist,                                 /* tp_getset */
+    0,                                                  /* tp_base */
+    0,                                                  /* tp_dict */
+    0,                                                  /* tp_descr_get */
+    0,                                                  /* tp_descr_set */
+    0,                                                  /* tp_dictoffset */
+    0,                                                  /* tp_init */
+    0,                                                  /* tp_alloc */
+    pyepoll_new,                                        /* tp_new */
+    0,                                                  /* tp_free */
+};
+
+#endif /* HAVE_EPOLL */
+
+#ifdef HAVE_KQUEUE
+/* **************************************************************************
+ *                      kqueue interface for BSD
+ *
+ * Copyright (c) 2000 Doug White, 2006 James Knight, 2007 Christian Heimes
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#ifdef HAVE_SYS_EVENT_H
+#include <sys/event.h>
+#endif
+
+PyDoc_STRVAR(kqueue_event_doc,
+"kevent(ident, filter=KQ_FILTER_READ, flags=KQ_EV_ADD, fflags=0, data=0, udata=0)\n\
+\n\
+This object is the equivalent of the struct kevent for the C API.\n\
+\n\
+See the kqueue manpage for more detailed information about the meaning\n\
+of the arguments.\n\
+\n\
+One minor note: while you might hope that udata could store a\n\
+reference to a python object, it cannot, because it is impossible to\n\
+keep a proper reference count of the object once it's passed into the\n\
+kernel. Therefore, I have restricted it to only storing an integer.  I\n\
+recommend ignoring it and simply using the 'ident' field to key off\n\
+of. You could also set up a dictionary on the python side to store a\n\
+udata->object mapping.");
+
+typedef struct {
+    PyObject_HEAD
+    struct kevent e;
+} kqueue_event_Object;
+
+static PyTypeObject kqueue_event_Type;
+
+#define kqueue_event_Check(op) (PyObject_TypeCheck((op), &kqueue_event_Type))
+
+typedef struct {
+    PyObject_HEAD
+    SOCKET kqfd;                /* kqueue control fd */
+} kqueue_queue_Object;
+
+static PyTypeObject kqueue_queue_Type;
+
+#define kqueue_queue_Check(op) (PyObject_TypeCheck((op), &kqueue_queue_Type))
+
+#if (SIZEOF_UINTPTR_T != SIZEOF_VOID_P)
+#   error uintptr_t does not match void *!
+#elif (SIZEOF_UINTPTR_T == SIZEOF_LONG_LONG)
+#   define T_UINTPTRT         T_ULONGLONG
+#   define T_INTPTRT          T_LONGLONG
+#   define PyLong_AsUintptr_t PyLong_AsUnsignedLongLong
+#   define UINTPTRT_FMT_UNIT  "K"
+#   define INTPTRT_FMT_UNIT   "L"
+#elif (SIZEOF_UINTPTR_T == SIZEOF_LONG)
+#   define T_UINTPTRT         T_ULONG
+#   define T_INTPTRT          T_LONG
+#   define PyLong_AsUintptr_t PyLong_AsUnsignedLong
+#   define UINTPTRT_FMT_UNIT  "k"
+#   define INTPTRT_FMT_UNIT   "l"
+#elif (SIZEOF_UINTPTR_T == SIZEOF_INT)
+#   define T_UINTPTRT         T_UINT
+#   define T_INTPTRT          T_INT
+#   define PyLong_AsUintptr_t PyLong_AsUnsignedLong
+#   define UINTPTRT_FMT_UNIT  "I"
+#   define INTPTRT_FMT_UNIT   "i"
+#else
+#   error uintptr_t does not match int, long, or long long!
+#endif
+
+/*
+ * kevent is not standard and its members vary across BSDs.
+ */
+#if !defined(__OpenBSD__)
+#   define IDENT_TYPE	T_UINTPTRT
+#   define IDENT_CAST	Py_intptr_t
+#   define DATA_TYPE	T_INTPTRT
+#   define DATA_FMT_UNIT INTPTRT_FMT_UNIT
+#   define IDENT_AsType	PyLong_AsUintptr_t
+#else
+#   define IDENT_TYPE	T_UINT
+#   define IDENT_CAST	int
+#   define DATA_TYPE	T_INT
+#   define DATA_FMT_UNIT "i"
+#   define IDENT_AsType	PyLong_AsUnsignedLong
+#endif
+
+/* Unfortunately, we can't store python objects in udata, because
+ * kevents in the kernel can be removed without warning, which would
+ * forever lose the refcount on the object stored with it.
+ */
+
+#define KQ_OFF(x) offsetof(kqueue_event_Object, x)
+static struct PyMemberDef kqueue_event_members[] = {
+    {"ident",           IDENT_TYPE,     KQ_OFF(e.ident)},
+    {"filter",          T_SHORT,        KQ_OFF(e.filter)},
+    {"flags",           T_USHORT,       KQ_OFF(e.flags)},
+    {"fflags",          T_UINT,         KQ_OFF(e.fflags)},
+    {"data",            DATA_TYPE,      KQ_OFF(e.data)},
+    {"udata",           T_UINTPTRT,     KQ_OFF(e.udata)},
+    {NULL} /* Sentinel */
+};
+#undef KQ_OFF
+
+static PyObject *
+
+kqueue_event_repr(kqueue_event_Object *s)
+{
+    char buf[1024];
+    PyOS_snprintf(
+        buf, sizeof(buf),
+        "<select.kevent ident=%zu filter=%d flags=0x%x fflags=0x%x "
+        "data=0x%zd udata=%p>",
+        (size_t)(s->e.ident), s->e.filter, s->e.flags,
+        s->e.fflags, (Py_ssize_t)(s->e.data), s->e.udata);
+    return PyUnicode_FromString(buf);
+}
+
+static int
+kqueue_event_init(kqueue_event_Object *self, PyObject *args, PyObject *kwds)
+{
+    PyObject *pfd;
+    static char *kwlist[] = {"ident", "filter", "flags", "fflags",
+                             "data", "udata", NULL};
+    static char *fmt = "O|hhi" DATA_FMT_UNIT UINTPTRT_FMT_UNIT ":kevent";
+
+    EV_SET(&(self->e), 0, EVFILT_READ, EV_ADD, 0, 0, 0); /* defaults */
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwds, fmt, kwlist,
+        &pfd, &(self->e.filter), &(self->e.flags),
+        &(self->e.fflags), &(self->e.data), &(self->e.udata))) {
+        return -1;
+    }
+
+    if (PyLong_Check(pfd)
+#if IDENT_TYPE == T_UINT
+	&& PyLong_AsUnsignedLong(pfd) <= UINT_MAX
+#endif
+    ) {
+        self->e.ident = IDENT_AsType(pfd);
+    }
+    else {
+        self->e.ident = PyObject_AsFileDescriptor(pfd);
+    }
+    if (PyErr_Occurred()) {
+        return -1;
+    }
+    return 0;
+}
+
+static PyObject *
+kqueue_event_richcompare(kqueue_event_Object *s, kqueue_event_Object *o,
+                         int op)
+{
+    Py_intptr_t result = 0;
+
+    if (!kqueue_event_Check(o)) {
+        if (op == Py_EQ || op == Py_NE) {
+            PyObject *res = op == Py_EQ ? Py_False : Py_True;
+            Py_INCREF(res);
+            return res;
+        }
+        PyErr_Format(PyExc_TypeError,
+            "can't compare %.200s to %.200s",
+            Py_TYPE(s)->tp_name, Py_TYPE(o)->tp_name);
+        return NULL;
+    }
+    if (((result = (IDENT_CAST)(s->e.ident - o->e.ident)) == 0) &&
+        ((result = s->e.filter - o->e.filter) == 0) &&
+        ((result = s->e.flags - o->e.flags) == 0) &&
+        ((result = (int)(s->e.fflags - o->e.fflags)) == 0) &&
+        ((result = s->e.data - o->e.data) == 0) &&
+        ((result = s->e.udata - o->e.udata) == 0)
+       ) {
+        result = 0;
+    }
+
+    switch (op) {
+        case Py_EQ:
+        result = (result == 0);
+        break;
+        case Py_NE:
+        result = (result != 0);
+        break;
+        case Py_LE:
+        result = (result <= 0);
+        break;
+        case Py_GE:
+        result = (result >= 0);
+        break;
+        case Py_LT:
+        result = (result < 0);
+        break;
+        case Py_GT:
+        result = (result > 0);
+        break;
+    }
+    return PyBool_FromLong((long)result);
+}
+
+static PyTypeObject kqueue_event_Type = {
+    PyVarObject_HEAD_INIT(NULL, 0)
+    "select.kevent",                                    /* tp_name */
+    sizeof(kqueue_event_Object),                        /* tp_basicsize */
+    0,                                                  /* tp_itemsize */
+    0,                                                  /* tp_dealloc */
+    0,                                                  /* tp_print */
+    0,                                                  /* tp_getattr */
+    0,                                                  /* tp_setattr */
+    0,                                                  /* tp_reserved */
+    (reprfunc)kqueue_event_repr,                        /* tp_repr */
+    0,                                                  /* tp_as_number */
+    0,                                                  /* tp_as_sequence */
+    0,                                                  /* tp_as_mapping */
+    0,                                                  /* tp_hash */
+    0,                                                  /* tp_call */
+    0,                                                  /* tp_str */
+    0,                                                  /* tp_getattro */
+    0,                                                  /* tp_setattro */
+    0,                                                  /* tp_as_buffer */
+    Py_TPFLAGS_DEFAULT,                                 /* tp_flags */
+    kqueue_event_doc,                                   /* tp_doc */
+    0,                                                  /* tp_traverse */
+    0,                                                  /* tp_clear */
+    (richcmpfunc)kqueue_event_richcompare,              /* tp_richcompare */
+    0,                                                  /* tp_weaklistoffset */
+    0,                                                  /* tp_iter */
+    0,                                                  /* tp_iternext */
+    0,                                                  /* tp_methods */
+    kqueue_event_members,                               /* tp_members */
+    0,                                                  /* tp_getset */
+    0,                                                  /* tp_base */
+    0,                                                  /* tp_dict */
+    0,                                                  /* tp_descr_get */
+    0,                                                  /* tp_descr_set */
+    0,                                                  /* tp_dictoffset */
+    (initproc)kqueue_event_init,                        /* tp_init */
+    0,                                                  /* tp_alloc */
+    0,                                                  /* tp_new */
+    0,                                                  /* tp_free */
+};
+
+static PyObject *
+kqueue_queue_err_closed(void)
+{
+    PyErr_SetString(PyExc_ValueError, "I/O operation on closed kqueue fd");
+    return NULL;
+}
+
+static int
+kqueue_queue_internal_close(kqueue_queue_Object *self)
+{
+    int save_errno = 0;
+    if (self->kqfd >= 0) {
+        int kqfd = self->kqfd;
+        self->kqfd = -1;
+        Py_BEGIN_ALLOW_THREADS
+        if (close(kqfd) < 0)
+            save_errno = errno;
+        Py_END_ALLOW_THREADS
+    }
+    return save_errno;
+}
+
+static PyObject *
+newKqueue_Object(PyTypeObject *type, SOCKET fd)
+{
+    kqueue_queue_Object *self;
+    assert(type != NULL && type->tp_alloc != NULL);
+    self = (kqueue_queue_Object *) type->tp_alloc(type, 0);
+    if (self == NULL) {
+        return NULL;
+    }
+
+    if (fd == -1) {
+        Py_BEGIN_ALLOW_THREADS
+        self->kqfd = kqueue();
+        Py_END_ALLOW_THREADS
+    }
+    else {
+        self->kqfd = fd;
+    }
+    if (self->kqfd < 0) {
+        Py_DECREF(self);
+        PyErr_SetFromErrno(PyExc_OSError);
+        return NULL;
+    }
+    return (PyObject *)self;
+}
+
+static PyObject *
+kqueue_queue_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
+{
+
+    if ((args != NULL && PyObject_Size(args)) ||
+                    (kwds != NULL && PyObject_Size(kwds))) {
+        PyErr_SetString(PyExc_ValueError,
+                        "select.kqueue doesn't accept arguments");
+        return NULL;
+    }
+
+    return newKqueue_Object(type, -1);
+}
+
+static void
+kqueue_queue_dealloc(kqueue_queue_Object *self)
+{
+    kqueue_queue_internal_close(self);
+    Py_TYPE(self)->tp_free(self);
+}
+
+static PyObject*
+kqueue_queue_close(kqueue_queue_Object *self)
+{
+    errno = kqueue_queue_internal_close(self);
+    if (errno < 0) {
+        PyErr_SetFromErrno(PyExc_OSError);
+        return NULL;
+    }
+    Py_RETURN_NONE;
+}
+
+PyDoc_STRVAR(kqueue_queue_close_doc,
+"close() -> None\n\
+\n\
+Close the kqueue control file descriptor. Further operations on the kqueue\n\
+object will raise an exception.");
+
+static PyObject*
+kqueue_queue_get_closed(kqueue_queue_Object *self)
+{
+    if (self->kqfd < 0)
+        Py_RETURN_TRUE;
+    else
+        Py_RETURN_FALSE;
+}
+
+static PyObject*
+kqueue_queue_fileno(kqueue_queue_Object *self)
+{
+    if (self->kqfd < 0)
+        return kqueue_queue_err_closed();
+    return PyLong_FromLong(self->kqfd);
+}
+
+PyDoc_STRVAR(kqueue_queue_fileno_doc,
+"fileno() -> int\n\
+\n\
+Return the kqueue control file descriptor.");
+
+static PyObject*
+kqueue_queue_fromfd(PyObject *cls, PyObject *args)
+{
+    SOCKET fd;
+
+    if (!PyArg_ParseTuple(args, "i:fromfd", &fd))
+        return NULL;
+
+    return newKqueue_Object((PyTypeObject*)cls, fd);
+}
+
+PyDoc_STRVAR(kqueue_queue_fromfd_doc,
+"fromfd(fd) -> kqueue\n\
+\n\
+Create a kqueue object from a given control fd.");
+
+static PyObject *
+kqueue_queue_control(kqueue_queue_Object *self, PyObject *args)
+{
+    int nevents = 0;
+    int gotevents = 0;
+    int nchanges = 0;
+    int i = 0;
+    PyObject *otimeout = NULL;
+    PyObject *ch = NULL;
+    PyObject *it = NULL, *ei = NULL;
+    PyObject *result = NULL;
+    struct kevent *evl = NULL;
+    struct kevent *chl = NULL;
+    struct timespec timeout;
+    struct timespec *ptimeoutspec;
+
+    if (self->kqfd < 0)
+        return kqueue_queue_err_closed();
+
+    if (!PyArg_ParseTuple(args, "Oi|O:control", &ch, &nevents, &otimeout))
+        return NULL;
+
+    if (nevents < 0) {
+        PyErr_Format(PyExc_ValueError,
+            "Length of eventlist must be 0 or positive, got %d",
+            nevents);
+        return NULL;
+    }
+
+    if (otimeout == Py_None || otimeout == NULL) {
+        ptimeoutspec = NULL;
+    }
+    else if (PyNumber_Check(otimeout)) {
+        if (_PyTime_ObjectToTimespec(otimeout,
+                                     &timeout.tv_sec, &timeout.tv_nsec) == -1)
+            return NULL;
+
+        if (timeout.tv_sec < 0) {
+            PyErr_SetString(PyExc_ValueError,
+                            "timeout must be positive or None");
+            return NULL;
+        }
+        ptimeoutspec = &timeout;
+    }
+    else {
+        PyErr_Format(PyExc_TypeError,
+            "timeout argument must be an number "
+            "or None, got %.200s",
+            Py_TYPE(otimeout)->tp_name);
+        return NULL;
+    }
+
+    if (ch != NULL && ch != Py_None) {
+        it = PyObject_GetIter(ch);
+        if (it == NULL) {
+            PyErr_SetString(PyExc_TypeError,
+                            "changelist is not iterable");
+            return NULL;
+        }
+        nchanges = PyObject_Size(ch);
+        if (nchanges < 0) {
+            goto error;
+        }
+
+        chl = PyMem_New(struct kevent, nchanges);
+        if (chl == NULL) {
+            PyErr_NoMemory();
+            goto error;
+        }
+        i = 0;
+        while ((ei = PyIter_Next(it)) != NULL) {
+            if (!kqueue_event_Check(ei)) {
+                Py_DECREF(ei);
+                PyErr_SetString(PyExc_TypeError,
+                    "changelist must be an iterable of "
+                    "select.kevent objects");
+                goto error;
+            } else {
+                chl[i++] = ((kqueue_event_Object *)ei)->e;
+            }
+            Py_DECREF(ei);
+        }
+    }
+    Py_CLEAR(it);
+
+    /* event list */
+    if (nevents) {
+        evl = PyMem_New(struct kevent, nevents);
+        if (evl == NULL) {
+            PyErr_NoMemory();
+            goto error;
+        }
+    }
+
+    Py_BEGIN_ALLOW_THREADS
+    gotevents = kevent(self->kqfd, chl, nchanges,
+                       evl, nevents, ptimeoutspec);
+    Py_END_ALLOW_THREADS
+
+    if (gotevents == -1) {
+        PyErr_SetFromErrno(PyExc_OSError);
+        goto error;
+    }
+
+    result = PyList_New(gotevents);
+    if (result == NULL) {
+        goto error;
+    }
+
+    for (i = 0; i < gotevents; i++) {
+        kqueue_event_Object *ch;
+
+        ch = PyObject_New(kqueue_event_Object, &kqueue_event_Type);
+        if (ch == NULL) {
+            goto error;
+        }
+        ch->e = evl[i];
+        PyList_SET_ITEM(result, i, (PyObject *)ch);
+    }
+    PyMem_Free(chl);
+    PyMem_Free(evl);
+    return result;
+
+    error:
+    PyMem_Free(chl);
+    PyMem_Free(evl);
+    Py_XDECREF(result);
+    Py_XDECREF(it);
+    return NULL;
+}
+
+PyDoc_STRVAR(kqueue_queue_control_doc,
+"control(changelist, max_events[, timeout=None]) -> eventlist\n\
+\n\
+Calls the kernel kevent function.\n\
+- changelist must be a list of kevent objects describing the changes\n\
+  to be made to the kernel's watch list or None.\n\
+- max_events lets you specify the maximum number of events that the\n\
+  kernel will return.\n\
+- timeout is the maximum time to wait in seconds, or else None,\n\
+  to wait forever. timeout accepts floats for smaller timeouts, too.");
+
+
+static PyMethodDef kqueue_queue_methods[] = {
+    {"fromfd",          (PyCFunction)kqueue_queue_fromfd,
+     METH_VARARGS | METH_CLASS, kqueue_queue_fromfd_doc},
+    {"close",           (PyCFunction)kqueue_queue_close,        METH_NOARGS,
+     kqueue_queue_close_doc},
+    {"fileno",          (PyCFunction)kqueue_queue_fileno,       METH_NOARGS,
+     kqueue_queue_fileno_doc},
+    {"control",         (PyCFunction)kqueue_queue_control,
+     METH_VARARGS ,     kqueue_queue_control_doc},
+    {NULL,      NULL},
+};
+
+static PyGetSetDef kqueue_queue_getsetlist[] = {
+    {"closed", (getter)kqueue_queue_get_closed, NULL,
+     "True if the kqueue handler is closed"},
+    {0},
+};
+
+PyDoc_STRVAR(kqueue_queue_doc,
+"Kqueue syscall wrapper.\n\
+\n\
+For example, to start watching a socket for input:\n\
+>>> kq = kqueue()\n\
+>>> sock = socket()\n\
+>>> sock.connect((host, port))\n\
+>>> kq.control([kevent(sock, KQ_FILTER_WRITE, KQ_EV_ADD)], 0)\n\
+\n\
+To wait one second for it to become writeable:\n\
+>>> kq.control(None, 1, 1000)\n\
+\n\
+To stop listening:\n\
+>>> kq.control([kevent(sock, KQ_FILTER_WRITE, KQ_EV_DELETE)], 0)");
+
+static PyTypeObject kqueue_queue_Type = {
+    PyVarObject_HEAD_INIT(NULL, 0)
+    "select.kqueue",                                    /* tp_name */
+    sizeof(kqueue_queue_Object),                        /* tp_basicsize */
+    0,                                                  /* tp_itemsize */
+    (destructor)kqueue_queue_dealloc,                   /* tp_dealloc */
+    0,                                                  /* tp_print */
+    0,                                                  /* tp_getattr */
+    0,                                                  /* tp_setattr */
+    0,                                                  /* tp_reserved */
+    0,                                                  /* tp_repr */
+    0,                                                  /* tp_as_number */
+    0,                                                  /* tp_as_sequence */
+    0,                                                  /* tp_as_mapping */
+    0,                                                  /* tp_hash */
+    0,                                                  /* tp_call */
+    0,                                                  /* tp_str */
+    0,                                                  /* tp_getattro */
+    0,                                                  /* tp_setattro */
+    0,                                                  /* tp_as_buffer */
+    Py_TPFLAGS_DEFAULT,                                 /* tp_flags */
+    kqueue_queue_doc,                                   /* tp_doc */
+    0,                                                  /* tp_traverse */
+    0,                                                  /* tp_clear */
+    0,                                                  /* tp_richcompare */
+    0,                                                  /* tp_weaklistoffset */
+    0,                                                  /* tp_iter */
+    0,                                                  /* tp_iternext */
+    kqueue_queue_methods,                               /* tp_methods */
+    0,                                                  /* tp_members */
+    kqueue_queue_getsetlist,                            /* tp_getset */
+    0,                                                  /* tp_base */
+    0,                                                  /* tp_dict */
+    0,                                                  /* tp_descr_get */
+    0,                                                  /* tp_descr_set */
+    0,                                                  /* tp_dictoffset */
+    0,                                                  /* tp_init */
+    0,                                                  /* tp_alloc */
+    kqueue_queue_new,                                   /* tp_new */
+    0,                                                  /* tp_free */
+};
+
+#endif /* HAVE_KQUEUE */
+
+
+
+
+
+/* ************************************************************************ */
+
+PyDoc_STRVAR(select_doc,
+"select(rlist, wlist, xlist[, timeout]) -> (rlist, wlist, xlist)\n\
+\n\
+Wait until one or more file descriptors are ready for some kind of I/O.\n\
+The first three arguments are sequences of file descriptors to be waited for:\n\
+rlist -- wait until ready for reading\n\
+wlist -- wait until ready for writing\n\
+xlist -- wait for an ``exceptional condition''\n\
+If only one kind of condition is required, pass [] for the other lists.\n\
+A file descriptor is either a socket or file object, or a small integer\n\
+gotten from a fileno() method call on one of those.\n\
+\n\
+The optional 4th argument specifies a timeout in seconds; it may be\n\
+a floating point number to specify fractions of seconds.  If it is absent\n\
+or None, the call will never time out.\n\
+\n\
+The return value is a tuple of three lists corresponding to the first three\n\
+arguments; each contains the subset of the corresponding file descriptors\n\
+that are ready.\n\
+\n\
+*** IMPORTANT NOTICE ***\n\
+On Windows and OpenVMS, only sockets are supported; on Unix, all file\n\
+descriptors can be used.");
+
+static PyMethodDef select_methods[] = {
+    {"select",          select_select,  METH_VARARGS,   select_doc},
+#if defined(HAVE_POLL) && !defined(HAVE_BROKEN_POLL)
+    {"poll",            select_poll,    METH_NOARGS,    poll_doc},
+#endif /* HAVE_POLL */
+#ifdef HAVE_SYS_DEVPOLL_H
+    {"devpoll",         select_devpoll, METH_NOARGS,    devpoll_doc},
+#endif
+    {0,         0},     /* sentinel */
+};
+
+PyDoc_STRVAR(module_doc,
+"This module supports asynchronous I/O on multiple file descriptors.\n\
+\n\
+*** IMPORTANT NOTICE ***\n\
+On Windows and OpenVMS, only sockets are supported; on Unix, all file descriptors.");
+
+
+static struct PyModuleDef selectmodule = {
+    PyModuleDef_HEAD_INIT,
+    "_select",
+    module_doc,
+    -1,
+    select_methods,
+    NULL,
+    NULL,
+    NULL,
+    NULL
+};
+
+
+
+
+PyMODINIT_FUNC
+PyInit__select(void)
+{
+    PyObject *m;
+    m = PyModule_Create(&selectmodule);
+    if (m == NULL)
+        return NULL;
+
+    Py_INCREF(PyExc_OSError);
+    PyModule_AddObject(m, "error", PyExc_OSError);
+
+#ifdef PIPE_BUF
+#ifdef HAVE_BROKEN_PIPE_BUF
+#undef PIPE_BUF
+#define PIPE_BUF 512
+#endif
+    PyModule_AddIntMacro(m, PIPE_BUF);
+#endif
+
+#if defined(HAVE_POLL) && !defined(HAVE_BROKEN_POLL)
+#ifdef __APPLE__
+    if (select_have_broken_poll()) {
+        if (PyObject_DelAttrString(m, "poll") == -1) {
+            PyErr_Clear();
+        }
+    } else {
+#else
+    {
+#endif
+        if (PyType_Ready(&poll_Type) < 0)
+            return NULL;
+        PyModule_AddIntMacro(m, POLLIN);
+        PyModule_AddIntMacro(m, POLLPRI);
+        PyModule_AddIntMacro(m, POLLOUT);
+        PyModule_AddIntMacro(m, POLLERR);
+        PyModule_AddIntMacro(m, POLLHUP);
+        PyModule_AddIntMacro(m, POLLNVAL);
+
+#ifdef POLLRDNORM
+        PyModule_AddIntMacro(m, POLLRDNORM);
+#endif
+#ifdef POLLRDBAND
+        PyModule_AddIntMacro(m, POLLRDBAND);
+#endif
+#ifdef POLLWRNORM
+        PyModule_AddIntMacro(m, POLLWRNORM);
+#endif
+#ifdef POLLWRBAND
+        PyModule_AddIntMacro(m, POLLWRBAND);
+#endif
+#ifdef POLLMSG
+        PyModule_AddIntMacro(m, POLLMSG);
+#endif
+    }
+#endif /* HAVE_POLL */
+
+#ifdef HAVE_SYS_DEVPOLL_H
+    if (PyType_Ready(&devpoll_Type) < 0)
+        return NULL;
+#endif
+
+#ifdef HAVE_EPOLL
+    Py_TYPE(&pyEpoll_Type) = &PyType_Type;
+    if (PyType_Ready(&pyEpoll_Type) < 0)
+        return NULL;
+
+    Py_INCREF(&pyEpoll_Type);
+    PyModule_AddObject(m, "epoll", (PyObject *) &pyEpoll_Type);
+
+    PyModule_AddIntMacro(m, EPOLLIN);
+    PyModule_AddIntMacro(m, EPOLLOUT);
+    PyModule_AddIntMacro(m, EPOLLPRI);
+    PyModule_AddIntMacro(m, EPOLLERR);
+    PyModule_AddIntMacro(m, EPOLLHUP);
+    PyModule_AddIntMacro(m, EPOLLET);
+#ifdef EPOLLONESHOT
+    /* Kernel 2.6.2+ */
+    PyModule_AddIntMacro(m, EPOLLONESHOT);
+#endif
+    /* PyModule_AddIntConstant(m, "EPOLL_RDHUP", EPOLLRDHUP); */
+    PyModule_AddIntMacro(m, EPOLLRDNORM);
+    PyModule_AddIntMacro(m, EPOLLRDBAND);
+    PyModule_AddIntMacro(m, EPOLLWRNORM);
+    PyModule_AddIntMacro(m, EPOLLWRBAND);
+    PyModule_AddIntMacro(m, EPOLLMSG);
+
+#ifdef EPOLL_CLOEXEC
+    PyModule_AddIntMacro(m, EPOLL_CLOEXEC);
+#endif
+#endif /* HAVE_EPOLL */
+
+#ifdef HAVE_KQUEUE
+    kqueue_event_Type.tp_new = PyType_GenericNew;
+    Py_TYPE(&kqueue_event_Type) = &PyType_Type;
+    if(PyType_Ready(&kqueue_event_Type) < 0)
+        return NULL;
+
+    Py_INCREF(&kqueue_event_Type);
+    PyModule_AddObject(m, "kevent", (PyObject *)&kqueue_event_Type);
+
+    Py_TYPE(&kqueue_queue_Type) = &PyType_Type;
+    if(PyType_Ready(&kqueue_queue_Type) < 0)
+        return NULL;
+    Py_INCREF(&kqueue_queue_Type);
+    PyModule_AddObject(m, "kqueue", (PyObject *)&kqueue_queue_Type);
+
+    /* event filters */
+    PyModule_AddIntConstant(m, "KQ_FILTER_READ", EVFILT_READ);
+    PyModule_AddIntConstant(m, "KQ_FILTER_WRITE", EVFILT_WRITE);
+    PyModule_AddIntConstant(m, "KQ_FILTER_AIO", EVFILT_AIO);
+    PyModule_AddIntConstant(m, "KQ_FILTER_VNODE", EVFILT_VNODE);
+    PyModule_AddIntConstant(m, "KQ_FILTER_PROC", EVFILT_PROC);
+#ifdef EVFILT_NETDEV
+    PyModule_AddIntConstant(m, "KQ_FILTER_NETDEV", EVFILT_NETDEV);
+#endif
+    PyModule_AddIntConstant(m, "KQ_FILTER_SIGNAL", EVFILT_SIGNAL);
+    PyModule_AddIntConstant(m, "KQ_FILTER_TIMER", EVFILT_TIMER);
+
+    /* event flags */
+    PyModule_AddIntConstant(m, "KQ_EV_ADD", EV_ADD);
+    PyModule_AddIntConstant(m, "KQ_EV_DELETE", EV_DELETE);
+    PyModule_AddIntConstant(m, "KQ_EV_ENABLE", EV_ENABLE);
+    PyModule_AddIntConstant(m, "KQ_EV_DISABLE", EV_DISABLE);
+    PyModule_AddIntConstant(m, "KQ_EV_ONESHOT", EV_ONESHOT);
+    PyModule_AddIntConstant(m, "KQ_EV_CLEAR", EV_CLEAR);
+
+    PyModule_AddIntConstant(m, "KQ_EV_SYSFLAGS", EV_SYSFLAGS);
+    PyModule_AddIntConstant(m, "KQ_EV_FLAG1", EV_FLAG1);
+
+    PyModule_AddIntConstant(m, "KQ_EV_EOF", EV_EOF);
+    PyModule_AddIntConstant(m, "KQ_EV_ERROR", EV_ERROR);
+
+    /* READ WRITE filter flag */
+    PyModule_AddIntConstant(m, "KQ_NOTE_LOWAT", NOTE_LOWAT);
+
+    /* VNODE filter flags  */
+    PyModule_AddIntConstant(m, "KQ_NOTE_DELETE", NOTE_DELETE);
+    PyModule_AddIntConstant(m, "KQ_NOTE_WRITE", NOTE_WRITE);
+    PyModule_AddIntConstant(m, "KQ_NOTE_EXTEND", NOTE_EXTEND);
+    PyModule_AddIntConstant(m, "KQ_NOTE_ATTRIB", NOTE_ATTRIB);
+    PyModule_AddIntConstant(m, "KQ_NOTE_LINK", NOTE_LINK);
+    PyModule_AddIntConstant(m, "KQ_NOTE_RENAME", NOTE_RENAME);
+    PyModule_AddIntConstant(m, "KQ_NOTE_REVOKE", NOTE_REVOKE);
+
+    /* PROC filter flags  */
+    PyModule_AddIntConstant(m, "KQ_NOTE_EXIT", NOTE_EXIT);
+    PyModule_AddIntConstant(m, "KQ_NOTE_FORK", NOTE_FORK);
+    PyModule_AddIntConstant(m, "KQ_NOTE_EXEC", NOTE_EXEC);
+    PyModule_AddIntConstant(m, "KQ_NOTE_PCTRLMASK", NOTE_PCTRLMASK);
+    PyModule_AddIntConstant(m, "KQ_NOTE_PDATAMASK", NOTE_PDATAMASK);
+
+    PyModule_AddIntConstant(m, "KQ_NOTE_TRACK", NOTE_TRACK);
+    PyModule_AddIntConstant(m, "KQ_NOTE_CHILD", NOTE_CHILD);
+    PyModule_AddIntConstant(m, "KQ_NOTE_TRACKERR", NOTE_TRACKERR);
+
+    /* NETDEV filter flags */
+#ifdef EVFILT_NETDEV
+    PyModule_AddIntConstant(m, "KQ_NOTE_LINKUP", NOTE_LINKUP);
+    PyModule_AddIntConstant(m, "KQ_NOTE_LINKDOWN", NOTE_LINKDOWN);
+    PyModule_AddIntConstant(m, "KQ_NOTE_LINKINV", NOTE_LINKINV);
+#endif
+
+#endif /* HAVE_KQUEUE */
+    return m;
+}
diff -r 1287d4c9cd39 Modules/selectmodule.c
--- a/Modules/selectmodule.c	Fri Aug 02 10:22:07 2013 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,2334 +0,0 @@
-/* select - Module containing unix select(2) call.
-   Under Unix, the file descriptors are small integers.
-   Under Win32, select only exists for sockets, and sockets may
-   have any value except INVALID_SOCKET.
-*/
-
-#include "Python.h"
-#include <structmember.h>
-
-#ifdef HAVE_SYS_DEVPOLL_H
-#include <sys/resource.h>
-#include <sys/devpoll.h>
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <fcntl.h>
-#endif
-
-#ifdef __APPLE__
-    /* Perform runtime testing for a broken poll on OSX to make it easier
-     * to use the same binary on multiple releases of the OS.
-     */
-#undef HAVE_BROKEN_POLL
-#endif
-
-/* Windows #defines FD_SETSIZE to 64 if FD_SETSIZE isn't already defined.
-   64 is too small (too many people have bumped into that limit).
-   Here we boost it.
-   Users who want even more than the boosted limit should #define
-   FD_SETSIZE higher before this; e.g., via compiler /D switch.
-*/
-#if defined(MS_WINDOWS) && !defined(FD_SETSIZE)
-#define FD_SETSIZE 512
-#endif
-
-#if defined(HAVE_POLL_H)
-#include <poll.h>
-#elif defined(HAVE_SYS_POLL_H)
-#include <sys/poll.h>
-#endif
-
-#ifdef __sgi
-/* This is missing from unistd.h */
-extern void bzero(void *, int);
-#endif
-
-#ifdef HAVE_SYS_TYPES_H
-#include <sys/types.h>
-#endif
-
-#ifdef MS_WINDOWS
-#  define WIN32_LEAN_AND_MEAN
-#  include <winsock.h>
-#else
-#  define SOCKET int
-#  if defined(__VMS)
-#    include <socket.h>
-#  endif
-#endif
-
-/* list of Python objects and their file descriptor */
-typedef struct {
-    PyObject *obj;                           /* owned reference */
-    SOCKET fd;
-    int sentinel;                            /* -1 == sentinel */
-} pylist;
-
-static void
-reap_obj(pylist fd2obj[FD_SETSIZE + 1])
-{
-    int i;
-    for (i = 0; i < FD_SETSIZE + 1 && fd2obj[i].sentinel >= 0; i++) {
-        Py_XDECREF(fd2obj[i].obj);
-        fd2obj[i].obj = NULL;
-    }
-    fd2obj[0].sentinel = -1;
-}
-
-
-/* returns -1 and sets the Python exception if an error occurred, otherwise
-   returns a number >= 0
-*/
-static int
-seq2set(PyObject *seq, fd_set *set, pylist fd2obj[FD_SETSIZE + 1])
-{
-    int max = -1;
-    int index = 0;
-    Py_ssize_t i;
-    PyObject* fast_seq = NULL;
-    PyObject* o = NULL;
-
-    fd2obj[0].obj = (PyObject*)0;            /* set list to zero size */
-    FD_ZERO(set);
-
-    fast_seq = PySequence_Fast(seq, "arguments 1-3 must be sequences");
-    if (!fast_seq)
-        return -1;
-
-    for (i = 0; i < PySequence_Fast_GET_SIZE(fast_seq); i++)  {
-        SOCKET v;
-
-        /* any intervening fileno() calls could decr this refcnt */
-        if (!(o = PySequence_Fast_GET_ITEM(fast_seq, i)))
-            goto finally;
-
-        Py_INCREF(o);
-        v = PyObject_AsFileDescriptor( o );
-        if (v == -1) goto finally;
-
-#if defined(_MSC_VER)
-        max = 0;                             /* not used for Win32 */
-#else  /* !_MSC_VER */
-        if (!_PyIsSelectable_fd(v)) {
-            PyErr_SetString(PyExc_ValueError,
-                        "filedescriptor out of range in select()");
-            goto finally;
-        }
-        if (v > max)
-            max = v;
-#endif /* _MSC_VER */
-        FD_SET(v, set);
-
-        /* add object and its file descriptor to the list */
-        if (index >= FD_SETSIZE) {
-            PyErr_SetString(PyExc_ValueError,
-                          "too many file descriptors in select()");
-            goto finally;
-        }
-        fd2obj[index].obj = o;
-        fd2obj[index].fd = v;
-        fd2obj[index].sentinel = 0;
-        fd2obj[++index].sentinel = -1;
-    }
-    Py_DECREF(fast_seq);
-    return max+1;
-
-  finally:
-    Py_XDECREF(o);
-    Py_DECREF(fast_seq);
-    return -1;
-}
-
-/* returns NULL and sets the Python exception if an error occurred */
-static PyObject *
-set2list(fd_set *set, pylist fd2obj[FD_SETSIZE + 1])
-{
-    int i, j, count=0;
-    PyObject *list, *o;
-    SOCKET fd;
-
-    for (j = 0; fd2obj[j].sentinel >= 0; j++) {
-        if (FD_ISSET(fd2obj[j].fd, set))
-            count++;
-    }
-    list = PyList_New(count);
-    if (!list)
-        return NULL;
-
-    i = 0;
-    for (j = 0; fd2obj[j].sentinel >= 0; j++) {
-        fd = fd2obj[j].fd;
-        if (FD_ISSET(fd, set)) {
-            o = fd2obj[j].obj;
-            fd2obj[j].obj = NULL;
-            /* transfer ownership */
-            if (PyList_SetItem(list, i, o) < 0)
-                goto finally;
-
-            i++;
-        }
-    }
-    return list;
-  finally:
-    Py_DECREF(list);
-    return NULL;
-}
-
-#undef SELECT_USES_HEAP
-#if FD_SETSIZE > 1024
-#define SELECT_USES_HEAP
-#endif /* FD_SETSIZE > 1024 */
-
-static PyObject *
-select_select(PyObject *self, PyObject *args)
-{
-#ifdef SELECT_USES_HEAP
-    pylist *rfd2obj, *wfd2obj, *efd2obj;
-#else  /* !SELECT_USES_HEAP */
-    /* XXX: All this should probably be implemented as follows:
-     * - find the highest descriptor we're interested in
-     * - add one
-     * - that's the size
-     * See: Stevens, APitUE, $12.5.1
-     */
-    pylist rfd2obj[FD_SETSIZE + 1];
-    pylist wfd2obj[FD_SETSIZE + 1];
-    pylist efd2obj[FD_SETSIZE + 1];
-#endif /* SELECT_USES_HEAP */
-    PyObject *ifdlist, *ofdlist, *efdlist;
-    PyObject *ret = NULL;
-    PyObject *tout = Py_None;
-    fd_set ifdset, ofdset, efdset;
-    struct timeval tv, *tvp;
-    int imax, omax, emax, max;
-    int n;
-
-    /* convert arguments */
-    if (!PyArg_UnpackTuple(args, "select", 3, 4,
-                          &ifdlist, &ofdlist, &efdlist, &tout))
-        return NULL;
-
-    if (tout == Py_None)
-        tvp = (struct timeval *)0;
-    else if (!PyNumber_Check(tout)) {
-        PyErr_SetString(PyExc_TypeError,
-                        "timeout must be a float or None");
-        return NULL;
-    }
-    else {
-#ifdef MS_WINDOWS
-        time_t sec;
-        if (_PyTime_ObjectToTimeval(tout, &sec, &tv.tv_usec) == -1)
-            return NULL;
-        assert(sizeof(tv.tv_sec) == sizeof(long));
-#if SIZEOF_TIME_T > SIZEOF_LONG
-        if (sec > LONG_MAX) {
-            PyErr_SetString(PyExc_OverflowError,
-                            "timeout is too large");
-            return NULL;
-        }
-#endif
-        tv.tv_sec = (long)sec;
-#else
-        /* 64-bit OS X has struct timeval.tv_usec as an int (and thus still 4
-           bytes as required), but no longer defined by a long. */
-        long tv_usec;
-        if (_PyTime_ObjectToTimeval(tout, &tv.tv_sec, &tv_usec) == -1)
-            return NULL;
-        tv.tv_usec = tv_usec;
-#endif
-        if (tv.tv_sec < 0) {
-            PyErr_SetString(PyExc_ValueError, "timeout must be non-negative");
-            return NULL;
-        }
-        tvp = &tv;
-    }
-
-
-#ifdef SELECT_USES_HEAP
-    /* Allocate memory for the lists */
-    rfd2obj = PyMem_NEW(pylist, FD_SETSIZE + 1);
-    wfd2obj = PyMem_NEW(pylist, FD_SETSIZE + 1);
-    efd2obj = PyMem_NEW(pylist, FD_SETSIZE + 1);
-    if (rfd2obj == NULL || wfd2obj == NULL || efd2obj == NULL) {
-        if (rfd2obj) PyMem_DEL(rfd2obj);
-        if (wfd2obj) PyMem_DEL(wfd2obj);
-        if (efd2obj) PyMem_DEL(efd2obj);
-        return PyErr_NoMemory();
-    }
-#endif /* SELECT_USES_HEAP */
-    /* Convert sequences to fd_sets, and get maximum fd number
-     * propagates the Python exception set in seq2set()
-     */
-    rfd2obj[0].sentinel = -1;
-    wfd2obj[0].sentinel = -1;
-    efd2obj[0].sentinel = -1;
-    if ((imax=seq2set(ifdlist, &ifdset, rfd2obj)) < 0)
-        goto finally;
-    if ((omax=seq2set(ofdlist, &ofdset, wfd2obj)) < 0)
-        goto finally;
-    if ((emax=seq2set(efdlist, &efdset, efd2obj)) < 0)
-        goto finally;
-    max = imax;
-    if (omax > max) max = omax;
-    if (emax > max) max = emax;
-
-    Py_BEGIN_ALLOW_THREADS
-    n = select(max, &ifdset, &ofdset, &efdset, tvp);
-    Py_END_ALLOW_THREADS
-
-#ifdef MS_WINDOWS
-    if (n == SOCKET_ERROR) {
-        PyErr_SetExcFromWindowsErr(PyExc_OSError, WSAGetLastError());
-    }
-#else
-    if (n < 0) {
-        PyErr_SetFromErrno(PyExc_OSError);
-    }
-#endif
-    else {
-        /* any of these three calls can raise an exception.  it's more
-           convenient to test for this after all three calls... but
-           is that acceptable?
-        */
-        ifdlist = set2list(&ifdset, rfd2obj);
-        ofdlist = set2list(&ofdset, wfd2obj);
-        efdlist = set2list(&efdset, efd2obj);
-        if (PyErr_Occurred())
-            ret = NULL;
-        else
-            ret = PyTuple_Pack(3, ifdlist, ofdlist, efdlist);
-
-        Py_XDECREF(ifdlist);
-        Py_XDECREF(ofdlist);
-        Py_XDECREF(efdlist);
-    }
-
-  finally:
-    reap_obj(rfd2obj);
-    reap_obj(wfd2obj);
-    reap_obj(efd2obj);
-#ifdef SELECT_USES_HEAP
-    PyMem_DEL(rfd2obj);
-    PyMem_DEL(wfd2obj);
-    PyMem_DEL(efd2obj);
-#endif /* SELECT_USES_HEAP */
-    return ret;
-}
-
-#if defined(HAVE_POLL) && !defined(HAVE_BROKEN_POLL)
-/*
- * poll() support
- */
-
-typedef struct {
-    PyObject_HEAD
-    PyObject *dict;
-    int ufd_uptodate;
-    int ufd_len;
-    struct pollfd *ufds;
-} pollObject;
-
-static PyTypeObject poll_Type;
-
-/* Update the malloc'ed array of pollfds to match the dictionary
-   contained within a pollObject.  Return 1 on success, 0 on an error.
-*/
-
-static int
-update_ufd_array(pollObject *self)
-{
-    Py_ssize_t i, pos;
-    PyObject *key, *value;
-    struct pollfd *old_ufds = self->ufds;
-
-    self->ufd_len = PyDict_Size(self->dict);
-    PyMem_RESIZE(self->ufds, struct pollfd, self->ufd_len);
-    if (self->ufds == NULL) {
-        self->ufds = old_ufds;
-        PyErr_NoMemory();
-        return 0;
-    }
-
-    i = pos = 0;
-    while (PyDict_Next(self->dict, &pos, &key, &value)) {
-        assert(i < self->ufd_len);
-        /* Never overflow */
-        self->ufds[i].fd = (int)PyLong_AsLong(key);
-        self->ufds[i].events = (short)PyLong_AsLong(value);
-        i++;
-    }
-    assert(i == self->ufd_len);
-    self->ufd_uptodate = 1;
-    return 1;
-}
-
-PyDoc_STRVAR(poll_register_doc,
-"register(fd [, eventmask] ) -> None\n\n\
-Register a file descriptor with the polling object.\n\
-fd -- either an integer, or an object with a fileno() method returning an\n\
-      int.\n\
-events -- an optional bitmask describing the type of events to check for");
-
-static PyObject *
-poll_register(pollObject *self, PyObject *args)
-{
-    PyObject *o, *key, *value;
-    int fd;
-    short events = POLLIN | POLLPRI | POLLOUT;
-    int err;
-
-    if (!PyArg_ParseTuple(args, "O|h:register", &o, &events)) {
-        return NULL;
-    }
-
-    fd = PyObject_AsFileDescriptor(o);
-    if (fd == -1) return NULL;
-
-    /* Add entry to the internal dictionary: the key is the
-       file descriptor, and the value is the event mask. */
-    key = PyLong_FromLong(fd);
-    if (key == NULL)
-        return NULL;
-    value = PyLong_FromLong(events);
-    if (value == NULL) {
-        Py_DECREF(key);
-        return NULL;
-    }
-    err = PyDict_SetItem(self->dict, key, value);
-    Py_DECREF(key);
-    Py_DECREF(value);
-    if (err < 0)
-        return NULL;
-
-    self->ufd_uptodate = 0;
-
-    Py_INCREF(Py_None);
-    return Py_None;
-}
-
-PyDoc_STRVAR(poll_modify_doc,
-"modify(fd, eventmask) -> None\n\n\
-Modify an already registered file descriptor.\n\
-fd -- either an integer, or an object with a fileno() method returning an\n\
-      int.\n\
-events -- an optional bitmask describing the type of events to check for");
-
-static PyObject *
-poll_modify(pollObject *self, PyObject *args)
-{
-    PyObject *o, *key, *value;
-    int fd, events;
-    int err;
-
-    if (!PyArg_ParseTuple(args, "Oi:modify", &o, &events)) {
-        return NULL;
-    }
-
-    fd = PyObject_AsFileDescriptor(o);
-    if (fd == -1) return NULL;
-
-    /* Modify registered fd */
-    key = PyLong_FromLong(fd);
-    if (key == NULL)
-        return NULL;
-    if (PyDict_GetItem(self->dict, key) == NULL) {
-        errno = ENOENT;
-        PyErr_SetFromErrno(PyExc_OSError);
-        Py_DECREF(key);
-        return NULL;
-    }
-    value = PyLong_FromLong(events);
-    if (value == NULL) {
-        Py_DECREF(key);
-        return NULL;
-    }
-    err = PyDict_SetItem(self->dict, key, value);
-    Py_DECREF(key);
-    Py_DECREF(value);
-    if (err < 0)
-        return NULL;
-
-    self->ufd_uptodate = 0;
-
-    Py_INCREF(Py_None);
-    return Py_None;
-}
-
-
-PyDoc_STRVAR(poll_unregister_doc,
-"unregister(fd) -> None\n\n\
-Remove a file descriptor being tracked by the polling object.");
-
-static PyObject *
-poll_unregister(pollObject *self, PyObject *o)
-{
-    PyObject *key;
-    int fd;
-
-    fd = PyObject_AsFileDescriptor( o );
-    if (fd == -1)
-        return NULL;
-
-    /* Check whether the fd is already in the array */
-    key = PyLong_FromLong(fd);
-    if (key == NULL)
-        return NULL;
-
-    if (PyDict_DelItem(self->dict, key) == -1) {
-        Py_DECREF(key);
-        /* This will simply raise the KeyError set by PyDict_DelItem
-           if the file descriptor isn't registered. */
-        return NULL;
-    }
-
-    Py_DECREF(key);
-    self->ufd_uptodate = 0;
-
-    Py_INCREF(Py_None);
-    return Py_None;
-}
-
-PyDoc_STRVAR(poll_poll_doc,
-"poll( [timeout] ) -> list of (fd, event) 2-tuples\n\n\
-Polls the set of registered file descriptors, returning a list containing \n\
-any descriptors that have events or errors to report.");
-
-static PyObject *
-poll_poll(pollObject *self, PyObject *args)
-{
-    PyObject *result_list = NULL, *tout = NULL;
-    int timeout = 0, poll_result, i, j;
-    PyObject *value = NULL, *num = NULL;
-
-    if (!PyArg_UnpackTuple(args, "poll", 0, 1, &tout)) {
-        return NULL;
-    }
-
-    /* Check values for timeout */
-    if (tout == NULL || tout == Py_None)
-        timeout = -1;
-    else if (!PyNumber_Check(tout)) {
-        PyErr_SetString(PyExc_TypeError,
-                        "timeout must be an integer or None");
-        return NULL;
-    }
-    else {
-        tout = PyNumber_Long(tout);
-        if (!tout)
-            return NULL;
-        timeout = _PyLong_AsInt(tout);
-        Py_DECREF(tout);
-        if (timeout == -1 && PyErr_Occurred())
-            return NULL;
-    }
-
-    /* Ensure the ufd array is up to date */
-    if (!self->ufd_uptodate)
-        if (update_ufd_array(self) == 0)
-            return NULL;
-
-    /* call poll() */
-    Py_BEGIN_ALLOW_THREADS
-    poll_result = poll(self->ufds, self->ufd_len, timeout);
-    Py_END_ALLOW_THREADS
-
-    if (poll_result < 0) {
-        PyErr_SetFromErrno(PyExc_OSError);
-        return NULL;
-    }
-
-    /* build the result list */
-
-    result_list = PyList_New(poll_result);
-    if (!result_list)
-        return NULL;
-    else {
-        for (i = 0, j = 0; j < poll_result; j++) {
-            /* skip to the next fired descriptor */
-            while (!self->ufds[i].revents) {
-                i++;
-            }
-            /* if we hit a NULL return, set value to NULL
-               and break out of loop; code at end will
-               clean up result_list */
-            value = PyTuple_New(2);
-            if (value == NULL)
-                goto error;
-            num = PyLong_FromLong(self->ufds[i].fd);
-            if (num == NULL) {
-                Py_DECREF(value);
-                goto error;
-            }
-            PyTuple_SET_ITEM(value, 0, num);
-
-            /* The &0xffff is a workaround for AIX.  'revents'
-               is a 16-bit short, and IBM assigned POLLNVAL
-               to be 0x8000, so the conversion to int results
-               in a negative number. See SF bug #923315. */
-            num = PyLong_FromLong(self->ufds[i].revents & 0xffff);
-            if (num == NULL) {
-                Py_DECREF(value);
-                goto error;
-            }
-            PyTuple_SET_ITEM(value, 1, num);
-            if ((PyList_SetItem(result_list, j, value)) == -1) {
-                Py_DECREF(value);
-                goto error;
-            }
-            i++;
-        }
-    }
-    return result_list;
-
-  error:
-    Py_DECREF(result_list);
-    return NULL;
-}
-
-static PyMethodDef poll_methods[] = {
-    {"register",        (PyCFunction)poll_register,
-     METH_VARARGS,  poll_register_doc},
-    {"modify",          (PyCFunction)poll_modify,
-     METH_VARARGS,  poll_modify_doc},
-    {"unregister",      (PyCFunction)poll_unregister,
-     METH_O,        poll_unregister_doc},
-    {"poll",            (PyCFunction)poll_poll,
-     METH_VARARGS,  poll_poll_doc},
-    {NULL,              NULL}           /* sentinel */
-};
-
-static pollObject *
-newPollObject(void)
-{
-    pollObject *self;
-    self = PyObject_New(pollObject, &poll_Type);
-    if (self == NULL)
-        return NULL;
-    /* ufd_uptodate is a Boolean, denoting whether the
-       array pointed to by ufds matches the contents of the dictionary. */
-    self->ufd_uptodate = 0;
-    self->ufds = NULL;
-    self->dict = PyDict_New();
-    if (self->dict == NULL) {
-        Py_DECREF(self);
-        return NULL;
-    }
-    return self;
-}
-
-static void
-poll_dealloc(pollObject *self)
-{
-    if (self->ufds != NULL)
-        PyMem_DEL(self->ufds);
-    Py_XDECREF(self->dict);
-    PyObject_Del(self);
-}
-
-static PyTypeObject poll_Type = {
-    /* The ob_type field must be initialized in the module init function
-     * to be portable to Windows without using C++. */
-    PyVarObject_HEAD_INIT(NULL, 0)
-    "select.poll",              /*tp_name*/
-    sizeof(pollObject),         /*tp_basicsize*/
-    0,                          /*tp_itemsize*/
-    /* methods */
-    (destructor)poll_dealloc, /*tp_dealloc*/
-    0,                          /*tp_print*/
-    0,                          /*tp_getattr*/
-    0,                      /*tp_setattr*/
-    0,                          /*tp_reserved*/
-    0,                          /*tp_repr*/
-    0,                          /*tp_as_number*/
-    0,                          /*tp_as_sequence*/
-    0,                          /*tp_as_mapping*/
-    0,                          /*tp_hash*/
-    0,                          /*tp_call*/
-    0,                          /*tp_str*/
-    0,                          /*tp_getattro*/
-    0,                          /*tp_setattro*/
-    0,                          /*tp_as_buffer*/
-    Py_TPFLAGS_DEFAULT,         /*tp_flags*/
-    0,                          /*tp_doc*/
-    0,                          /*tp_traverse*/
-    0,                          /*tp_clear*/
-    0,                          /*tp_richcompare*/
-    0,                          /*tp_weaklistoffset*/
-    0,                          /*tp_iter*/
-    0,                          /*tp_iternext*/
-    poll_methods,               /*tp_methods*/
-};
-
-#ifdef HAVE_SYS_DEVPOLL_H
-typedef struct {
-    PyObject_HEAD
-    int fd_devpoll;
-    int max_n_fds;
-    int n_fds;
-    struct pollfd *fds;
-} devpollObject;
-
-static PyTypeObject devpoll_Type;
-
-static int devpoll_flush(devpollObject *self)
-{
-    int size, n;
-
-    if (!self->n_fds) return 0;
-
-    size = sizeof(struct pollfd)*self->n_fds;
-    self->n_fds = 0;
-
-    Py_BEGIN_ALLOW_THREADS
-    n = write(self->fd_devpoll, self->fds, size);
-    Py_END_ALLOW_THREADS
-
-    if (n == -1 ) {
-        PyErr_SetFromErrno(PyExc_IOError);
-        return -1;
-    }
-    if (n < size) {
-        /*
-        ** Data writed to /dev/poll is a binary data structure. It is not
-        ** clear what to do if a partial write occurred. For now, raise
-        ** an exception and see if we actually found this problem in
-        ** the wild.
-        ** See http://bugs.python.org/issue6397.
-        */
-        PyErr_Format(PyExc_IOError, "failed to write all pollfds. "
-                "Please, report at http://bugs.python.org/. "
-                "Data to report: Size tried: %d, actual size written: %d.",
-                size, n);
-        return -1;
-    }
-    return 0;
-}
-
-static PyObject *
-internal_devpoll_register(devpollObject *self, PyObject *args, int remove)
-{
-    PyObject *o;
-    int fd, events = POLLIN | POLLPRI | POLLOUT;
-
-    if (!PyArg_ParseTuple(args, "O|i:register", &o, &events)) {
-        return NULL;
-    }
-
-    fd = PyObject_AsFileDescriptor(o);
-    if (fd == -1) return NULL;
-
-    if (remove) {
-        self->fds[self->n_fds].fd = fd;
-        self->fds[self->n_fds].events = POLLREMOVE;
-
-        if (++self->n_fds == self->max_n_fds) {
-            if (devpoll_flush(self))
-                return NULL;
-        }
-    }
-
-    self->fds[self->n_fds].fd = fd;
-    self->fds[self->n_fds].events = events;
-
-    if (++self->n_fds == self->max_n_fds) {
-        if (devpoll_flush(self))
-            return NULL;
-    }
-
-    Py_RETURN_NONE;
-}
-
-PyDoc_STRVAR(devpoll_register_doc,
-"register(fd [, eventmask] ) -> None\n\n\
-Register a file descriptor with the polling object.\n\
-fd -- either an integer, or an object with a fileno() method returning an\n\
-      int.\n\
-events -- an optional bitmask describing the type of events to check for");
-
-static PyObject *
-devpoll_register(devpollObject *self, PyObject *args)
-{
-    return internal_devpoll_register(self, args, 0);
-}
-
-PyDoc_STRVAR(devpoll_modify_doc,
-"modify(fd[, eventmask]) -> None\n\n\
-Modify a possible already registered file descriptor.\n\
-fd -- either an integer, or an object with a fileno() method returning an\n\
-      int.\n\
-events -- an optional bitmask describing the type of events to check for");
-
-static PyObject *
-devpoll_modify(devpollObject *self, PyObject *args)
-{
-    return internal_devpoll_register(self, args, 1);
-}
-
-
-PyDoc_STRVAR(devpoll_unregister_doc,
-"unregister(fd) -> None\n\n\
-Remove a file descriptor being tracked by the polling object.");
-
-static PyObject *
-devpoll_unregister(devpollObject *self, PyObject *o)
-{
-    int fd;
-
-    fd = PyObject_AsFileDescriptor( o );
-    if (fd == -1)
-        return NULL;
-
-    self->fds[self->n_fds].fd = fd;
-    self->fds[self->n_fds].events = POLLREMOVE;
-
-    if (++self->n_fds == self->max_n_fds) {
-        if (devpoll_flush(self))
-            return NULL;
-    }
-
-    Py_RETURN_NONE;
-}
-
-PyDoc_STRVAR(devpoll_poll_doc,
-"poll( [timeout] ) -> list of (fd, event) 2-tuples\n\n\
-Polls the set of registered file descriptors, returning a list containing \n\
-any descriptors that have events or errors to report.");
-
-static PyObject *
-devpoll_poll(devpollObject *self, PyObject *args)
-{
-    struct dvpoll dvp;
-    PyObject *result_list = NULL, *tout = NULL;
-    int poll_result, i;
-    long timeout;
-    PyObject *value, *num1, *num2;
-
-    if (!PyArg_UnpackTuple(args, "poll", 0, 1, &tout)) {
-        return NULL;
-    }
-
-    /* Check values for timeout */
-    if (tout == NULL || tout == Py_None)
-        timeout = -1;
-    else if (!PyNumber_Check(tout)) {
-        PyErr_SetString(PyExc_TypeError,
-                        "timeout must be an integer or None");
-        return NULL;
-    }
-    else {
-        tout = PyNumber_Long(tout);
-        if (!tout)
-            return NULL;
-        timeout = PyLong_AsLong(tout);
-        Py_DECREF(tout);
-        if (timeout == -1 && PyErr_Occurred())
-            return NULL;
-    }
-
-    if ((timeout < -1) || (timeout > INT_MAX)) {
-        PyErr_SetString(PyExc_OverflowError,
-                        "timeout is out of range");
-        return NULL;
-    }
-
-    if (devpoll_flush(self))
-        return NULL;
-
-    dvp.dp_fds = self->fds;
-    dvp.dp_nfds = self->max_n_fds;
-    dvp.dp_timeout = timeout;
-
-    /* call devpoll() */
-    Py_BEGIN_ALLOW_THREADS
-    poll_result = ioctl(self->fd_devpoll, DP_POLL, &dvp);
-    Py_END_ALLOW_THREADS
-
-    if (poll_result < 0) {
-        PyErr_SetFromErrno(PyExc_IOError);
-        return NULL;
-    }
-
-    /* build the result list */
-
-    result_list = PyList_New(poll_result);
-    if (!result_list)
-        return NULL;
-    else {
-        for (i = 0; i < poll_result; i++) {
-            num1 = PyLong_FromLong(self->fds[i].fd);
-            num2 = PyLong_FromLong(self->fds[i].revents);
-            if ((num1 == NULL) || (num2 == NULL)) {
-                Py_XDECREF(num1);
-                Py_XDECREF(num2);
-                goto error;
-            }
-            value = PyTuple_Pack(2, num1, num2);
-            Py_DECREF(num1);
-            Py_DECREF(num2);
-            if (value == NULL)
-                goto error;
-            if ((PyList_SetItem(result_list, i, value)) == -1) {
-                Py_DECREF(value);
-                goto error;
-            }
-        }
-    }
-
-    return result_list;
-
-  error:
-    Py_DECREF(result_list);
-    return NULL;
-}
-
-static PyMethodDef devpoll_methods[] = {
-    {"register",        (PyCFunction)devpoll_register,
-     METH_VARARGS,  devpoll_register_doc},
-    {"modify",          (PyCFunction)devpoll_modify,
-     METH_VARARGS,  devpoll_modify_doc},
-    {"unregister",      (PyCFunction)devpoll_unregister,
-     METH_O,        devpoll_unregister_doc},
-    {"poll",            (PyCFunction)devpoll_poll,
-     METH_VARARGS,  devpoll_poll_doc},
-    {NULL,              NULL}           /* sentinel */
-};
-
-static devpollObject *
-newDevPollObject(void)
-{
-    devpollObject *self;
-    int fd_devpoll, limit_result;
-    struct pollfd *fds;
-    struct rlimit limit;
-
-    Py_BEGIN_ALLOW_THREADS
-    /*
-    ** If we try to process more that getrlimit()
-    ** fds, the kernel will give an error, so
-    ** we set the limit here. It is a dynamic
-    ** value, because we can change rlimit() anytime.
-    */
-    limit_result = getrlimit(RLIMIT_NOFILE, &limit);
-    if (limit_result != -1)
-        fd_devpoll = open("/dev/poll", O_RDWR);
-    Py_END_ALLOW_THREADS
-
-    if (limit_result == -1) {
-        PyErr_SetFromErrno(PyExc_OSError);
-        return NULL;
-    }
-    if (fd_devpoll == -1) {
-        PyErr_SetFromErrnoWithFilename(PyExc_IOError, "/dev/poll");
-        return NULL;
-    }
-
-    fds = PyMem_NEW(struct pollfd, limit.rlim_cur);
-    if (fds == NULL) {
-        close(fd_devpoll);
-        PyErr_NoMemory();
-        return NULL;
-    }
-
-    self = PyObject_New(devpollObject, &devpoll_Type);
-    if (self == NULL) {
-        close(fd_devpoll);
-        PyMem_DEL(fds);
-        return NULL;
-    }
-    self->fd_devpoll = fd_devpoll;
-    self->max_n_fds = limit.rlim_cur;
-    self->n_fds = 0;
-    self->fds = fds;
-
-    return self;
-}
-
-static void
-devpoll_dealloc(devpollObject *self)
-{
-    Py_BEGIN_ALLOW_THREADS
-    close(self->fd_devpoll);
-    Py_END_ALLOW_THREADS
-
-    PyMem_DEL(self->fds);
-
-    PyObject_Del(self);
-}
-
-static PyTypeObject devpoll_Type = {
-    /* The ob_type field must be initialized in the module init function
-     * to be portable to Windows without using C++. */
-    PyVarObject_HEAD_INIT(NULL, 0)
-    "select.devpoll",           /*tp_name*/
-    sizeof(devpollObject),      /*tp_basicsize*/
-    0,                          /*tp_itemsize*/
-    /* methods */
-    (destructor)devpoll_dealloc, /*tp_dealloc*/
-    0,                          /*tp_print*/
-    0,                          /*tp_getattr*/
-    0,                          /*tp_setattr*/
-    0,                          /*tp_reserved*/
-    0,                          /*tp_repr*/
-    0,                          /*tp_as_number*/
-    0,                          /*tp_as_sequence*/
-    0,                          /*tp_as_mapping*/
-    0,                          /*tp_hash*/
-    0,                          /*tp_call*/
-    0,                          /*tp_str*/
-    0,                          /*tp_getattro*/
-    0,                          /*tp_setattro*/
-    0,                          /*tp_as_buffer*/
-    Py_TPFLAGS_DEFAULT,         /*tp_flags*/
-    0,                          /*tp_doc*/
-    0,                          /*tp_traverse*/
-    0,                          /*tp_clear*/
-    0,                          /*tp_richcompare*/
-    0,                          /*tp_weaklistoffset*/
-    0,                          /*tp_iter*/
-    0,                          /*tp_iternext*/
-    devpoll_methods,            /*tp_methods*/
-};
-#endif  /* HAVE_SYS_DEVPOLL_H */
-
-
-
-PyDoc_STRVAR(poll_doc,
-"Returns a polling object, which supports registering and\n\
-unregistering file descriptors, and then polling them for I/O events.");
-
-static PyObject *
-select_poll(PyObject *self, PyObject *unused)
-{
-    return (PyObject *)newPollObject();
-}
-
-#ifdef HAVE_SYS_DEVPOLL_H
-PyDoc_STRVAR(devpoll_doc,
-"Returns a polling object, which supports registering and\n\
-unregistering file descriptors, and then polling them for I/O events.");
-
-static PyObject *
-select_devpoll(PyObject *self, PyObject *unused)
-{
-    return (PyObject *)newDevPollObject();
-}
-#endif
-
-
-#ifdef __APPLE__
-/*
- * On some systems poll() sets errno on invalid file descriptors. We test
- * for this at runtime because this bug may be fixed or introduced between
- * OS releases.
- */
-static int select_have_broken_poll(void)
-{
-    int poll_test;
-    int filedes[2];
-
-    struct pollfd poll_struct = { 0, POLLIN|POLLPRI|POLLOUT, 0 };
-
-    /* Create a file descriptor to make invalid */
-    if (pipe(filedes) < 0) {
-        return 1;
-    }
-    poll_struct.fd = filedes[0];
-    close(filedes[0]);
-    close(filedes[1]);
-    poll_test = poll(&poll_struct, 1, 0);
-    if (poll_test < 0) {
-        return 1;
-    } else if (poll_test == 0 && poll_struct.revents != POLLNVAL) {
-        return 1;
-    }
-    return 0;
-}
-#endif /* __APPLE__ */
-
-#endif /* HAVE_POLL */
-
-#ifdef HAVE_EPOLL
-/* **************************************************************************
- *                      epoll interface for Linux 2.6
- *
- * Written by Christian Heimes
- * Inspired by Twisted's _epoll.pyx and select.poll()
- */
-
-#ifdef HAVE_SYS_EPOLL_H
-#include <sys/epoll.h>
-#endif
-
-typedef struct {
-    PyObject_HEAD
-    SOCKET epfd;                        /* epoll control file descriptor */
-} pyEpoll_Object;
-
-static PyTypeObject pyEpoll_Type;
-#define pyepoll_CHECK(op) (PyObject_TypeCheck((op), &pyEpoll_Type))
-
-static PyObject *
-pyepoll_err_closed(void)
-{
-    PyErr_SetString(PyExc_ValueError, "I/O operation on closed epoll fd");
-    return NULL;
-}
-
-static int
-pyepoll_internal_close(pyEpoll_Object *self)
-{
-    int save_errno = 0;
-    if (self->epfd >= 0) {
-        int epfd = self->epfd;
-        self->epfd = -1;
-        Py_BEGIN_ALLOW_THREADS
-        if (close(epfd) < 0)
-            save_errno = errno;
-        Py_END_ALLOW_THREADS
-    }
-    return save_errno;
-}
-
-static PyObject *
-newPyEpoll_Object(PyTypeObject *type, int sizehint, int flags, SOCKET fd)
-{
-    pyEpoll_Object *self;
-
-    assert(type != NULL && type->tp_alloc != NULL);
-    self = (pyEpoll_Object *) type->tp_alloc(type, 0);
-    if (self == NULL)
-        return NULL;
-
-    if (fd == -1) {
-        Py_BEGIN_ALLOW_THREADS
-#ifdef HAVE_EPOLL_CREATE1
-        if (flags)
-            self->epfd = epoll_create1(flags);
-        else
-#endif
-        self->epfd = epoll_create(sizehint);
-        Py_END_ALLOW_THREADS
-    }
-    else {
-        self->epfd = fd;
-    }
-    if (self->epfd < 0) {
-        Py_DECREF(self);
-        PyErr_SetFromErrno(PyExc_OSError);
-        return NULL;
-    }
-    return (PyObject *)self;
-}
-
-
-static PyObject *
-pyepoll_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
-{
-    int flags = 0, sizehint = FD_SETSIZE - 1;
-    static char *kwlist[] = {"sizehint", "flags", NULL};
-
-    if (!PyArg_ParseTupleAndKeywords(args, kwds, "|ii:epoll", kwlist,
-                                     &sizehint, &flags))
-        return NULL;
-    if (sizehint < 0) {
-        PyErr_SetString(PyExc_ValueError, "negative sizehint");
-        return NULL;
-    }
-
-    return newPyEpoll_Object(type, sizehint, flags, -1);
-}
-
-
-static void
-pyepoll_dealloc(pyEpoll_Object *self)
-{
-    (void)pyepoll_internal_close(self);
-    Py_TYPE(self)->tp_free(self);
-}
-
-static PyObject*
-pyepoll_close(pyEpoll_Object *self)
-{
-    errno = pyepoll_internal_close(self);
-    if (errno < 0) {
-        PyErr_SetFromErrno(PyExc_OSError);
-        return NULL;
-    }
-    Py_RETURN_NONE;
-}
-
-PyDoc_STRVAR(pyepoll_close_doc,
-"close() -> None\n\
-\n\
-Close the epoll control file descriptor. Further operations on the epoll\n\
-object will raise an exception.");
-
-static PyObject*
-pyepoll_get_closed(pyEpoll_Object *self)
-{
-    if (self->epfd < 0)
-        Py_RETURN_TRUE;
-    else
-        Py_RETURN_FALSE;
-}
-
-static PyObject*
-pyepoll_fileno(pyEpoll_Object *self)
-{
-    if (self->epfd < 0)
-        return pyepoll_err_closed();
-    return PyLong_FromLong(self->epfd);
-}
-
-PyDoc_STRVAR(pyepoll_fileno_doc,
-"fileno() -> int\n\
-\n\
-Return the epoll control file descriptor.");
-
-static PyObject*
-pyepoll_fromfd(PyObject *cls, PyObject *args)
-{
-    SOCKET fd;
-
-    if (!PyArg_ParseTuple(args, "i:fromfd", &fd))
-        return NULL;
-
-    return newPyEpoll_Object((PyTypeObject*)cls, FD_SETSIZE - 1, 0, fd);
-}
-
-PyDoc_STRVAR(pyepoll_fromfd_doc,
-"fromfd(fd) -> epoll\n\
-\n\
-Create an epoll object from a given control fd.");
-
-static PyObject *
-pyepoll_internal_ctl(int epfd, int op, PyObject *pfd, unsigned int events)
-{
-    struct epoll_event ev;
-    int result;
-    int fd;
-
-    if (epfd < 0)
-        return pyepoll_err_closed();
-
-    fd = PyObject_AsFileDescriptor(pfd);
-    if (fd == -1) {
-        return NULL;
-    }
-
-    switch(op) {
-        case EPOLL_CTL_ADD:
-        case EPOLL_CTL_MOD:
-        ev.events = events;
-        ev.data.fd = fd;
-        Py_BEGIN_ALLOW_THREADS
-        result = epoll_ctl(epfd, op, fd, &ev);
-        Py_END_ALLOW_THREADS
-        break;
-        case EPOLL_CTL_DEL:
-        /* In kernel versions before 2.6.9, the EPOLL_CTL_DEL
-         * operation required a non-NULL pointer in event, even
-         * though this argument is ignored. */
-        Py_BEGIN_ALLOW_THREADS
-        result = epoll_ctl(epfd, op, fd, &ev);
-        if (errno == EBADF) {
-            /* fd already closed */
-            result = 0;
-            errno = 0;
-        }
-        Py_END_ALLOW_THREADS
-        break;
-        default:
-        result = -1;
-        errno = EINVAL;
-    }
-
-    if (result < 0) {
-        PyErr_SetFromErrno(PyExc_OSError);
-        return NULL;
-    }
-    Py_RETURN_NONE;
-}
-
-static PyObject *
-pyepoll_register(pyEpoll_Object *self, PyObject *args, PyObject *kwds)
-{
-    PyObject *pfd;
-    unsigned int events = EPOLLIN | EPOLLOUT | EPOLLPRI;
-    static char *kwlist[] = {"fd", "eventmask", NULL};
-
-    if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|I:register", kwlist,
-                                     &pfd, &events)) {
-        return NULL;
-    }
-
-    return pyepoll_internal_ctl(self->epfd, EPOLL_CTL_ADD, pfd, events);
-}
-
-PyDoc_STRVAR(pyepoll_register_doc,
-"register(fd[, eventmask]) -> None\n\
-\n\
-Registers a new fd or raises an OSError if the fd is already registered.\n\
-fd is the target file descriptor of the operation.\n\
-events is a bit set composed of the various EPOLL constants; the default\n\
-is EPOLL_IN | EPOLL_OUT | EPOLL_PRI.\n\
-\n\
-The epoll interface supports all file descriptors that support poll.");
-
-static PyObject *
-pyepoll_modify(pyEpoll_Object *self, PyObject *args, PyObject *kwds)
-{
-    PyObject *pfd;
-    unsigned int events;
-    static char *kwlist[] = {"fd", "eventmask", NULL};
-
-    if (!PyArg_ParseTupleAndKeywords(args, kwds, "OI:modify", kwlist,
-                                     &pfd, &events)) {
-        return NULL;
-    }
-
-    return pyepoll_internal_ctl(self->epfd, EPOLL_CTL_MOD, pfd, events);
-}
-
-PyDoc_STRVAR(pyepoll_modify_doc,
-"modify(fd, eventmask) -> None\n\
-\n\
-fd is the target file descriptor of the operation\n\
-events is a bit set composed of the various EPOLL constants");
-
-static PyObject *
-pyepoll_unregister(pyEpoll_Object *self, PyObject *args, PyObject *kwds)
-{
-    PyObject *pfd;
-    static char *kwlist[] = {"fd", NULL};
-
-    if (!PyArg_ParseTupleAndKeywords(args, kwds, "O:unregister", kwlist,
-                                     &pfd)) {
-        return NULL;
-    }
-
-    return pyepoll_internal_ctl(self->epfd, EPOLL_CTL_DEL, pfd, 0);
-}
-
-PyDoc_STRVAR(pyepoll_unregister_doc,
-"unregister(fd) -> None\n\
-\n\
-fd is the target file descriptor of the operation.");
-
-static PyObject *
-pyepoll_poll(pyEpoll_Object *self, PyObject *args, PyObject *kwds)
-{
-    double dtimeout = -1.;
-    int timeout;
-    int maxevents = -1;
-    int nfds, i;
-    PyObject *elist = NULL, *etuple = NULL;
-    struct epoll_event *evs = NULL;
-    static char *kwlist[] = {"timeout", "maxevents", NULL};
-
-    if (self->epfd < 0)
-        return pyepoll_err_closed();
-
-    if (!PyArg_ParseTupleAndKeywords(args, kwds, "|di:poll", kwlist,
-                                     &dtimeout, &maxevents)) {
-        return NULL;
-    }
-
-    if (dtimeout < 0) {
-        timeout = -1;
-    }
-    else if (dtimeout * 1000.0 > INT_MAX) {
-        PyErr_SetString(PyExc_OverflowError,
-                        "timeout is too large");
-        return NULL;
-    }
-    else {
-        timeout = (int)(dtimeout * 1000.0);
-    }
-
-    if (maxevents == -1) {
-        maxevents = FD_SETSIZE-1;
-    }
-    else if (maxevents < 1) {
-        PyErr_Format(PyExc_ValueError,
-                     "maxevents must be greater than 0, got %d",
-                     maxevents);
-        return NULL;
-    }
-
-    evs = PyMem_New(struct epoll_event, maxevents);
-    if (evs == NULL) {
-        Py_DECREF(self);
-        PyErr_NoMemory();
-        return NULL;
-    }
-
-    Py_BEGIN_ALLOW_THREADS
-    nfds = epoll_wait(self->epfd, evs, maxevents, timeout);
-    Py_END_ALLOW_THREADS
-    if (nfds < 0) {
-        PyErr_SetFromErrno(PyExc_OSError);
-        goto error;
-    }
-
-    elist = PyList_New(nfds);
-    if (elist == NULL) {
-        goto error;
-    }
-
-    for (i = 0; i < nfds; i++) {
-        etuple = Py_BuildValue("iI", evs[i].data.fd, evs[i].events);
-        if (etuple == NULL) {
-            Py_CLEAR(elist);
-            goto error;
-        }
-        PyList_SET_ITEM(elist, i, etuple);
-    }
-
-    error:
-    PyMem_Free(evs);
-    return elist;
-}
-
-PyDoc_STRVAR(pyepoll_poll_doc,
-"poll([timeout=-1[, maxevents=-1]]) -> [(fd, events), (...)]\n\
-\n\
-Wait for events on the epoll file descriptor for a maximum time of timeout\n\
-in seconds (as float). -1 makes poll wait indefinitely.\n\
-Up to maxevents are returned to the caller.");
-
-static PyObject *
-pyepoll_enter(pyEpoll_Object *self, PyObject *args)
-{
-    if (self->epfd < 0)
-        return pyepoll_err_closed();
-
-    Py_INCREF(self);
-    return (PyObject *)self;
-}
-
-static PyObject *
-pyepoll_exit(PyObject *self, PyObject *args)
-{
-    _Py_IDENTIFIER(close);
-
-    return _PyObject_CallMethodId(self, &PyId_close, NULL);
-}
-
-static PyMethodDef pyepoll_methods[] = {
-    {"fromfd",          (PyCFunction)pyepoll_fromfd,
-     METH_VARARGS | METH_CLASS, pyepoll_fromfd_doc},
-    {"close",           (PyCFunction)pyepoll_close,     METH_NOARGS,
-     pyepoll_close_doc},
-    {"fileno",          (PyCFunction)pyepoll_fileno,    METH_NOARGS,
-     pyepoll_fileno_doc},
-    {"modify",          (PyCFunction)pyepoll_modify,
-     METH_VARARGS | METH_KEYWORDS,      pyepoll_modify_doc},
-    {"register",        (PyCFunction)pyepoll_register,
-     METH_VARARGS | METH_KEYWORDS,      pyepoll_register_doc},
-    {"unregister",      (PyCFunction)pyepoll_unregister,
-     METH_VARARGS | METH_KEYWORDS,      pyepoll_unregister_doc},
-    {"poll",            (PyCFunction)pyepoll_poll,
-     METH_VARARGS | METH_KEYWORDS,      pyepoll_poll_doc},
-    {"__enter__",           (PyCFunction)pyepoll_enter,     METH_NOARGS,
-     NULL},
-    {"__exit__",           (PyCFunction)pyepoll_exit,     METH_VARARGS,
-     NULL},
-    {NULL,      NULL},
-};
-
-static PyGetSetDef pyepoll_getsetlist[] = {
-    {"closed", (getter)pyepoll_get_closed, NULL,
-     "True if the epoll handler is closed"},
-    {0},
-};
-
-PyDoc_STRVAR(pyepoll_doc,
-"select.epoll(sizehint=-1, flags=0)\n\
-\n\
-Returns an epolling object\n\
-\n\
-sizehint must be a positive integer or -1 for the default size. The\n\
-sizehint is used to optimize internal data structures. It doesn't limit\n\
-the maximum number of monitored events.");
-
-static PyTypeObject pyEpoll_Type = {
-    PyVarObject_HEAD_INIT(NULL, 0)
-    "select.epoll",                                     /* tp_name */
-    sizeof(pyEpoll_Object),                             /* tp_basicsize */
-    0,                                                  /* tp_itemsize */
-    (destructor)pyepoll_dealloc,                        /* tp_dealloc */
-    0,                                                  /* tp_print */
-    0,                                                  /* tp_getattr */
-    0,                                                  /* tp_setattr */
-    0,                                                  /* tp_reserved */
-    0,                                                  /* tp_repr */
-    0,                                                  /* tp_as_number */
-    0,                                                  /* tp_as_sequence */
-    0,                                                  /* tp_as_mapping */
-    0,                                                  /* tp_hash */
-    0,                                                  /* tp_call */
-    0,                                                  /* tp_str */
-    PyObject_GenericGetAttr,                            /* tp_getattro */
-    0,                                                  /* tp_setattro */
-    0,                                                  /* tp_as_buffer */
-    Py_TPFLAGS_DEFAULT,                                 /* tp_flags */
-    pyepoll_doc,                                        /* tp_doc */
-    0,                                                  /* tp_traverse */
-    0,                                                  /* tp_clear */
-    0,                                                  /* tp_richcompare */
-    0,                                                  /* tp_weaklistoffset */
-    0,                                                  /* tp_iter */
-    0,                                                  /* tp_iternext */
-    pyepoll_methods,                                    /* tp_methods */
-    0,                                                  /* tp_members */
-    pyepoll_getsetlist,                                 /* tp_getset */
-    0,                                                  /* tp_base */
-    0,                                                  /* tp_dict */
-    0,                                                  /* tp_descr_get */
-    0,                                                  /* tp_descr_set */
-    0,                                                  /* tp_dictoffset */
-    0,                                                  /* tp_init */
-    0,                                                  /* tp_alloc */
-    pyepoll_new,                                        /* tp_new */
-    0,                                                  /* tp_free */
-};
-
-#endif /* HAVE_EPOLL */
-
-#ifdef HAVE_KQUEUE
-/* **************************************************************************
- *                      kqueue interface for BSD
- *
- * Copyright (c) 2000 Doug White, 2006 James Knight, 2007 Christian Heimes
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#ifdef HAVE_SYS_EVENT_H
-#include <sys/event.h>
-#endif
-
-PyDoc_STRVAR(kqueue_event_doc,
-"kevent(ident, filter=KQ_FILTER_READ, flags=KQ_EV_ADD, fflags=0, data=0, udata=0)\n\
-\n\
-This object is the equivalent of the struct kevent for the C API.\n\
-\n\
-See the kqueue manpage for more detailed information about the meaning\n\
-of the arguments.\n\
-\n\
-One minor note: while you might hope that udata could store a\n\
-reference to a python object, it cannot, because it is impossible to\n\
-keep a proper reference count of the object once it's passed into the\n\
-kernel. Therefore, I have restricted it to only storing an integer.  I\n\
-recommend ignoring it and simply using the 'ident' field to key off\n\
-of. You could also set up a dictionary on the python side to store a\n\
-udata->object mapping.");
-
-typedef struct {
-    PyObject_HEAD
-    struct kevent e;
-} kqueue_event_Object;
-
-static PyTypeObject kqueue_event_Type;
-
-#define kqueue_event_Check(op) (PyObject_TypeCheck((op), &kqueue_event_Type))
-
-typedef struct {
-    PyObject_HEAD
-    SOCKET kqfd;                /* kqueue control fd */
-} kqueue_queue_Object;
-
-static PyTypeObject kqueue_queue_Type;
-
-#define kqueue_queue_Check(op) (PyObject_TypeCheck((op), &kqueue_queue_Type))
-
-#if (SIZEOF_UINTPTR_T != SIZEOF_VOID_P)
-#   error uintptr_t does not match void *!
-#elif (SIZEOF_UINTPTR_T == SIZEOF_LONG_LONG)
-#   define T_UINTPTRT         T_ULONGLONG
-#   define T_INTPTRT          T_LONGLONG
-#   define PyLong_AsUintptr_t PyLong_AsUnsignedLongLong
-#   define UINTPTRT_FMT_UNIT  "K"
-#   define INTPTRT_FMT_UNIT   "L"
-#elif (SIZEOF_UINTPTR_T == SIZEOF_LONG)
-#   define T_UINTPTRT         T_ULONG
-#   define T_INTPTRT          T_LONG
-#   define PyLong_AsUintptr_t PyLong_AsUnsignedLong
-#   define UINTPTRT_FMT_UNIT  "k"
-#   define INTPTRT_FMT_UNIT   "l"
-#elif (SIZEOF_UINTPTR_T == SIZEOF_INT)
-#   define T_UINTPTRT         T_UINT
-#   define T_INTPTRT          T_INT
-#   define PyLong_AsUintptr_t PyLong_AsUnsignedLong
-#   define UINTPTRT_FMT_UNIT  "I"
-#   define INTPTRT_FMT_UNIT   "i"
-#else
-#   error uintptr_t does not match int, long, or long long!
-#endif
-
-/*
- * kevent is not standard and its members vary across BSDs.
- */
-#if !defined(__OpenBSD__)
-#   define IDENT_TYPE	T_UINTPTRT
-#   define IDENT_CAST	Py_intptr_t
-#   define DATA_TYPE	T_INTPTRT
-#   define DATA_FMT_UNIT INTPTRT_FMT_UNIT
-#   define IDENT_AsType	PyLong_AsUintptr_t
-#else
-#   define IDENT_TYPE	T_UINT
-#   define IDENT_CAST	int
-#   define DATA_TYPE	T_INT
-#   define DATA_FMT_UNIT "i"
-#   define IDENT_AsType	PyLong_AsUnsignedLong
-#endif
-
-/* Unfortunately, we can't store python objects in udata, because
- * kevents in the kernel can be removed without warning, which would
- * forever lose the refcount on the object stored with it.
- */
-
-#define KQ_OFF(x) offsetof(kqueue_event_Object, x)
-static struct PyMemberDef kqueue_event_members[] = {
-    {"ident",           IDENT_TYPE,     KQ_OFF(e.ident)},
-    {"filter",          T_SHORT,        KQ_OFF(e.filter)},
-    {"flags",           T_USHORT,       KQ_OFF(e.flags)},
-    {"fflags",          T_UINT,         KQ_OFF(e.fflags)},
-    {"data",            DATA_TYPE,      KQ_OFF(e.data)},
-    {"udata",           T_UINTPTRT,     KQ_OFF(e.udata)},
-    {NULL} /* Sentinel */
-};
-#undef KQ_OFF
-
-static PyObject *
-
-kqueue_event_repr(kqueue_event_Object *s)
-{
-    char buf[1024];
-    PyOS_snprintf(
-        buf, sizeof(buf),
-        "<select.kevent ident=%zu filter=%d flags=0x%x fflags=0x%x "
-        "data=0x%zd udata=%p>",
-        (size_t)(s->e.ident), s->e.filter, s->e.flags,
-        s->e.fflags, (Py_ssize_t)(s->e.data), s->e.udata);
-    return PyUnicode_FromString(buf);
-}
-
-static int
-kqueue_event_init(kqueue_event_Object *self, PyObject *args, PyObject *kwds)
-{
-    PyObject *pfd;
-    static char *kwlist[] = {"ident", "filter", "flags", "fflags",
-                             "data", "udata", NULL};
-    static char *fmt = "O|hhi" DATA_FMT_UNIT UINTPTRT_FMT_UNIT ":kevent";
-
-    EV_SET(&(self->e), 0, EVFILT_READ, EV_ADD, 0, 0, 0); /* defaults */
-
-    if (!PyArg_ParseTupleAndKeywords(args, kwds, fmt, kwlist,
-        &pfd, &(self->e.filter), &(self->e.flags),
-        &(self->e.fflags), &(self->e.data), &(self->e.udata))) {
-        return -1;
-    }
-
-    if (PyLong_Check(pfd)
-#if IDENT_TYPE == T_UINT
-	&& PyLong_AsUnsignedLong(pfd) <= UINT_MAX
-#endif
-    ) {
-        self->e.ident = IDENT_AsType(pfd);
-    }
-    else {
-        self->e.ident = PyObject_AsFileDescriptor(pfd);
-    }
-    if (PyErr_Occurred()) {
-        return -1;
-    }
-    return 0;
-}
-
-static PyObject *
-kqueue_event_richcompare(kqueue_event_Object *s, kqueue_event_Object *o,
-                         int op)
-{
-    Py_intptr_t result = 0;
-
-    if (!kqueue_event_Check(o)) {
-        if (op == Py_EQ || op == Py_NE) {
-            PyObject *res = op == Py_EQ ? Py_False : Py_True;
-            Py_INCREF(res);
-            return res;
-        }
-        PyErr_Format(PyExc_TypeError,
-            "can't compare %.200s to %.200s",
-            Py_TYPE(s)->tp_name, Py_TYPE(o)->tp_name);
-        return NULL;
-    }
-    if (((result = (IDENT_CAST)(s->e.ident - o->e.ident)) == 0) &&
-        ((result = s->e.filter - o->e.filter) == 0) &&
-        ((result = s->e.flags - o->e.flags) == 0) &&
-        ((result = (int)(s->e.fflags - o->e.fflags)) == 0) &&
-        ((result = s->e.data - o->e.data) == 0) &&
-        ((result = s->e.udata - o->e.udata) == 0)
-       ) {
-        result = 0;
-    }
-
-    switch (op) {
-        case Py_EQ:
-        result = (result == 0);
-        break;
-        case Py_NE:
-        result = (result != 0);
-        break;
-        case Py_LE:
-        result = (result <= 0);
-        break;
-        case Py_GE:
-        result = (result >= 0);
-        break;
-        case Py_LT:
-        result = (result < 0);
-        break;
-        case Py_GT:
-        result = (result > 0);
-        break;
-    }
-    return PyBool_FromLong((long)result);
-}
-
-static PyTypeObject kqueue_event_Type = {
-    PyVarObject_HEAD_INIT(NULL, 0)
-    "select.kevent",                                    /* tp_name */
-    sizeof(kqueue_event_Object),                        /* tp_basicsize */
-    0,                                                  /* tp_itemsize */
-    0,                                                  /* tp_dealloc */
-    0,                                                  /* tp_print */
-    0,                                                  /* tp_getattr */
-    0,                                                  /* tp_setattr */
-    0,                                                  /* tp_reserved */
-    (reprfunc)kqueue_event_repr,                        /* tp_repr */
-    0,                                                  /* tp_as_number */
-    0,                                                  /* tp_as_sequence */
-    0,                                                  /* tp_as_mapping */
-    0,                                                  /* tp_hash */
-    0,                                                  /* tp_call */
-    0,                                                  /* tp_str */
-    0,                                                  /* tp_getattro */
-    0,                                                  /* tp_setattro */
-    0,                                                  /* tp_as_buffer */
-    Py_TPFLAGS_DEFAULT,                                 /* tp_flags */
-    kqueue_event_doc,                                   /* tp_doc */
-    0,                                                  /* tp_traverse */
-    0,                                                  /* tp_clear */
-    (richcmpfunc)kqueue_event_richcompare,              /* tp_richcompare */
-    0,                                                  /* tp_weaklistoffset */
-    0,                                                  /* tp_iter */
-    0,                                                  /* tp_iternext */
-    0,                                                  /* tp_methods */
-    kqueue_event_members,                               /* tp_members */
-    0,                                                  /* tp_getset */
-    0,                                                  /* tp_base */
-    0,                                                  /* tp_dict */
-    0,                                                  /* tp_descr_get */
-    0,                                                  /* tp_descr_set */
-    0,                                                  /* tp_dictoffset */
-    (initproc)kqueue_event_init,                        /* tp_init */
-    0,                                                  /* tp_alloc */
-    0,                                                  /* tp_new */
-    0,                                                  /* tp_free */
-};
-
-static PyObject *
-kqueue_queue_err_closed(void)
-{
-    PyErr_SetString(PyExc_ValueError, "I/O operation on closed kqueue fd");
-    return NULL;
-}
-
-static int
-kqueue_queue_internal_close(kqueue_queue_Object *self)
-{
-    int save_errno = 0;
-    if (self->kqfd >= 0) {
-        int kqfd = self->kqfd;
-        self->kqfd = -1;
-        Py_BEGIN_ALLOW_THREADS
-        if (close(kqfd) < 0)
-            save_errno = errno;
-        Py_END_ALLOW_THREADS
-    }
-    return save_errno;
-}
-
-static PyObject *
-newKqueue_Object(PyTypeObject *type, SOCKET fd)
-{
-    kqueue_queue_Object *self;
-    assert(type != NULL && type->tp_alloc != NULL);
-    self = (kqueue_queue_Object *) type->tp_alloc(type, 0);
-    if (self == NULL) {
-        return NULL;
-    }
-
-    if (fd == -1) {
-        Py_BEGIN_ALLOW_THREADS
-        self->kqfd = kqueue();
-        Py_END_ALLOW_THREADS
-    }
-    else {
-        self->kqfd = fd;
-    }
-    if (self->kqfd < 0) {
-        Py_DECREF(self);
-        PyErr_SetFromErrno(PyExc_OSError);
-        return NULL;
-    }
-    return (PyObject *)self;
-}
-
-static PyObject *
-kqueue_queue_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
-{
-
-    if ((args != NULL && PyObject_Size(args)) ||
-                    (kwds != NULL && PyObject_Size(kwds))) {
-        PyErr_SetString(PyExc_ValueError,
-                        "select.kqueue doesn't accept arguments");
-        return NULL;
-    }
-
-    return newKqueue_Object(type, -1);
-}
-
-static void
-kqueue_queue_dealloc(kqueue_queue_Object *self)
-{
-    kqueue_queue_internal_close(self);
-    Py_TYPE(self)->tp_free(self);
-}
-
-static PyObject*
-kqueue_queue_close(kqueue_queue_Object *self)
-{
-    errno = kqueue_queue_internal_close(self);
-    if (errno < 0) {
-        PyErr_SetFromErrno(PyExc_OSError);
-        return NULL;
-    }
-    Py_RETURN_NONE;
-}
-
-PyDoc_STRVAR(kqueue_queue_close_doc,
-"close() -> None\n\
-\n\
-Close the kqueue control file descriptor. Further operations on the kqueue\n\
-object will raise an exception.");
-
-static PyObject*
-kqueue_queue_get_closed(kqueue_queue_Object *self)
-{
-    if (self->kqfd < 0)
-        Py_RETURN_TRUE;
-    else
-        Py_RETURN_FALSE;
-}
-
-static PyObject*
-kqueue_queue_fileno(kqueue_queue_Object *self)
-{
-    if (self->kqfd < 0)
-        return kqueue_queue_err_closed();
-    return PyLong_FromLong(self->kqfd);
-}
-
-PyDoc_STRVAR(kqueue_queue_fileno_doc,
-"fileno() -> int\n\
-\n\
-Return the kqueue control file descriptor.");
-
-static PyObject*
-kqueue_queue_fromfd(PyObject *cls, PyObject *args)
-{
-    SOCKET fd;
-
-    if (!PyArg_ParseTuple(args, "i:fromfd", &fd))
-        return NULL;
-
-    return newKqueue_Object((PyTypeObject*)cls, fd);
-}
-
-PyDoc_STRVAR(kqueue_queue_fromfd_doc,
-"fromfd(fd) -> kqueue\n\
-\n\
-Create a kqueue object from a given control fd.");
-
-static PyObject *
-kqueue_queue_control(kqueue_queue_Object *self, PyObject *args)
-{
-    int nevents = 0;
-    int gotevents = 0;
-    int nchanges = 0;
-    int i = 0;
-    PyObject *otimeout = NULL;
-    PyObject *ch = NULL;
-    PyObject *it = NULL, *ei = NULL;
-    PyObject *result = NULL;
-    struct kevent *evl = NULL;
-    struct kevent *chl = NULL;
-    struct timespec timeout;
-    struct timespec *ptimeoutspec;
-
-    if (self->kqfd < 0)
-        return kqueue_queue_err_closed();
-
-    if (!PyArg_ParseTuple(args, "Oi|O:control", &ch, &nevents, &otimeout))
-        return NULL;
-
-    if (nevents < 0) {
-        PyErr_Format(PyExc_ValueError,
-            "Length of eventlist must be 0 or positive, got %d",
-            nevents);
-        return NULL;
-    }
-
-    if (otimeout == Py_None || otimeout == NULL) {
-        ptimeoutspec = NULL;
-    }
-    else if (PyNumber_Check(otimeout)) {
-        if (_PyTime_ObjectToTimespec(otimeout,
-                                     &timeout.tv_sec, &timeout.tv_nsec) == -1)
-            return NULL;
-
-        if (timeout.tv_sec < 0) {
-            PyErr_SetString(PyExc_ValueError,
-                            "timeout must be positive or None");
-            return NULL;
-        }
-        ptimeoutspec = &timeout;
-    }
-    else {
-        PyErr_Format(PyExc_TypeError,
-            "timeout argument must be an number "
-            "or None, got %.200s",
-            Py_TYPE(otimeout)->tp_name);
-        return NULL;
-    }
-
-    if (ch != NULL && ch != Py_None) {
-        it = PyObject_GetIter(ch);
-        if (it == NULL) {
-            PyErr_SetString(PyExc_TypeError,
-                            "changelist is not iterable");
-            return NULL;
-        }
-        nchanges = PyObject_Size(ch);
-        if (nchanges < 0) {
-            goto error;
-        }
-
-        chl = PyMem_New(struct kevent, nchanges);
-        if (chl == NULL) {
-            PyErr_NoMemory();
-            goto error;
-        }
-        i = 0;
-        while ((ei = PyIter_Next(it)) != NULL) {
-            if (!kqueue_event_Check(ei)) {
-                Py_DECREF(ei);
-                PyErr_SetString(PyExc_TypeError,
-                    "changelist must be an iterable of "
-                    "select.kevent objects");
-                goto error;
-            } else {
-                chl[i++] = ((kqueue_event_Object *)ei)->e;
-            }
-            Py_DECREF(ei);
-        }
-    }
-    Py_CLEAR(it);
-
-    /* event list */
-    if (nevents) {
-        evl = PyMem_New(struct kevent, nevents);
-        if (evl == NULL) {
-            PyErr_NoMemory();
-            goto error;
-        }
-    }
-
-    Py_BEGIN_ALLOW_THREADS
-    gotevents = kevent(self->kqfd, chl, nchanges,
-                       evl, nevents, ptimeoutspec);
-    Py_END_ALLOW_THREADS
-
-    if (gotevents == -1) {
-        PyErr_SetFromErrno(PyExc_OSError);
-        goto error;
-    }
-
-    result = PyList_New(gotevents);
-    if (result == NULL) {
-        goto error;
-    }
-
-    for (i = 0; i < gotevents; i++) {
-        kqueue_event_Object *ch;
-
-        ch = PyObject_New(kqueue_event_Object, &kqueue_event_Type);
-        if (ch == NULL) {
-            goto error;
-        }
-        ch->e = evl[i];
-        PyList_SET_ITEM(result, i, (PyObject *)ch);
-    }
-    PyMem_Free(chl);
-    PyMem_Free(evl);
-    return result;
-
-    error:
-    PyMem_Free(chl);
-    PyMem_Free(evl);
-    Py_XDECREF(result);
-    Py_XDECREF(it);
-    return NULL;
-}
-
-PyDoc_STRVAR(kqueue_queue_control_doc,
-"control(changelist, max_events[, timeout=None]) -> eventlist\n\
-\n\
-Calls the kernel kevent function.\n\
-- changelist must be a list of kevent objects describing the changes\n\
-  to be made to the kernel's watch list or None.\n\
-- max_events lets you specify the maximum number of events that the\n\
-  kernel will return.\n\
-- timeout is the maximum time to wait in seconds, or else None,\n\
-  to wait forever. timeout accepts floats for smaller timeouts, too.");
-
-
-static PyMethodDef kqueue_queue_methods[] = {
-    {"fromfd",          (PyCFunction)kqueue_queue_fromfd,
-     METH_VARARGS | METH_CLASS, kqueue_queue_fromfd_doc},
-    {"close",           (PyCFunction)kqueue_queue_close,        METH_NOARGS,
-     kqueue_queue_close_doc},
-    {"fileno",          (PyCFunction)kqueue_queue_fileno,       METH_NOARGS,
-     kqueue_queue_fileno_doc},
-    {"control",         (PyCFunction)kqueue_queue_control,
-     METH_VARARGS ,     kqueue_queue_control_doc},
-    {NULL,      NULL},
-};
-
-static PyGetSetDef kqueue_queue_getsetlist[] = {
-    {"closed", (getter)kqueue_queue_get_closed, NULL,
-     "True if the kqueue handler is closed"},
-    {0},
-};
-
-PyDoc_STRVAR(kqueue_queue_doc,
-"Kqueue syscall wrapper.\n\
-\n\
-For example, to start watching a socket for input:\n\
->>> kq = kqueue()\n\
->>> sock = socket()\n\
->>> sock.connect((host, port))\n\
->>> kq.control([kevent(sock, KQ_FILTER_WRITE, KQ_EV_ADD)], 0)\n\
-\n\
-To wait one second for it to become writeable:\n\
->>> kq.control(None, 1, 1000)\n\
-\n\
-To stop listening:\n\
->>> kq.control([kevent(sock, KQ_FILTER_WRITE, KQ_EV_DELETE)], 0)");
-
-static PyTypeObject kqueue_queue_Type = {
-    PyVarObject_HEAD_INIT(NULL, 0)
-    "select.kqueue",                                    /* tp_name */
-    sizeof(kqueue_queue_Object),                        /* tp_basicsize */
-    0,                                                  /* tp_itemsize */
-    (destructor)kqueue_queue_dealloc,                   /* tp_dealloc */
-    0,                                                  /* tp_print */
-    0,                                                  /* tp_getattr */
-    0,                                                  /* tp_setattr */
-    0,                                                  /* tp_reserved */
-    0,                                                  /* tp_repr */
-    0,                                                  /* tp_as_number */
-    0,                                                  /* tp_as_sequence */
-    0,                                                  /* tp_as_mapping */
-    0,                                                  /* tp_hash */
-    0,                                                  /* tp_call */
-    0,                                                  /* tp_str */
-    0,                                                  /* tp_getattro */
-    0,                                                  /* tp_setattro */
-    0,                                                  /* tp_as_buffer */
-    Py_TPFLAGS_DEFAULT,                                 /* tp_flags */
-    kqueue_queue_doc,                                   /* tp_doc */
-    0,                                                  /* tp_traverse */
-    0,                                                  /* tp_clear */
-    0,                                                  /* tp_richcompare */
-    0,                                                  /* tp_weaklistoffset */
-    0,                                                  /* tp_iter */
-    0,                                                  /* tp_iternext */
-    kqueue_queue_methods,                               /* tp_methods */
-    0,                                                  /* tp_members */
-    kqueue_queue_getsetlist,                            /* tp_getset */
-    0,                                                  /* tp_base */
-    0,                                                  /* tp_dict */
-    0,                                                  /* tp_descr_get */
-    0,                                                  /* tp_descr_set */
-    0,                                                  /* tp_dictoffset */
-    0,                                                  /* tp_init */
-    0,                                                  /* tp_alloc */
-    kqueue_queue_new,                                   /* tp_new */
-    0,                                                  /* tp_free */
-};
-
-#endif /* HAVE_KQUEUE */
-
-
-
-
-
-/* ************************************************************************ */
-
-PyDoc_STRVAR(select_doc,
-"select(rlist, wlist, xlist[, timeout]) -> (rlist, wlist, xlist)\n\
-\n\
-Wait until one or more file descriptors are ready for some kind of I/O.\n\
-The first three arguments are sequences of file descriptors to be waited for:\n\
-rlist -- wait until ready for reading\n\
-wlist -- wait until ready for writing\n\
-xlist -- wait for an ``exceptional condition''\n\
-If only one kind of condition is required, pass [] for the other lists.\n\
-A file descriptor is either a socket or file object, or a small integer\n\
-gotten from a fileno() method call on one of those.\n\
-\n\
-The optional 4th argument specifies a timeout in seconds; it may be\n\
-a floating point number to specify fractions of seconds.  If it is absent\n\
-or None, the call will never time out.\n\
-\n\
-The return value is a tuple of three lists corresponding to the first three\n\
-arguments; each contains the subset of the corresponding file descriptors\n\
-that are ready.\n\
-\n\
-*** IMPORTANT NOTICE ***\n\
-On Windows and OpenVMS, only sockets are supported; on Unix, all file\n\
-descriptors can be used.");
-
-static PyMethodDef select_methods[] = {
-    {"select",          select_select,  METH_VARARGS,   select_doc},
-#if defined(HAVE_POLL) && !defined(HAVE_BROKEN_POLL)
-    {"poll",            select_poll,    METH_NOARGS,    poll_doc},
-#endif /* HAVE_POLL */
-#ifdef HAVE_SYS_DEVPOLL_H
-    {"devpoll",         select_devpoll, METH_NOARGS,    devpoll_doc},
-#endif
-    {0,         0},     /* sentinel */
-};
-
-PyDoc_STRVAR(module_doc,
-"This module supports asynchronous I/O on multiple file descriptors.\n\
-\n\
-*** IMPORTANT NOTICE ***\n\
-On Windows and OpenVMS, only sockets are supported; on Unix, all file descriptors.");
-
-
-static struct PyModuleDef selectmodule = {
-    PyModuleDef_HEAD_INIT,
-    "select",
-    module_doc,
-    -1,
-    select_methods,
-    NULL,
-    NULL,
-    NULL,
-    NULL
-};
-
-
-
-
-PyMODINIT_FUNC
-PyInit_select(void)
-{
-    PyObject *m;
-    m = PyModule_Create(&selectmodule);
-    if (m == NULL)
-        return NULL;
-
-    Py_INCREF(PyExc_OSError);
-    PyModule_AddObject(m, "error", PyExc_OSError);
-
-#ifdef PIPE_BUF
-#ifdef HAVE_BROKEN_PIPE_BUF
-#undef PIPE_BUF
-#define PIPE_BUF 512
-#endif
-    PyModule_AddIntMacro(m, PIPE_BUF);
-#endif
-
-#if defined(HAVE_POLL) && !defined(HAVE_BROKEN_POLL)
-#ifdef __APPLE__
-    if (select_have_broken_poll()) {
-        if (PyObject_DelAttrString(m, "poll") == -1) {
-            PyErr_Clear();
-        }
-    } else {
-#else
-    {
-#endif
-        if (PyType_Ready(&poll_Type) < 0)
-            return NULL;
-        PyModule_AddIntMacro(m, POLLIN);
-        PyModule_AddIntMacro(m, POLLPRI);
-        PyModule_AddIntMacro(m, POLLOUT);
-        PyModule_AddIntMacro(m, POLLERR);
-        PyModule_AddIntMacro(m, POLLHUP);
-        PyModule_AddIntMacro(m, POLLNVAL);
-
-#ifdef POLLRDNORM
-        PyModule_AddIntMacro(m, POLLRDNORM);
-#endif
-#ifdef POLLRDBAND
-        PyModule_AddIntMacro(m, POLLRDBAND);
-#endif
-#ifdef POLLWRNORM
-        PyModule_AddIntMacro(m, POLLWRNORM);
-#endif
-#ifdef POLLWRBAND
-        PyModule_AddIntMacro(m, POLLWRBAND);
-#endif
-#ifdef POLLMSG
-        PyModule_AddIntMacro(m, POLLMSG);
-#endif
-    }
-#endif /* HAVE_POLL */
-
-#ifdef HAVE_SYS_DEVPOLL_H
-    if (PyType_Ready(&devpoll_Type) < 0)
-        return NULL;
-#endif
-
-#ifdef HAVE_EPOLL
-    Py_TYPE(&pyEpoll_Type) = &PyType_Type;
-    if (PyType_Ready(&pyEpoll_Type) < 0)
-        return NULL;
-
-    Py_INCREF(&pyEpoll_Type);
-    PyModule_AddObject(m, "epoll", (PyObject *) &pyEpoll_Type);
-
-    PyModule_AddIntMacro(m, EPOLLIN);
-    PyModule_AddIntMacro(m, EPOLLOUT);
-    PyModule_AddIntMacro(m, EPOLLPRI);
-    PyModule_AddIntMacro(m, EPOLLERR);
-    PyModule_AddIntMacro(m, EPOLLHUP);
-    PyModule_AddIntMacro(m, EPOLLET);
-#ifdef EPOLLONESHOT
-    /* Kernel 2.6.2+ */
-    PyModule_AddIntMacro(m, EPOLLONESHOT);
-#endif
-    /* PyModule_AddIntConstant(m, "EPOLL_RDHUP", EPOLLRDHUP); */
-    PyModule_AddIntMacro(m, EPOLLRDNORM);
-    PyModule_AddIntMacro(m, EPOLLRDBAND);
-    PyModule_AddIntMacro(m, EPOLLWRNORM);
-    PyModule_AddIntMacro(m, EPOLLWRBAND);
-    PyModule_AddIntMacro(m, EPOLLMSG);
-
-#ifdef EPOLL_CLOEXEC
-    PyModule_AddIntMacro(m, EPOLL_CLOEXEC);
-#endif
-#endif /* HAVE_EPOLL */
-
-#ifdef HAVE_KQUEUE
-    kqueue_event_Type.tp_new = PyType_GenericNew;
-    Py_TYPE(&kqueue_event_Type) = &PyType_Type;
-    if(PyType_Ready(&kqueue_event_Type) < 0)
-        return NULL;
-
-    Py_INCREF(&kqueue_event_Type);
-    PyModule_AddObject(m, "kevent", (PyObject *)&kqueue_event_Type);
-
-    Py_TYPE(&kqueue_queue_Type) = &PyType_Type;
-    if(PyType_Ready(&kqueue_queue_Type) < 0)
-        return NULL;
-    Py_INCREF(&kqueue_queue_Type);
-    PyModule_AddObject(m, "kqueue", (PyObject *)&kqueue_queue_Type);
-
-    /* event filters */
-    PyModule_AddIntConstant(m, "KQ_FILTER_READ", EVFILT_READ);
-    PyModule_AddIntConstant(m, "KQ_FILTER_WRITE", EVFILT_WRITE);
-    PyModule_AddIntConstant(m, "KQ_FILTER_AIO", EVFILT_AIO);
-    PyModule_AddIntConstant(m, "KQ_FILTER_VNODE", EVFILT_VNODE);
-    PyModule_AddIntConstant(m, "KQ_FILTER_PROC", EVFILT_PROC);
-#ifdef EVFILT_NETDEV
-    PyModule_AddIntConstant(m, "KQ_FILTER_NETDEV", EVFILT_NETDEV);
-#endif
-    PyModule_AddIntConstant(m, "KQ_FILTER_SIGNAL", EVFILT_SIGNAL);
-    PyModule_AddIntConstant(m, "KQ_FILTER_TIMER", EVFILT_TIMER);
-
-    /* event flags */
-    PyModule_AddIntConstant(m, "KQ_EV_ADD", EV_ADD);
-    PyModule_AddIntConstant(m, "KQ_EV_DELETE", EV_DELETE);
-    PyModule_AddIntConstant(m, "KQ_EV_ENABLE", EV_ENABLE);
-    PyModule_AddIntConstant(m, "KQ_EV_DISABLE", EV_DISABLE);
-    PyModule_AddIntConstant(m, "KQ_EV_ONESHOT", EV_ONESHOT);
-    PyModule_AddIntConstant(m, "KQ_EV_CLEAR", EV_CLEAR);
-
-    PyModule_AddIntConstant(m, "KQ_EV_SYSFLAGS", EV_SYSFLAGS);
-    PyModule_AddIntConstant(m, "KQ_EV_FLAG1", EV_FLAG1);
-
-    PyModule_AddIntConstant(m, "KQ_EV_EOF", EV_EOF);
-    PyModule_AddIntConstant(m, "KQ_EV_ERROR", EV_ERROR);
-
-    /* READ WRITE filter flag */
-    PyModule_AddIntConstant(m, "KQ_NOTE_LOWAT", NOTE_LOWAT);
-
-    /* VNODE filter flags  */
-    PyModule_AddIntConstant(m, "KQ_NOTE_DELETE", NOTE_DELETE);
-    PyModule_AddIntConstant(m, "KQ_NOTE_WRITE", NOTE_WRITE);
-    PyModule_AddIntConstant(m, "KQ_NOTE_EXTEND", NOTE_EXTEND);
-    PyModule_AddIntConstant(m, "KQ_NOTE_ATTRIB", NOTE_ATTRIB);
-    PyModule_AddIntConstant(m, "KQ_NOTE_LINK", NOTE_LINK);
-    PyModule_AddIntConstant(m, "KQ_NOTE_RENAME", NOTE_RENAME);
-    PyModule_AddIntConstant(m, "KQ_NOTE_REVOKE", NOTE_REVOKE);
-
-    /* PROC filter flags  */
-    PyModule_AddIntConstant(m, "KQ_NOTE_EXIT", NOTE_EXIT);
-    PyModule_AddIntConstant(m, "KQ_NOTE_FORK", NOTE_FORK);
-    PyModule_AddIntConstant(m, "KQ_NOTE_EXEC", NOTE_EXEC);
-    PyModule_AddIntConstant(m, "KQ_NOTE_PCTRLMASK", NOTE_PCTRLMASK);
-    PyModule_AddIntConstant(m, "KQ_NOTE_PDATAMASK", NOTE_PDATAMASK);
-
-    PyModule_AddIntConstant(m, "KQ_NOTE_TRACK", NOTE_TRACK);
-    PyModule_AddIntConstant(m, "KQ_NOTE_CHILD", NOTE_CHILD);
-    PyModule_AddIntConstant(m, "KQ_NOTE_TRACKERR", NOTE_TRACKERR);
-
-    /* NETDEV filter flags */
-#ifdef EVFILT_NETDEV
-    PyModule_AddIntConstant(m, "KQ_NOTE_LINKUP", NOTE_LINKUP);
-    PyModule_AddIntConstant(m, "KQ_NOTE_LINKDOWN", NOTE_LINKDOWN);
-    PyModule_AddIntConstant(m, "KQ_NOTE_LINKINV", NOTE_LINKINV);
-#endif
-
-#endif /* HAVE_KQUEUE */
-    return m;
-}
diff -r 1287d4c9cd39 PC/VS9.0/select.vcproj
--- a/PC/VS9.0/select.vcproj	Fri Aug 02 10:22:07 2013 +0200
+++ b/PC/VS9.0/select.vcproj	Fri Aug 02 19:45:03 2013 +0200
@@ -527,7 +527,7 @@
 			Name="Source Files"
 			>
 			<File
-				RelativePath="..\..\Modules\selectmodule.c"
+				RelativePath="..\..\Modules\_selectmodule.c"
 				>
 			</File>
 		</Filter>
diff -r 1287d4c9cd39 PCbuild/readme.txt
--- a/PCbuild/readme.txt	Fri Aug 02 10:22:07 2013 +0200
+++ b/PCbuild/readme.txt	Fri Aug 02 19:45:03 2013 +0200
@@ -92,8 +92,8 @@
 pyexpat
     Python wrapper for accelerated XML parsing, which incorporates stable
     code from the Expat project:  http://sourceforge.net/projects/expat/
-select
-    selectmodule.c
+_select
+    _selectmodule.c
 unicodedata
     large tables of Unicode data
 winsound
diff -r 1287d4c9cd39 PCbuild/select.vcxproj
--- a/PCbuild/select.vcxproj	Fri Aug 02 10:22:07 2013 +0200
+++ b/PCbuild/select.vcxproj	Fri Aug 02 19:45:03 2013 +0200
@@ -220,7 +220,7 @@
     </Link>
   </ItemDefinitionGroup>
   <ItemGroup>
-    <ClCompile Include="..\Modules\selectmodule.c" />
+    <ClCompile Include="..\Modules\_selectmodule.c" />
   </ItemGroup>
   <ItemGroup>
     <ProjectReference Include="pythoncore.vcxproj">
@@ -231,4 +231,4 @@
   <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
   <ImportGroup Label="ExtensionTargets">
   </ImportGroup>
-</Project>
\ No newline at end of file
+</Project>
diff -r 1287d4c9cd39 PCbuild/select.vcxproj.filters
--- a/PCbuild/select.vcxproj.filters	Fri Aug 02 10:22:07 2013 +0200
+++ b/PCbuild/select.vcxproj.filters	Fri Aug 02 19:45:03 2013 +0200
@@ -6,8 +6,8 @@
     </Filter>
   </ItemGroup>
   <ItemGroup>
-    <ClCompile Include="..\Modules\selectmodule.c">
+    <ClCompile Include="..\Modules\_selectmodule.c">
       <Filter>Source Files</Filter>
     </ClCompile>
   </ItemGroup>
-</Project>
\ No newline at end of file
+</Project>
diff -r 1287d4c9cd39 setup.py
--- a/setup.py	Fri Aug 02 10:22:07 2013 +0200
+++ b/setup.py	Fri Aug 02 19:45:03 2013 +0200
@@ -619,7 +619,7 @@
             missing.append('spwd')
 
         # select(2); not on ancient System V
-        exts.append( Extension('select', ['selectmodule.c']) )
+        exts.append( Extension('_select', ['_selectmodule.c']) )
 
         # Fred Drake's interface to the Python parser
         exts.append( Extension('parser', ['parsermodule.c']) )
-------------- next part --------------
diff -r 110a10e0733a examples/wsclient.py
--- a/examples/wsclient.py	Mon Jul 29 10:36:33 2013 -0700
+++ b/examples/wsclient.py	Fri Aug 02 19:32:13 2013 +0200
@@ -4,13 +4,13 @@
 import base64
 import hashlib
 import os
+import select
 import signal
 import sys
 
 import tulip
 import tulip.http
 from tulip.http import websocket
-import tulip.selectors
 
 WS_KEY = b"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
 
@@ -89,7 +89,7 @@
 
     url = 'http://{}:{}'.format(args.host, args.port)
 
-    loop = tulip.SelectorEventLoop(tulip.selectors.SelectSelector())
+    loop = tulip.SelectorEventLoop(select.SelectSelector())
     tulip.set_event_loop(loop)
 
     loop.add_signal_handler(signal.SIGINT, loop.stop)
diff -r 110a10e0733a tests/events_test.py
--- a/tests/events_test.py	Mon Jul 29 10:36:33 2013 -0700
+++ b/tests/events_test.py	Fri Aug 02 19:32:13 2013 +0200
@@ -4,6 +4,7 @@
 import io
 import os
 import re
+import select
 import signal
 import socket
 try:
@@ -900,33 +901,32 @@
             raise unittest.SkipTest(
                 "IocpEventLoop does not have create_datagram_endpoint()")
 else:
-    from tulip import selectors
     from tulip import unix_events
 
-    if hasattr(selectors, 'KqueueSelector'):
+    if hasattr(select, 'KqueueSelector'):
         class KqueueEventLoopTests(EventLoopTestsMixin, unittest.TestCase):
 
             def create_event_loop(self):
                 return unix_events.SelectorEventLoop(
-                    selectors.KqueueSelector())
+                    select.KqueueSelector())
 
-    if hasattr(selectors, 'EpollSelector'):
+    if hasattr(select, 'EpollSelector'):
         class EPollEventLoopTests(EventLoopTestsMixin, unittest.TestCase):
 
             def create_event_loop(self):
-                return unix_events.SelectorEventLoop(selectors.EpollSelector())
+                return unix_events.SelectorEventLoop(select.EpollSelector())
 
-    if hasattr(selectors, 'PollSelector'):
+    if hasattr(select, 'PollSelector'):
         class PollEventLoopTests(EventLoopTestsMixin, unittest.TestCase):
 
             def create_event_loop(self):
-                return unix_events.SelectorEventLoop(selectors.PollSelector())
+                return unix_events.SelectorEventLoop(select.PollSelector())
 
     # Should always exist.
     class SelectEventLoopTests(EventLoopTestsMixin, unittest.TestCase):
 
         def create_event_loop(self):
-            return unix_events.SelectorEventLoop(selectors.SelectSelector())
+            return unix_events.SelectorEventLoop(select.SelectSelector())
 
 
 class HandleTests(unittest.TestCase):
diff -r 110a10e0733a tests/selector_events_test.py
--- a/tests/selector_events_test.py	Mon Jul 29 10:36:33 2013 -0700
+++ b/tests/selector_events_test.py	Fri Aug 02 19:32:13 2013 +0200
@@ -1,6 +1,7 @@
 """Tests for selector_events.py"""
 
 import errno
+import select
 import socket
 import unittest
 import unittest.mock
@@ -10,7 +11,6 @@
     ssl = None
 
 from tulip import futures
-from tulip import selectors
 from tulip.events import AbstractEventLoop
 from tulip.protocols import DatagramProtocol, Protocol
 from tulip.selector_events import BaseSelectorEventLoop
@@ -399,7 +399,7 @@
         self.assertTrue(self.loop._selector.register.called)
         fd, mask, (r, w) = self.loop._selector.register.call_args[0]
         self.assertEqual(1, fd)
-        self.assertEqual(selectors.EVENT_READ, mask)
+        self.assertEqual(select.EVENT_READ, mask)
         self.assertEqual(cb, r._callback)
         self.assertEqual(None, w)
 
@@ -407,7 +407,7 @@
         reader = unittest.mock.Mock()
         writer = unittest.mock.Mock()
         self.loop._selector.get_info.return_value = (
-            selectors.EVENT_WRITE, (reader, writer))
+            select.EVENT_WRITE, (reader, writer))
         cb = lambda: True
         self.loop.add_reader(1, cb)
 
@@ -416,14 +416,14 @@
         self.assertTrue(self.loop._selector.modify.called)
         fd, mask, (r, w) = self.loop._selector.modify.call_args[0]
         self.assertEqual(1, fd)
-        self.assertEqual(selectors.EVENT_WRITE | selectors.EVENT_READ, mask)
+        self.assertEqual(select.EVENT_WRITE | select.EVENT_READ, mask)
         self.assertEqual(cb, r._callback)
         self.assertEqual(writer, w)
 
     def test_add_reader_existing_writer(self):
         writer = unittest.mock.Mock()
         self.loop._selector.get_info.return_value = (
-            selectors.EVENT_WRITE, (None, writer))
+            select.EVENT_WRITE, (None, writer))
         cb = lambda: True
         self.loop.add_reader(1, cb)
 
@@ -431,13 +431,13 @@
         self.assertTrue(self.loop._selector.modify.called)
         fd, mask, (r, w) = self.loop._selector.modify.call_args[0]
         self.assertEqual(1, fd)
-        self.assertEqual(selectors.EVENT_WRITE | selectors.EVENT_READ, mask)
+        self.assertEqual(select.EVENT_WRITE | select.EVENT_READ, mask)
         self.assertEqual(cb, r._callback)
         self.assertEqual(writer, w)
 
     def test_remove_reader(self):
         self.loop._selector.get_info.return_value = (
-            selectors.EVENT_READ, (None, None))
+            select.EVENT_READ, (None, None))
         self.assertFalse(self.loop.remove_reader(1))
 
         self.assertTrue(self.loop._selector.unregister.called)
@@ -446,13 +446,13 @@
         reader = unittest.mock.Mock()
         writer = unittest.mock.Mock()
         self.loop._selector.get_info.return_value = (
-            selectors.EVENT_READ | selectors.EVENT_WRITE, (reader, writer))
+            select.EVENT_READ | select.EVENT_WRITE, (reader, writer))
         self.assertTrue(
             self.loop.remove_reader(1))
 
         self.assertFalse(self.loop._selector.unregister.called)
         self.assertEqual(
-            (1, selectors.EVENT_WRITE, (None, writer)),
+            (1, select.EVENT_WRITE, (None, writer)),
             self.loop._selector.modify.call_args[0])
 
     def test_remove_reader_unknown(self):
@@ -468,7 +468,7 @@
         self.assertTrue(self.loop._selector.register.called)
         fd, mask, (r, w) = self.loop._selector.register.call_args[0]
         self.assertEqual(1, fd)
-        self.assertEqual(selectors.EVENT_WRITE, mask)
+        self.assertEqual(select.EVENT_WRITE, mask)
         self.assertEqual(None, r)
         self.assertEqual(cb, w._callback)
 
@@ -476,7 +476,7 @@
         reader = unittest.mock.Mock()
         writer = unittest.mock.Mock()
         self.loop._selector.get_info.return_value = (
-            selectors.EVENT_READ, (reader, writer))
+            select.EVENT_READ, (reader, writer))
         cb = lambda: True
         self.loop.add_writer(1, cb)
 
@@ -485,13 +485,13 @@
         self.assertTrue(self.loop._selector.modify.called)
         fd, mask, (r, w) = self.loop._selector.modify.call_args[0]
         self.assertEqual(1, fd)
-        self.assertEqual(selectors.EVENT_WRITE | selectors.EVENT_READ, mask)
+        self.assertEqual(select.EVENT_WRITE | select.EVENT_READ, mask)
         self.assertEqual(reader, r)
         self.assertEqual(cb, w._callback)
 
     def test_remove_writer(self):
         self.loop._selector.get_info.return_value = (
-            selectors.EVENT_WRITE, (None, None))
+            select.EVENT_WRITE, (None, None))
         self.assertFalse(self.loop.remove_writer(1))
 
         self.assertTrue(self.loop._selector.unregister.called)
@@ -500,13 +500,13 @@
         reader = unittest.mock.Mock()
         writer = unittest.mock.Mock()
         self.loop._selector.get_info.return_value = (
-            selectors.EVENT_READ | selectors.EVENT_WRITE, (reader, writer))
+            select.EVENT_READ | select.EVENT_WRITE, (reader, writer))
         self.assertTrue(
             self.loop.remove_writer(1))
 
         self.assertFalse(self.loop._selector.unregister.called)
         self.assertEqual(
-            (1, selectors.EVENT_READ, (reader, None)),
+            (1, select.EVENT_READ, (reader, None)),
             self.loop._selector.modify.call_args[0])
 
     def test_remove_writer_unknown(self):
@@ -520,7 +520,7 @@
 
         self.loop._add_callback = unittest.mock.Mock()
         self.loop._process_events(
-            ((1, selectors.EVENT_READ, (reader, None)),))
+            ((1, select.EVENT_READ, (reader, None)),))
         self.assertTrue(self.loop._add_callback.called)
         self.loop._add_callback.assert_called_with(reader)
 
@@ -530,7 +530,7 @@
 
         self.loop.remove_reader = unittest.mock.Mock()
         self.loop._process_events(
-            ((1, selectors.EVENT_READ, (reader, None)),))
+            ((1, select.EVENT_READ, (reader, None)),))
         self.loop.remove_reader.assert_called_with(1)
 
     def test_process_events_write(self):
@@ -539,7 +539,7 @@
 
         self.loop._add_callback = unittest.mock.Mock()
         self.loop._process_events(
-            ((1, selectors.EVENT_WRITE, (None, writer)),))
+            ((1, select.EVENT_WRITE, (None, writer)),))
         self.loop._add_callback.assert_called_with(writer)
 
     def test_process_events_write_cancelled(self):
@@ -548,7 +548,7 @@
         self.loop.remove_writer = unittest.mock.Mock()
 
         self.loop._process_events(
-            ((1, selectors.EVENT_WRITE, (None, writer)),))
+            ((1, select.EVENT_WRITE, (None, writer)),))
         self.loop.remove_writer.assert_called_with(1)
 
 
diff -r 110a10e0733a tests/selectors_test.py
--- a/tests/selectors_test.py	Mon Jul 29 10:36:33 2013 -0700
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,143 +0,0 @@
-"""Tests for selectors.py."""
-
-import unittest
-import unittest.mock
-
-from tulip import selectors
-
-
-class BaseSelectorTests(unittest.TestCase):
-
-    def test_fileobj_to_fd(self):
-        self.assertEqual(10, selectors._fileobj_to_fd(10))
-
-        f = unittest.mock.Mock()
-        f.fileno.return_value = 10
-        self.assertEqual(10, selectors._fileobj_to_fd(f))
-
-        f.fileno.side_effect = TypeError
-        self.assertRaises(ValueError, selectors._fileobj_to_fd, f)
-
-    def test_selector_key_repr(self):
-        key = selectors.SelectorKey(10, selectors.EVENT_READ)
-        self.assertEqual(
-            "SelectorKey<fileobj=10, fd=10, events=0x1, data=None>", repr(key))
-
-    def test_register(self):
-        fobj = unittest.mock.Mock()
-        fobj.fileno.return_value = 10
-
-        s = selectors._BaseSelector()
-        key = s.register(fobj, selectors.EVENT_READ)
-        self.assertIsInstance(key, selectors.SelectorKey)
-        self.assertEqual(key.fd, 10)
-        self.assertIs(key, s._fd_to_key[10])
-
-    def test_register_unknown_event(self):
-        s = selectors._BaseSelector()
-        self.assertRaises(ValueError, s.register, unittest.mock.Mock(), 999999)
-
-    def test_register_already_registered(self):
-        fobj = unittest.mock.Mock()
-        fobj.fileno.return_value = 10
-
-        s = selectors._BaseSelector()
-        s.register(fobj, selectors.EVENT_READ)
-        self.assertRaises(ValueError, s.register, fobj, selectors.EVENT_READ)
-
-    def test_unregister(self):
-        fobj = unittest.mock.Mock()
-        fobj.fileno.return_value = 10
-
-        s = selectors._BaseSelector()
-        s.register(fobj, selectors.EVENT_READ)
-        s.unregister(fobj)
-        self.assertFalse(s._fd_to_key)
-        self.assertFalse(s._fileobj_to_key)
-
-    def test_unregister_unknown(self):
-        s = selectors._BaseSelector()
-        self.assertRaises(ValueError, s.unregister, unittest.mock.Mock())
-
-    def test_modify_unknown(self):
-        s = selectors._BaseSelector()
-        self.assertRaises(ValueError, s.modify, unittest.mock.Mock(), 1)
-
-    def test_modify(self):
-        fobj = unittest.mock.Mock()
-        fobj.fileno.return_value = 10
-
-        s = selectors._BaseSelector()
-        key = s.register(fobj, selectors.EVENT_READ)
-        key2 = s.modify(fobj, selectors.EVENT_WRITE)
-        self.assertNotEqual(key.events, key2.events)
-        self.assertEqual((selectors.EVENT_WRITE, None), s.get_info(fobj))
-
-    def test_modify_data(self):
-        fobj = unittest.mock.Mock()
-        fobj.fileno.return_value = 10
-
-        d1 = object()
-        d2 = object()
-
-        s = selectors._BaseSelector()
-        key = s.register(fobj, selectors.EVENT_READ, d1)
-        key2 = s.modify(fobj, selectors.EVENT_READ, d2)
-        self.assertEqual(key.events, key2.events)
-        self.assertNotEqual(key.data, key2.data)
-        self.assertEqual((selectors.EVENT_READ, d2), s.get_info(fobj))
-
-    def test_modify_same(self):
-        fobj = unittest.mock.Mock()
-        fobj.fileno.return_value = 10
-
-        data = object()
-
-        s = selectors._BaseSelector()
-        key = s.register(fobj, selectors.EVENT_READ, data)
-        key2 = s.modify(fobj, selectors.EVENT_READ, data)
-        self.assertIs(key, key2)
-
-    def test_select(self):
-        s = selectors._BaseSelector()
-        self.assertRaises(NotImplementedError, s.select)
-
-    def test_close(self):
-        s = selectors._BaseSelector()
-        s.register(1, selectors.EVENT_READ)
-
-        s.close()
-        self.assertFalse(s._fd_to_key)
-        self.assertFalse(s._fileobj_to_key)
-
-    def test_registered_count(self):
-        s = selectors._BaseSelector()
-        self.assertEqual(0, s.registered_count())
-
-        s.register(1, selectors.EVENT_READ)
-        self.assertEqual(1, s.registered_count())
-
-        s.unregister(1)
-        self.assertEqual(0, s.registered_count())
-
-    def test_context_manager(self):
-        s = selectors._BaseSelector()
-
-        with s as sel:
-            sel.register(1, selectors.EVENT_READ)
-
-        self.assertFalse(s._fd_to_key)
-        self.assertFalse(s._fileobj_to_key)
-
-    @unittest.mock.patch('tulip.selectors.tulip_log')
-    def test_key_from_fd(self, m_log):
-        s = selectors._BaseSelector()
-        key = s.register(1, selectors.EVENT_READ)
-
-        self.assertIs(key, s._key_from_fd(1))
-        self.assertIsNone(s._key_from_fd(10))
-        m_log.warning.assert_called_with('No key found for fd %r', 10)
-
-    if hasattr(selectors.DefaultSelector, 'fileno'):
-        def test_fileno(self):
-            self.assertIsInstance(selectors.DefaultSelector().fileno(), int)
diff -r 110a10e0733a tulip/selector_events.py
--- a/tulip/selector_events.py	Mon Jul 29 10:36:33 2013 -0700
+++ b/tulip/selector_events.py	Fri Aug 02 19:32:13 2013 +0200
@@ -5,6 +5,7 @@
 """
 
 import collections
+import select
 import socket
 try:
     import ssl
@@ -15,7 +16,6 @@
 from . import constants
 from . import events
 from . import futures
-from . import selectors
 from . import transports
 from .log import tulip_log
 
@@ -43,7 +43,7 @@
         super().__init__()
 
         if selector is None:
-            selector = selectors.DefaultSelector()
+            selector = select.DefaultSelector()
         tulip_log.debug('Using selector: %s', selector.__class__.__name__)
         self._selector = selector
         self._make_self_pipe()
@@ -131,10 +131,10 @@
         try:
             mask, (reader, writer) = self._selector.get_info(fd)
         except KeyError:
-            self._selector.register(fd, selectors.EVENT_READ,
+            self._selector.register(fd, select.EVENT_READ,
                                     (handle, None))
         else:
-            self._selector.modify(fd, mask | selectors.EVENT_READ,
+            self._selector.modify(fd, mask | select.EVENT_READ,
                                   (handle, writer))
             if reader is not None:
                 reader.cancel()
@@ -146,7 +146,7 @@
         except KeyError:
             return False
         else:
-            mask &= ~selectors.EVENT_READ
+            mask &= ~select.EVENT_READ
             if not mask:
                 self._selector.unregister(fd)
             else:
@@ -164,10 +164,10 @@
         try:
             mask, (reader, writer) = self._selector.get_info(fd)
         except KeyError:
-            self._selector.register(fd, selectors.EVENT_WRITE,
+            self._selector.register(fd, select.EVENT_WRITE,
                                     (None, handle))
         else:
-            self._selector.modify(fd, mask | selectors.EVENT_WRITE,
+            self._selector.modify(fd, mask | select.EVENT_WRITE,
                                   (reader, handle))
             if writer is not None:
                 writer.cancel()
@@ -180,7 +180,7 @@
             return False
         else:
             # Remove both writer and connector.
-            mask &= ~selectors.EVENT_WRITE
+            mask &= ~select.EVENT_WRITE
             if not mask:
                 self._selector.unregister(fd)
             else:
@@ -309,12 +309,12 @@
 
     def _process_events(self, event_list):
         for fileobj, mask, (reader, writer) in event_list:
-            if mask & selectors.EVENT_READ and reader is not None:
+            if mask & select.EVENT_READ and reader is not None:
                 if reader._cancelled:
                     self.remove_reader(fileobj)
                 else:
                     self._add_callback(reader)
-            if mask & selectors.EVENT_WRITE and writer is not None:
+            if mask & select.EVENT_WRITE and writer is not None:
                 if writer._cancelled:
                     self.remove_writer(fileobj)
                 else:

From report at bugs.python.org  Fri Aug  2 23:27:58 2013
From: report at bugs.python.org (Madison May)
Date: Fri, 02 Aug 2013 21:27:58 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375478878.14.0.279166874419.issue18629@psf.upfronthosting.co.za>


Madison May added the comment:

I agree -- it's not at all intuitive that the floor division returns a decimal number of seconds, while float division raises an error.  This should probably be cleaned up.   

In python 3.4, both float division and integer division return decimal numbers of seconds -- that's not all that intuitive, either.  

Python 3.4.0a0 (default:d5536c06a082+, Jul 11 2013, 20:23:54) 
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import timedelta
>>> print(timedelta(seconds=3)/2)
0:00:01.500000
>>> print(timedelta(seconds=3)//2)
0:00:01.500000

----------
nosy: +madison.may

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

From report at bugs.python.org  Fri Aug  2 23:33:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Aug 2013 21:33:12 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375479192.77.0.0833014536025.issue18629@psf.upfronthosting.co.za>


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


----------
nosy: +belopolsky, lemburg

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

From report at bugs.python.org  Fri Aug  2 23:42:59 2013
From: report at bugs.python.org (Madison May)
Date: Fri, 02 Aug 2013 21:42:59 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1375479779.99.0.778346245122.issue8998@psf.upfronthosting.co.za>


Madison May added the comment:

This issue may have been dead for 3+ years, but perhaps it's time its brought back to the surface.  Aside from simple being convenient for general security practices, a stdlib module for crypto routines would enable python to handle encrypted zipfiles and resolve issues like issue9170. Currently, only hashlib and hmac are available to users (see http://docs.python.org/3/library/crypto.html).  

I'd imagine that collaboration with the likes of Dwayne from PyCrypto or further collaboration with Geremy from Evpy would be possible, and perhaps the stdlib could build on a 3rd party crypto library.  Is anyone else interested in working to make this happen (or does anyone have a good argument against a stdlib crypto library)?  I imagine it would be difficult to maintain, but perhaps its at least worth giving this issue a second chance.

----------
nosy: +madison.may

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

From report at bugs.python.org  Fri Aug  2 23:54:27 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 02 Aug 2013 21:54:27 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1375479779.99.0.778346245122.issue8998@psf.upfronthosting.co.za>
Message-ID: <51FC2A8B.7000305@egenix.com>


Marc-Andre Lemburg added the comment:

Madison May wrote:
> This issue may have been dead for 3+ years, but perhaps it's time its brought back to the surface.  Aside from simple being convenient for general security practices, a stdlib module for crypto routines would enable python to handle encrypted zipfiles and resolve issues like issue9170. Currently, only hashlib and hmac are available to users (see http://docs.python.org/3/library/crypto.html).  
> 
> I'd imagine that collaboration with the likes of Dwayne from PyCrypto or further collaboration with Geremy from Evpy would be possible, and perhaps the stdlib could build on a 3rd party crypto library.  Is anyone else interested in working to make this happen (or does anyone have a good argument against a stdlib crypto library)?  I imagine it would be difficult to maintain, but perhaps its at least worth giving this issue a second chance.

IMO, it's better to have crypto routines not be part of the stdlib.
Not because there's a technical reason. Making crypto code part of
the stdlib would create legal issues, e.g. make it illegal to use
in some parts of the world.

See http://www.cryptolaw.org/ for details.

----------

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

From report at bugs.python.org  Fri Aug  2 23:56:50 2013
From: report at bugs.python.org (Madison May)
Date: Fri, 02 Aug 2013 21:56:50 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1375480610.84.0.797617981238.issue8998@psf.upfronthosting.co.za>


Madison May added the comment:

Yeah, that definitely qualifies as a good argument.  I didn't consider the legal issues that would create.  Let's let this issue rest in peace, then.

----------

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

From report at bugs.python.org  Sat Aug  3 00:01:19 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 02 Aug 2013 22:01:19 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1375480879.36.0.421825405974.issue8998@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

The interest is there but nobody is designing or implementing it. Realistically, make a module sporting the proposed API and put it up on pypi and after success there: raise the issue on python-ideas.

Read the entire thread here first before designing such a thing.

We will always have unsolvable problems in any crypto shipped with Python such as side channel attacks. Those are outside the scope of what the CPython project should ever attempt to solve. Document them as weaknesses and suggest people use C libraries dedicated to avoiding those problems if their security needs require it.

----------

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

From report at bugs.python.org  Sat Aug  3 00:03:09 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 02 Aug 2013 22:03:09 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1375480989.61.0.121408019553.issue8998@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Python already ships with SSL support so the legal ship might have sailed ages ago if thats what PSF lawyers say. (IANAL)

----------
resolution:  -> later
status: open -> closed

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

From report at bugs.python.org  Sat Aug  3 00:09:33 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 02 Aug 2013 22:09:33 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1375481373.85.0.998290212438.issue18606@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

note, http://docs.scipy.org/doc/scipy/reference/stats.html#statistical-functions is a very popular module for statistics in Python.

One of the more frequent things I see people include the entire beast of a code base (scipy and numpy) for is the student's t-test functions.

I don't think we can include code from scipy due to license reasons so any implementor should NOT be looking at the scipy code, just the docs for API inspirations.

----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Sat Aug  3 00:10:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Aug 2013 22:10:04 +0000
Subject: [issue17934] Add a frame method to clear expensive details
In-Reply-To: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za>
Message-ID: <1375481404.08.0.7034157405.issue17934@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is an updated patch. Any objections to committing?

----------
Added file: http://bugs.python.org/file31132/frame_clear_alt3.patch

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

From report at bugs.python.org  Sat Aug  3 00:25:41 2013
From: report at bugs.python.org (Valerie Lambert)
Date: Fri, 02 Aug 2013 22:25:41 +0000
Subject: [issue4885] mmap enhancement request
In-Reply-To: <1231445893.72.0.162990779773.issue4885@psf.upfronthosting.co.za>
Message-ID: <1375482341.21.0.349909002761.issue4885@psf.upfronthosting.co.za>


Valerie Lambert added the comment:

I just signed and sent the agreement electronically. Let me know if there is anything else I need to do.

----------

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

From report at bugs.python.org  Sat Aug  3 00:43:31 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Aug 2013 22:43:31 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375483411.35.0.146250533736.issue18629@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I believe this is related to the fact that timedelta * float is not supported in 2.x:

Python 2.7.5 (default, May 24 2013, 15:56:16)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import *
>>> timedelta(2) * 0.5
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float'

I don't see why this is a barrier to Python 3 transitions.  Before you turn on true division you should replace all instances of floor division with '//' anyways.  Just treat instances of timedelta / int as you would instances of int / int.

----------

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

From report at bugs.python.org  Sat Aug  3 00:47:52 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Aug 2013 22:47:52 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375483672.39.0.318388706344.issue18629@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> Does a result of one and one half seconds make sense as the result of a floor division operation?

Yes.  Timedeltas behave as integers containing the number of microseconds:

>>> timedelta(microseconds=1) / 2
datetime.timedelta(0)

----------

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

From report at bugs.python.org  Sat Aug  3 00:47:55 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 02 Aug 2013 22:47:55 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1375483675.16.0.0183350718704.issue16853@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Version addressing Antoine and Christian's comments.

----------
Added file: http://bugs.python.org/file31133/selector-12.diff

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

From report at bugs.python.org  Sat Aug  3 01:38:45 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 02 Aug 2013 23:38:45 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375486725.21.0.5394765724.issue18264@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I've been reading the discussion again to figure out what we need to move forward; it appears that a simple approach of using str(int(obj)) in json encoding when isinstance(obj, int) was acceptable for many of the participants, and it helps solve the most common problem - the one with IntEnum. We can solve it now, move on to converting socket.* and other constants to IntEnum and perhaps change the solution to something more grandiose later.

I'm attaching a proof-of-concept (probably incomplete) patch that implements this for the Python and C implementations of json.

With it applied, Nick's example goes like this:

>>> from enum import IntEnum
>>> import json
>>> class Example(IntEnum): x = 1
... 
>>> json.dumps(Example.x)
'1'
>>> json.loads(json.dumps(Example.x))
1
>>> 

When thinking about the more generic approaches, we must consider what was raised here already - JSON interoperates with other languages, for which Python's enum is meaningless (think of JavaScript, for instance). So the only logical way to JSON-encode a IntEnum is str(int(...)).

----------
keywords: +patch
Added file: http://bugs.python.org/file31134/issue18264.1-prelim.patch

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

From report at bugs.python.org  Sat Aug  3 01:39:57 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 02 Aug 2013 23:39:57 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375486797.32.0.445467563382.issue18264@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

[please note that the patch is POC/hacky at best - it's likely to leak memory and be careless and incomplete in other ways. I'm just trying to demonstrate the approach]

----------

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

From report at bugs.python.org  Sat Aug  3 01:45:54 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 02 Aug 2013 23:45:54 +0000
Subject: [issue18635] Enum sets _member_type_ to instantiated values but not
	the class
In-Reply-To: <1375472056.62.0.564467694147.issue18635@psf.upfronthosting.co.za>
Message-ID: <1375487154.02.0.389825613527.issue18635@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Can you clarify why it would be useful? Note that we're talking about private non-documented members here.

----------

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

From report at bugs.python.org  Sat Aug  3 01:55:58 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 02 Aug 2013 23:55:58 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375487758.54.0.628790032916.issue18264@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I'll check you patch later against big numbers (which is where I had difficulties).  If it works I'll try to make it more complete.  If it doesn't, I've been working on just extraction the Enum member's value and using that (works fine on the Python side ;) .

Big Question:  if the Enum member was used as a key, do we use .name or .value?  The decision I went with was to compare the hashes of the member name vs the member itself -- if they're the same, use the .name, otherwise use the value.

----------

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

From report at bugs.python.org  Sat Aug  3 02:05:57 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 03 Aug 2013 00:05:57 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375488357.64.0.0405989667564.issue18264@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I don't think my idea of always extracting .value is grandiose (and didn't take that long to implement on the Python side), but it is definitely forcing me to learn more about C and how Python is put together.

It this point I have successfully imported Enum into the _json module; now I'm working on a function to quietly replace the object being encoded with its .value if it is, in fact, an Enum member.

Just been real short on time lately.  :/

Thank goodness for C API section of the docs!

----------

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

From report at bugs.python.org  Sat Aug  3 02:13:26 2013
From: report at bugs.python.org (Madison May)
Date: Sat, 03 Aug 2013 00:13:26 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1373400107.5.0.285657244525.issue18416@psf.upfronthosting.co.za>
Message-ID: <1375488806.64.0.934325813706.issue18416@psf.upfronthosting.co.za>


Madison May added the comment:

PathFinder or FileFinder?  Changing PathFinder._path_importer_cache(cls, path) seems to fix the issue.

See line 1302 in _bootstrap.py.

         if path == '':
-            path = '.'
+            path = _os.getcwd()


$ touch blah.py; ./python -c "import blah; print(blah.__file__)"
/home/mmay/cpython/blah.py

----------
nosy: +madison.may

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

From report at bugs.python.org  Sat Aug  3 02:21:17 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 03 Aug 2013 00:21:17 +0000
Subject: [issue18635] Enum sets _member_type_ to instantiated values but not
	the class
In-Reply-To: <1375472056.62.0.564467694147.issue18635@psf.upfronthosting.co.za>
Message-ID: <1375489277.81.0.974696504827.issue18635@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I also admit to being curious as to the reason it is useful, especially since it is, at this point, an implementation detail.

Even so, it still makes more sense to have that attribute on the class instead of the instance.

----------

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

From report at bugs.python.org  Sat Aug  3 03:06:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Aug 2013 01:06:14 +0000
Subject: [issue17046] test_subprocess test_executable_without_cwd fails when
	run with installed python
In-Reply-To: <1359266652.98.0.400492689788.issue17046@psf.upfronthosting.co.za>
Message-ID: <3c6Rrj2YGdz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset f37b336bfbca by Ned Deily in branch '3.3':
Issue #17046: Fix test_subprocess test_executable_without_cwd broken test case.
http://hg.python.org/cpython/rev/f37b336bfbca

New changeset e3e28ee5b5c3 by Ned Deily in branch 'default':
Issue #17046: merge from 3.3
http://hg.python.org/cpython/rev/e3e28ee5b5c3

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Aug  3 03:15:19 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Aug 2013 01:15:19 +0000
Subject: [issue17046] test_subprocess test_executable_without_cwd fails when
	run with installed python
In-Reply-To: <1359266652.98.0.400492689788.issue17046@psf.upfronthosting.co.za>
Message-ID: <1375492519.24.0.438036362866.issue17046@psf.upfronthosting.co.za>


Ned Deily added the comment:

test_executable_without_cwd was broken by the test enhancements added for Issue15533.  This particular test case is skipped unless the tests are being run from an installed Python rather than from a build directory, the more typical case.  The applied patch (for release in 3.3.3 and 3.4.0) fixes the problem.

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

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

From report at bugs.python.org  Sat Aug  3 03:56:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Aug 2013 01:56:20 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1375494980.19.0.654214173098.issue11798@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

If the iterator for 'self' were de-structive, if it removed (popped) the test from whatever structure holds it before yielding it, the messiness of enumerate and the new ._removeTestAtIndex method would not be needed and 'for test in self' would work as desired. If considered necessary,  new method .pop_iter, used in 'for test in self.pop_iter', would make it obvious that the iteration empties the collection.

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

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

From report at bugs.python.org  Sat Aug  3 04:31:09 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Aug 2013 02:31:09 +0000
Subject: [issue18270] IDLE on OS X fails with Attribute Error if no initial
	shell and Tk out-of-date
In-Reply-To: <1371739202.98.0.896833417364.issue18270@psf.upfronthosting.co.za>
Message-ID: <1375497069.91.0.476240235817.issue18270@psf.upfronthosting.co.za>


Ned Deily added the comment:

Terry, your patch did not get attached.  Do you still have it?

----------

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

From report at bugs.python.org  Sat Aug  3 04:42:35 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Aug 2013 02:42:35 +0000
Subject: [issue17704] ImportError: No module named '_curses'
In-Reply-To: <1365780009.75.0.902696843023.issue17704@psf.upfronthosting.co.za>
Message-ID: <1375497755.72.0.407018340231.issue17704@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
status: pending -> closed

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

From report at bugs.python.org  Sat Aug  3 04:52:51 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Aug 2013 02:52:51 +0000
Subject: [issue17216] sparc linux build fails with "could not import runpy
	module"
In-Reply-To: <1361030549.85.0.142057307455.issue17216@psf.upfronthosting.co.za>
Message-ID: <1375498371.69.0.361441367863.issue17216@psf.upfronthosting.co.za>


Ned Deily added the comment:

Since there has been no further activity on this issue and it seems to be isolated to a particular user build, I'm going to close this.  Feel free to reopen with more documentation if you believe there is a problem with Python itself.

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

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

From report at bugs.python.org  Sat Aug  3 05:02:19 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Aug 2013 03:02:19 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1375498939.37.0.636197500721.issue18606@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Is there a reason why there is no "review" link?  Could it be because the file is uploaded as is rather than as a patch?

In any case, I have a question about this code in sum:

                # Convert running total to a float. See comment below for
                # why we do it this way.
                total = type(total).__float__(total)

The "comment below" says:

            # Don't call float() directly, as that converts strings and we
            # don't want that. Also, like all dunder methods, we should call
            # __float__ on the class, not the instance.
            x = type(x).__float__(x)

but this reason does not apply to total that cannot be a string unless you add instances of a really weird class in which case all bets are off and the dunder method won't help much.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Sat Aug  3 05:19:51 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Aug 2013 03:19:51 +0000
Subject: [issue15398] intermittence on UnicodeFileTests.test_rename at
	test_pep277 on MacOS X
In-Reply-To: <1342722837.32.0.395738739848.issue15398@psf.upfronthosting.co.za>
Message-ID: <1375499991.59.0.489814221957.issue15398@psf.upfronthosting.co.za>


Ned Deily added the comment:

Has anyone seen this problem on other than OS X 10.6?  If not, I suggest we assume it was, in fact, due to a platform bug and close.

----------

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

From report at bugs.python.org  Sat Aug  3 05:22:00 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Aug 2013 03:22:00 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1375500120.19.0.896650033196.issue18606@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

The implementation of median and mode families of functions as classes is clever, but I am not sure it is a good idea to return something other than an instance of the class from __new__().  I would prefer to see a more traditional implementation along the lines:

class _mode:
    def __call__(self, data, ..):
        ..
    def collate(self, data, ..):
        ..
mode = _mode()

----------

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

From report at bugs.python.org  Sat Aug  3 05:37:26 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 03 Aug 2013 03:37:26 +0000
Subject: [issue18599] _sha1module report "SHA" as its name
In-Reply-To: <1375189512.2.0.0677739604762.issue18599@psf.upfronthosting.co.za>
Message-ID: <1375501046.78.0.20130757769.issue18599@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Sat Aug  3 05:41:06 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 03 Aug 2013 03:41:06 +0000
Subject: [issue18595] zipfile: symlinks etc.
In-Reply-To: <1375170318.76.0.496081120587.issue18595@psf.upfronthosting.co.za>
Message-ID: <1375501266.5.0.157608805297.issue18595@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Ronald, could you try to write a patch?

----------
nosy: +jcea
stage: test needed -> needs patch

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

From report at bugs.python.org  Sat Aug  3 05:41:36 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 03 Aug 2013 03:41:36 +0000
Subject: [issue18594] C accelerator for collections.Counter is slow
In-Reply-To: <1375166960.42.0.521563124847.issue18594@psf.upfronthosting.co.za>
Message-ID: <1375501296.96.0.61677379268.issue18594@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Sat Aug  3 05:47:44 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 03 Aug 2013 03:47:44 +0000
Subject: [issue18602] "_io" module names itself "io"
In-Reply-To: <1375214267.87.0.837503153982.issue18602@psf.upfronthosting.co.za>
Message-ID: <1375501664.57.0.284486336087.issue18602@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Sat Aug  3 06:11:24 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Aug 2013 04:11:24 +0000
Subject: [issue18270] IDLE on OS X fails with Attribute Error if no initial
	shell and Tk out-of-date
In-Reply-To: <1371739202.98.0.896833417364.issue18270@psf.upfronthosting.co.za>
Message-ID: <1375503084.79.0.476776348828.issue18270@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

No, but I recreated it from my description and attached it. But see next message.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31135/18270-27.diff

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

From report at bugs.python.org  Sat Aug  3 06:18:11 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 03 Aug 2013 04:18:11 +0000
Subject: [issue18574] BaseHTTPRequestHandler.handle_expect_100() sends invalid
	response
In-Reply-To: <1374971787.85.0.837580893432.issue18574@psf.upfronthosting.co.za>
Message-ID: <1375503491.75.0.467476360094.issue18574@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Sat Aug  3 06:21:36 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 03 Aug 2013 04:21:36 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1375503696.67.0.390887159285.issue16853@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

No time for a full review yet, but a comment on the timeout test failure you are observing in Tulip.  This particular test schedules a task that sleeps for 20 msecs, and first calls run_until_complete() with a timeout of 10 msecs, and then calls it again without a timeout.  It checks that the first call takes approximately 10 msec and the second call too.  But for some reason it is okay if the first call takes quite a bit longer (up to 18 msec) and then the second check is wrong.

Can you try again with the failing assert replaced with this?

	self.assertTrue(0.018 <= t2-t0 <= 0.028, t2-t0)

That should be a better way to check that code works.

----------

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

From report at bugs.python.org  Sat Aug  3 06:21:56 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 03 Aug 2013 04:21:56 +0000
Subject: [issue18575] Fixing tarfile._mode when using gzip via ":gz"
In-Reply-To: <1375000514.51.0.865237758651.issue18575@psf.upfronthosting.co.za>
Message-ID: <1375503716.85.0.576198709702.issue18575@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Sat Aug  3 06:40:14 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Aug 2013 04:40:14 +0000
Subject: [issue18270] IDLE on OS X fails with Attribute Error if no initial
	shell and Tk out-of-date
In-Reply-To: <1371739202.98.0.896833417364.issue18270@psf.upfronthosting.co.za>
Message-ID: <1375504814.07.0.394085346449.issue18270@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Looking further at handling debug, startup, cmd, or script options. When any of these are set, enable_shell is also, so to reach here, shell must be true, so only the MAC test, the subject of this issue, needs protection. Smaller patch (fewer lines changed) attached.

---
Not part of this issue, but if someone can explain ...:
This this bit under "if cmd or script:" puzzles me.
        shell.interp.runcommand("""if 1:
            import sys as _sys
            _sys.argv = %r
            del _sys
            \n""" % (sys.argv,))
Since the only lasting effect it can have is on the already imported sys module, it seems to be equivalent to
        sys.argv = "%r" % (sys.argv)
And I do not know what net effect that has, if anything.

----------
Added file: http://bugs.python.org/file31136/18270-27-B.diff

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

From report at bugs.python.org  Sat Aug  3 08:22:29 2013
From: report at bugs.python.org (Julien Nabet)
Date: Sat, 03 Aug 2013 06:22:29 +0000
Subject: [issue18521] [cppcheck] Full report
In-Reply-To: <1374408848.64.0.369654911435.issue18521@psf.upfronthosting.co.za>
Message-ID: <1375510948.99.0.253151104462.issue18521@psf.upfronthosting.co.za>


Julien Nabet added the comment:

Thank you for your feedback, you can close this tracker.

----------

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

From report at bugs.python.org  Sat Aug  3 09:29:57 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 03 Aug 2013 07:29:57 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375498939.37.0.636197500721.issue18606@psf.upfronthosting.co.za>
Message-ID: <51FCB160.9090303@pearwood.info>


Steven D'Aprano added the comment:

On 03/08/13 13:02, Alexander Belopolsky wrote:
>
> Alexander Belopolsky added the comment:
>
> Is there a reason why there is no "review" link?  Could it be because the file is uploaded as is rather than as a patch?

I cannot answer that question, sorry.

> In any case, I have a question about this code in sum:
>
>                  # Convert running total to a float. See comment below for
>                  # why we do it this way.
>                  total = type(total).__float__(total)
>
> The "comment below" says:
>
>              # Don't call float() directly, as that converts strings and we
>              # don't want that. Also, like all dunder methods, we should call
>              # __float__ on the class, not the instance.
>              x = type(x).__float__(x)
>
> but this reason does not apply to total that cannot be a string unless you add instances of a really weird class in which case all bets are off and the dunder method won't help much.

My reasoning was that total may be a string if the start parameter is a string, but of course I explicitly check the type of start. So I think you are right.

----------

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

From report at bugs.python.org  Sat Aug  3 10:18:14 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 03 Aug 2013 08:18:14 +0000
Subject: [issue18595] zipfile: symlinks etc.
In-Reply-To: <1375170318.76.0.496081120587.issue18595@psf.upfronthosting.co.za>
Message-ID: <1375517894.41.0.98354003175.issue18595@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

My initial plan was to add the patch soon after filing the issue, but that's before I noticed that this needs some API design to integrate nicely :-)

My current idea for the api:

* add "symlink(path, target") to write a symlink

* add "readlink(path)" to read a symlink

* "read" will raise an exception when trying to read a symlink
  (alternative: do symlink resolving, but that's too magical to my taste)
 
* "extract" and "extractall" extract the symlink as a symlink
  (but I'm not sure yet what to do on systems that don't support symlinks)

* with the various file types it might be better to also provide
  "islink(name)", "isdir(name)" and "isfile(name)" methods (simular to
  their os.path equivalents)

This will also require some changes to the ZipInfo class.

I'm not sure yet if adding support for device files and other unix attributes (UID/GID).

----------

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

From report at bugs.python.org  Sat Aug  3 10:30:53 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 03 Aug 2013 08:30:53 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1375518653.98.0.642731043115.issue18606@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

"Is there a reason why there is no 'review' link?  Could it be because the file is uploaded as is rather than as a patch?"

I think I can answer this question. The answer is yes. You can have "review" only if you use diff not raw file.

The original poster, Steven D'Aprano, uploaded the raw file instead of diff. To upload the new file as a diff, (assuming he is using mercurial) he can do something like this:

hg add Lib/statistics.py
hg diff Lib/statistics.py > /tmp/statistics_diff.patch

Then he can upload the statistics_diff.patch.

Of course, this is just my hypothetical guess.

----------
nosy: +vajrasky

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

From report at bugs.python.org  Sat Aug  3 11:21:57 2013
From: report at bugs.python.org (koobs)
Date: Sat, 03 Aug 2013 09:21:57 +0000
Subject: [issue16463] testConnectTimeout of test_timeout
	TCPTimeoutTestCasefailures fails intermittently
In-Reply-To: <1352757217.25.0.912881014186.issue16463@psf.upfronthosting.co.za>
Message-ID: <1375521717.44.0.543202970733.issue16463@psf.upfronthosting.co.za>


Changes by koobs <koobs.freebsd at gmail.com>:


----------
nosy: +koobs

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

From report at bugs.python.org  Sat Aug  3 11:30:40 2013
From: report at bugs.python.org (Phil Connell)
Date: Sat, 03 Aug 2013 09:30:40 +0000
Subject: [issue18566] In unittest.TestCase docs for setUp() and tearDown()
	don't mention AssertionError
In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za>
Message-ID: <1375522240.14.0.0356900597161.issue18566@psf.upfronthosting.co.za>


Changes by Phil Connell <pconnell at gmail.com>:


----------
nosy: +pconnell

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

From report at bugs.python.org  Sat Aug  3 11:34:45 2013
From: report at bugs.python.org (Phil Connell)
Date: Sat, 03 Aug 2013 09:34:45 +0000
Subject: [issue18594] C accelerator for collections.Counter is slow
In-Reply-To: <1375166960.42.0.521563124847.issue18594@psf.upfronthosting.co.za>
Message-ID: <1375522485.37.0.321775223672.issue18594@psf.upfronthosting.co.za>


Changes by Phil Connell <pconnell at gmail.com>:


----------
nosy: +pconnell

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

From report at bugs.python.org  Sat Aug  3 11:41:44 2013
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 03 Aug 2013 09:41:44 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1375522904.1.0.911295737544.issue11798@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <exarkun at twistedmatrix.com>:


----------
nosy:  -exarkun

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

From report at bugs.python.org  Sat Aug  3 11:43:09 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 03 Aug 2013 09:43:09 +0000
Subject: [issue18532] hashlib.HASH objects should officially expose the hash
	name
In-Reply-To: <1374524940.42.0.582552143445.issue18532@psf.upfronthosting.co.za>
Message-ID: <1375522988.99.0.101223106292.issue18532@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

It's not obvious to me if the authors originally intended to have the 'name' attribute as a formal interface, so I've decided the change should probably be added to Python 3.4. Here's a diff I've put together: http://paste.jaraco.com/tMdQ2

It updates the documentation and adds a test to guarantee the interface. I'm unsure about the RST syntax, so I would appreciate a review of the syntax there. Also, I haven't run the test yet, but I'll do that at a later date.

----------

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

From report at bugs.python.org  Sat Aug  3 11:43:46 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 03 Aug 2013 09:43:46 +0000
Subject: [issue18532] hashlib.HASH objects should officially expose the hash
	name
In-Reply-To: <1374524940.42.0.582552143445.issue18532@psf.upfronthosting.co.za>
Message-ID: <1375523026.38.0.847625289503.issue18532@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +needs review
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Aug  3 12:22:39 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 03 Aug 2013 10:22:39 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1375503696.67.0.390887159285.issue16853@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM30qe__hx5LEbzpD6XHpYcCy0Z5XbExUtCwXbYEJtCm3Q@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Guido van Rossum added the comment:
> Can you try again with the failing assert replaced with this?
>
> 	self.assertTrue(0.018 <= t2-t0 <= 0.028, t2-t0)
>
> That should be a better way to check that code works.

I'm still getting - less frequent - failures:
"""
======================================================================
FAIL: test_run_until_complete_timeout (events_test.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/events_test.py", line 194, in test_run_until_complete_timeout
    self.assertTrue(0.018 <= t2-t0 <= 0.028, t2-t0)
AssertionError: False is not true : 0.029771103999337356

----------------------------------------------------------------------
"""

Looking at strace output:
11:00:47.383145 select(4, [3], [], [], {0, 9765}) = 0 (Timeout) <0.015713>

select() takes an extra 5ms (15ms instead of 10ms).

5ms is quite low for a GPOS (the typical quantum is around 4ms for
250Hz timer, and on my machine I have high-resolution timers
configured but probably a crappy hardware).

I'd suggest increasing the timeouts (especially when Tulip gets
merged, it'll likely fail on many buildbots).

----------

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

From report at bugs.python.org  Sat Aug  3 12:31:43 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 03 Aug 2013 10:31:43 +0000
Subject: [issue10897] UNIX mmap unnecessarily dup() file descriptor
In-Reply-To: <1294845379.76.0.427887707002.issue10897@psf.upfronthosting.co.za>
Message-ID: <1375525903.82.0.707473239921.issue10897@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

> This can only be raised (above the hard limit) by a privileged
> process, so I would be out of luck there, as I could not convince
> my sysadmins to raise this further.

We all know that feeling :-)

> Meanwhile, I will just use my own module, so feel free to close
> this if you feel like it :)

OK, I'll close it then, since I don't see any satisfactory solution, and - until now - you've been the only user to get bitten.

Cheers.

----------
resolution:  -> wont fix
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Aug  3 12:44:31 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 03 Aug 2013 10:44:31 +0000
Subject: [issue16463] testConnectTimeout of test_timeout
	TCPTimeoutTestCasefailures fails intermittently
In-Reply-To: <1352757217.25.0.912881014186.issue16463@psf.upfronthosting.co.za>
Message-ID: <1375526671.33.0.700169554023.issue16463@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

The problem is that the test passes a DNS address to connect(), which means that it has to perform a name resolution first.
And since there's not timeout on gethostbyname()/getaddrinfo() you can end up well above the timeout.
The hostnames should be resolved beforehand.

----------
nosy: +neologix

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

From report at bugs.python.org  Sat Aug  3 12:48:08 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 03 Aug 2013 10:48:08 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375483672.39.0.318388706344.issue18629@psf.upfronthosting.co.za>
Message-ID: <51FCDFE1.3000108@egenix.com>


Marc-Andre Lemburg added the comment:

On 03.08.2013 00:47, Alexander Belopolsky wrote:
> 
> Alexander Belopolsky added the comment:
> 
>> Does a result of one and one half seconds make sense as the result of a floor division operation?
> 
> Yes.  Timedeltas behave as integers containing the number of microseconds:
> 
>>>> timedelta(microseconds=1) / 2
> datetime.timedelta(0)

I think that's a very obscure interpretation of floor division for
timedeltas :-)

IMO, floor division result should work on seconds, not microseconds.

----------

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

From mal at egenix.com  Sat Aug  3 12:48:01 2013
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat, 03 Aug 2013 12:48:01 +0200
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375483672.39.0.318388706344.issue18629@psf.upfronthosting.co.za>
References: <1375483672.39.0.318388706344.issue18629@psf.upfronthosting.co.za>
Message-ID: <51FCDFE1.3000108@egenix.com>

On 03.08.2013 00:47, Alexander Belopolsky wrote:
> 
> Alexander Belopolsky added the comment:
> 
>> Does a result of one and one half seconds make sense as the result of a floor division operation?
> 
> Yes.  Timedeltas behave as integers containing the number of microseconds:
> 
>>>> timedelta(microseconds=1) / 2
> datetime.timedelta(0)

I think that's a very obscure interpretation of floor division for
timedeltas :-)

IMO, floor division result should work on seconds, not microseconds.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Sat Aug  3 13:03:16 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Aug 2013 11:03:16 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375527796.29.0.652589645391.issue18629@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> I think that's a very obscure interpretation of floor division for
> timedeltas :-)

Agreed.

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

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

From report at bugs.python.org  Sat Aug  3 13:09:29 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Aug 2013 11:09:29 +0000
Subject: [issue18570] OverflowError in division: wrong message
In-Reply-To: <1374924685.41.0.945479313268.issue18570@psf.upfronthosting.co.za>
Message-ID: <1375528169.52.0.915993153799.issue18570@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Exception message fixed in revision dab7d6f33b87

----------

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

From report at bugs.python.org  Sat Aug  3 13:25:35 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 03 Aug 2013 11:25:35 +0000
Subject: [issue16463] testConnectTimeout of test_timeout
	TCPTimeoutTestCasefailures fails intermittently
In-Reply-To: <1375526671.33.0.700169554023.issue16463@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2pJMc8LC68iki0uqMnD5QT1O6Vi+ZhJ37mYg9qL93Lsw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

And here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file31137/connect_timeout.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16463>
_______________________________________
-------------- next part --------------
diff -r 1287d4c9cd39 Lib/test/test_timeout.py
--- a/Lib/test/test_timeout.py	Fri Aug 02 10:22:07 2013 +0200
+++ b/Lib/test/test_timeout.py	Sat Aug 03 13:19:24 2013 +0200
@@ -126,13 +126,23 @@
         self.assertLess(delta, timeout + self.fuzz)
         self.assertGreater(delta, timeout - 1.0)
 
+    def resolve_address(self, host, port):
+        """Resolve an (host, port) to an address.
+
+        We must perform name resolution before timeout tests, otherwise it will
+        be performed by connect().
+        """
+        with support.transient_internet(host):
+            return socket.getaddrinfo(host, port, socket.AF_INET,
+                                      socket.SOCK_STREAM)[0][4]
+
 
 class TCPTimeoutTestCase(TimeoutTestCase):
     """TCP test case for socket.socket() timeout functions"""
 
     def setUp(self):
         self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-        self.addr_remote = ('www.python.org.', 80)
+        self.addr_remote = self.resolve_address('www.python.org.', 80)
 
     def tearDown(self):
         self.sock.close()
@@ -142,7 +152,7 @@
         # to a host that silently drops our packets.  We can't simulate this
         # from Python because it's a function of the underlying TCP/IP stack.
         # So, the following Snakebite host has been defined:
-        blackhole = ('blackhole.snakebite.net', 56666)
+        blackhole = self.resolve_address('blackhole.snakebite.net', 56666)
 
         # Blackhole has been configured to silently drop any incoming packets.
         # No RSTs (for TCP) or ICMP UNREACH (for UDP/ICMP) will be sent back
@@ -154,7 +164,7 @@
         # to firewalling or general network configuration.  In order to improve
         # our confidence in testing the blackhole, a corresponding 'whitehole'
         # has also been set up using one port higher:
-        whitehole = ('whitehole.snakebite.net', 56667)
+        whitehole = self.resolve_address('whitehole.snakebite.net', 56667)
 
         # This address has been configured to immediately drop any incoming
         # packets as well, but it does it respectfully with regards to the

From report at bugs.python.org  Sat Aug  3 13:53:07 2013
From: report at bugs.python.org (Al Korgun)
Date: Sat, 03 Aug 2013 11:53:07 +0000
Subject: [issue18642] enhancement for operator 'assert'
Message-ID: <1375530787.73.0.318484624842.issue18642@psf.upfronthosting.co.za>


New submission from Al Korgun:

It would be pretty good, if 'assert' could raise specified exception, like that:

>>> data = None
>>> assert isinstance(data, basestring), TypeError("'data' must be a string")

<s>AssertionError</s>TypeError: 'data' must be a string

----------
components: Interpreter Core
messages: 194250
nosy: WitcherGeralt
priority: normal
severity: normal
status: open
title: enhancement for operator 'assert'
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sat Aug  3 14:07:10 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Aug 2013 12:07:10 +0000
Subject: [issue18642] enhancement for operator 'assert'
In-Reply-To: <1375530787.73.0.318484624842.issue18642@psf.upfronthosting.co.za>
Message-ID: <1375531630.05.0.324846148411.issue18642@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

What's wrong with:

if not isinstance(data, basestring):
    raise TypeError(...)

?

In any case, you appear to be wanting to use assert to check user input.  That's not its intended use;  instead, it's there for making debugging assertions.  Bear in mind that when running in optimized mode (with python -O), Python won't execute those asserts at all.  (See http://docs.python.org/3.4/reference/simple_stmts.html#the-assert-statement for more.)

I think this should be rejected.

----------
nosy: +mark.dickinson
versions: +Python 3.4 -Python 2.7

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

From report at bugs.python.org  Sat Aug  3 14:11:35 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 03 Aug 2013 12:11:35 +0000
Subject: [issue18643] implement socketpair() on Windows
Message-ID: <1375531895.31.0.501848123953.issue18643@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

socketpair() is quite useful, notably for tests.
Currently, it's not defined on Windows.
Since it's rather easy to implement, it would be nice to have it, if not in the stdlib, at least in test.support.

----------
components: Library (Lib)
messages: 194252
nosy: neologix, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: implement socketpair() on Windows
type: enhancement

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

From report at bugs.python.org  Sat Aug  3 14:45:44 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 03 Aug 2013 12:45:44 +0000
Subject: [issue18396] test_signal.test_issue9324() fails on buildbot AMD64
	Windows7 SP1 3.x
In-Reply-To: <1373208170.43.0.508048091983.issue18396@psf.upfronthosting.co.za>
Message-ID: <1375533944.84.0.73911843883.issue18396@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I checked the getsignal docs, and indeed None is the expected return value for "signal handler exists, but was not installed from Python". That's accurate given the way faulthandler works:

On Linux (Python 3.3.0):

$ python3 -c "import signal; print(signal.getsignal(signal.SIGSEGV))"
0
$ python3 -X faulthandler -c "import signal; print(signal.getsignal(signal.SIGSEGV))"
None

So Jeremy's patch looks correct to me - when faulthandler is enabled, we need to skip over the signals that have those handlers attached.

----------

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

From report at bugs.python.org  Sat Aug  3 14:57:32 2013
From: report at bugs.python.org (Chris Lambacher)
Date: Sat, 03 Aug 2013 12:57:32 +0000
Subject: [issue18635] Enum sets _member_type_ to instantiated values but not
	the class
In-Reply-To: <1375472056.62.0.564467694147.issue18635@psf.upfronthosting.co.za>
Message-ID: <1375534652.92.0.146277796903.issue18635@psf.upfronthosting.co.za>


Chris Lambacher added the comment:

My use case is a generic mixin for Enums and a generic mixin for Django ORM fields that uses the Enums to generate choices. 

The Enum mixin has to call cls.__class__._get_mixins_(cls.__bases__) to get the member_type so that it can call the member_type.__new__ method (currently using this for int and str). I'm currently setting _member_type_ on the class if it doesn't already exist in the Enum class.

The Django ORM field mixin has a to_python method where it is supposed to take input from the db/web and turn it into the python type (in this case an Enum). If we get a str from the web and we are going to an int, we need to run int on it. The generic way to do this in the mixin is to pass the value to _member_type_ as a function.

I think I have all the bugs out of my implementation so I should be able to extract it out of my app and make it open source this week.

----------

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

From report at bugs.python.org  Sat Aug  3 15:03:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Aug 2013 13:03:41 +0000
Subject: [issue18396] test_signal.test_issue9324() fails on buildbot AMD64
	Windows7 SP1 3.x
In-Reply-To: <1373208170.43.0.508048091983.issue18396@psf.upfronthosting.co.za>
Message-ID: <3c6lmX3VC2z7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset b7834800562f by Nick Coghlan in branch '3.3':
Close #18396: fix spurious test_signal failure on Windows
http://hg.python.org/cpython/rev/b7834800562f

New changeset 6fc71ed6a910 by Nick Coghlan in branch 'default':
Merge #18396 from 3.3
http://hg.python.org/cpython/rev/6fc71ed6a910

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

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

From report at bugs.python.org  Sat Aug  3 15:05:18 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 03 Aug 2013 13:05:18 +0000
Subject: [issue18396] test_signal.test_issue9324() fails on buildbot AMD64
	Windows7 SP1 3.x
In-Reply-To: <1373208170.43.0.508048091983.issue18396@psf.upfronthosting.co.za>
Message-ID: <1375535118.68.0.951787951687.issue18396@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I added one slight tweak to Jeremy's patch - an assertion to ensure that test loop is checking at least some* signals, even when faulthandler is enabled.

----------

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

From report at bugs.python.org  Sat Aug  3 15:18:09 2013
From: report at bugs.python.org (Al Korgun)
Date: Sat, 03 Aug 2013 13:18:09 +0000
Subject: [issue18642] enhancement for operator 'assert'
In-Reply-To: <1375530787.73.0.318484624842.issue18642@psf.upfronthosting.co.za>
Message-ID: <1375535889.51.0.540228108536.issue18642@psf.upfronthosting.co.za>


Al Korgun added the comment:

Mark Dickinson, and I just think it might be useful in debug. PYO is another story.

----------

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

From report at bugs.python.org  Sat Aug  3 15:31:31 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 03 Aug 2013 13:31:31 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1375536691.51.0.555057210352.issue15233@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Unless anyone objects, I'll backport it soonish.

----------
stage:  -> commit review

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

From report at bugs.python.org  Sat Aug  3 15:38:08 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 03 Aug 2013 13:38:08 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1375537088.29.0.787187267469.issue12015@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
keywords: +easy, needs review
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Sat Aug  3 15:40:07 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Aug 2013 13:40:07 +0000
Subject: [issue18642] enhancement for operator 'assert'
In-Reply-To: <1375530787.73.0.318484624842.issue18642@psf.upfronthosting.co.za>
Message-ID: <1375537207.25.0.0436984099259.issue18642@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Ah, so I think I don't understand the proposal.  In your original message,  is it your intention that the assert raises TypeError, or that it raises AssertionError?

Again:  what's the benefit over existing solutions?  Either:

    if not isinstance(data, basestring):
        raise TypeError("Bad user!  You gave me the wrong type")

or

    assert isinstance(data, basestring), "data should be a string at this point"

?

----------

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

From report at bugs.python.org  Sat Aug  3 15:45:19 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 03 Aug 2013 13:45:19 +0000
Subject: [issue18644] Got ResourceWarning: unclosed file when using test
	function from formatter module
Message-ID: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

This python is compiled with --with-pydebug option.

[sky at localhost cpython]$ cat /tmp/a.txt
manly man likes cute cat.
[sky at localhost cpython]$ ./python
Python 3.4.0a0 (default:e408e821d6c8, Jul 27 2013, 10:49:54) 
[GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from formatter import test
>>> test('/tmp/a.txt')
manly man likes cute cat.
__main__:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/a.txt' mode='r' encoding='UTF-8'>
>>> 
[sky at localhost cpython]$ ./python Lib/formatter.py /tmp/a.txt
manly man likes cute cat.
Lib/formatter.py:445: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/a.txt' mode='r' encoding='UTF-8'>
  test()

----------
components: Tests
files: formatter_fix_resource_warning.patch
keywords: patch
messages: 194260
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Got ResourceWarning: unclosed file when using test function from formatter module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file31138/formatter_fix_resource_warning.patch

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

From report at bugs.python.org  Sat Aug  3 15:51:15 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 03 Aug 2013 13:51:15 +0000
Subject: [issue18644] Got ResourceWarning: unclosed file when using test
	function from formatter module
In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za>
Message-ID: <1375537875.72.0.0276940387566.issue18644@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Sorry, I forgot about stdin. Attached the patch to handle stdin gracefully.

----------
Added file: http://bugs.python.org/file31139/formatter_fix_resource_warning_v2.patch

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

From report at bugs.python.org  Sat Aug  3 16:04:02 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 03 Aug 2013 14:04:02 +0000
Subject: [issue18644] Got ResourceWarning: unclosed file when using test
	function from formatter module
In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za>
Message-ID: <1375538642.37.0.997857054625.issue18644@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

I guess I should not close stdin just in case people are using test function in the script.

Attached the patch to only close the open files not stdin.

----------
Added file: http://bugs.python.org/file31140/formatter_fix_resource_warning_v3.patch

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

From report at bugs.python.org  Sat Aug  3 16:15:41 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Aug 2013 14:15:41 +0000
Subject: [issue18642] enhancement for operator 'assert'
In-Reply-To: <1375530787.73.0.318484624842.issue18642@psf.upfronthosting.co.za>
Message-ID: <1375539341.68.0.629037081423.issue18642@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think it would be confusing for assert to raise anything other than an AssertionError, so I also think this should be rejected.

It might be interesting for there to be a way to call unittest's assert methods in a debug context (that is, without having to have a test case around), but that is a very non-trivial (and probably impractical) thought :)

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

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

From report at bugs.python.org  Sat Aug  3 16:30:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Aug 2013 14:30:58 +0000
Subject: [issue18595] zipfile: symlinks etc.
In-Reply-To: <1375170318.76.0.496081120587.issue18595@psf.upfronthosting.co.za>
Message-ID: <1375540258.46.0.150687603014.issue18595@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> * "read" will raise an exception when trying to read a symlink
>  (alternative: do symlink resolving, but that's too magical to my taste)

And perhaps when trying to read a directory entry too.

> * "extract" and "extractall" extract the symlink as a symlink
>  (but I'm not sure yet what to do on systems that don't support symlinks)

What the tar module do?

> * with the various file types it might be better to also provide
>  "islink(name)", "isdir(name)" and "isfile(name)" methods (simular to
>  their os.path equivalents)

Or rather as methods of the ZipInfo object. See TarInfo.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sat Aug  3 16:44:26 2013
From: report at bugs.python.org (Martijn Pieters)
Date: Sat, 03 Aug 2013 14:44:26 +0000
Subject: [issue18644] Got ResourceWarning: unclosed file when using test
	function from formatter module
In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za>
Message-ID: <1375541066.29.0.757166721614.issue18644@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

Why is the `formatter` module still part of Python 3? This was a dependency for the `htmllib` module in Python 2 only, and that module was deprecated and removed from Python 3.

----------
nosy: +mjpieters

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

From report at bugs.python.org  Sat Aug  3 16:46:39 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 03 Aug 2013 14:46:39 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375541199.66.0.46278775258.issue18264@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Eli, your method is good.  I thought I had tried something similar but I obviously had the wrong PyLong constructor.

I'll get it implemented.

----------

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

From report at bugs.python.org  Sat Aug  3 17:33:59 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 03 Aug 2013 15:33:59 +0000
Subject: [issue18624] Add alias for iso-8859-8-i which is the same as
	iso-8859-8
In-Reply-To: <1375454262.69.0.534466060897.issue18624@psf.upfronthosting.co.za>
Message-ID: <51FD22DE.6030807@egenix.com>


Marc-Andre Lemburg added the comment:

On 02.08.2013 16:37, R. David Murray wrote:
> 
> I got the impression from what I read that -e included additional control sequences, but perhaps I misunderstood and that only meant that the data stream was expected to *use* additional control sequences but the control codes themselves are part of the base codec?
> 
> I'm specifically thinking of this statement from the linked reference:
> 
> "Because HTML uses the Unicode bidirectionality algorithm, conforming documents encoded using ISO 8859-8 must be labeled as "ISO-8859-8-i". Explicit directional control is also possible with HTML, but cannot be expressed with ISO 8859-8, so "ISO-8859-8-e" should not be used."
> 
> The "cannot be expressed" seems to imply there are differences in the codec.

No, not really. After some more research, I found that the -i and
-e suffixes are defined in RFC 1556:

http://tools.ietf.org/html/rfc1556

At the codec level, these encodings are all the same. The suffixes
define whether or not to interpret some of their control characters
with respect to bidi text when visualizing the text.

----------

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

From report at bugs.python.org  Sat Aug  3 18:17:33 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Aug 2013 16:17:33 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1375546653.21.0.0671070956824.issue11798@psf.upfronthosting.co.za>


R. David Murray added the comment:

Terry: I would not be in favor of using the normal iter, since iterating a collection doesn't normally empty it, and there may be tools that iterate a test suite outside of test execution.  Adding a pop_iter method would be a backward compatibility issue, since "replacement" test suites would not have that method.  I think the current patch is the best bet for maintaining backward compatibility.

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

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

From report at bugs.python.org  Sat Aug  3 18:19:56 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 03 Aug 2013 16:19:56 +0000
Subject: [issue18296] test_os.test_trailers() is failing on AMD64 FreeBSD 9.0
	dtrace 3.x
In-Reply-To: <1372119942.09.0.162654139201.issue18296@psf.upfronthosting.co.za>
Message-ID: <1375546796.57.0.00769754560912.issue18296@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

The test shouldn't pass 4096 as nbytes: apparently, recent FreeBSD kernels zero-fill.

----------
nosy: +neologix

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

From report at bugs.python.org  Sat Aug  3 18:31:37 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Aug 2013 16:31:37 +0000
Subject: [issue17998] internal error in regular expression engine
In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za>
Message-ID: <3c6rNS1rN8zND8@mail.python.org>


Roundup Robot added the comment:

New changeset 86b8b035529b by Serhiy Storchaka in branch '3.3':
Issue #17998: Fix an internal error in regular expression engine.
http://hg.python.org/cpython/rev/86b8b035529b

New changeset 36702442ffe0 by Serhiy Storchaka in branch 'default':
Issue #17998: Fix an internal error in regular expression engine.
http://hg.python.org/cpython/rev/36702442ffe0

New changeset e5e425fd1e4f by Serhiy Storchaka in branch '2.7':
Issue #17998: Fix an internal error in regular expression engine.
http://hg.python.org/cpython/rev/e5e425fd1e4f

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Aug  3 18:32:10 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Aug 2013 16:32:10 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375547530.36.0.773109260979.issue18629@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

What is so special about seconds?  Why not days? As in

>>> timedelta(3) // 2
timedelta(1)


Note that in 3.x we have timedelta over timedelta division that lets you do floor division in arbitrary time units.

What is the use case for timedelta // int that rounds down to a second?  I suspect in most cases you really want timedelta // timedelta(seconds=int) instead.

----------

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

From report at bugs.python.org  Sat Aug  3 18:36:18 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Aug 2013 16:36:18 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375547778.47.0.626883478405.issue18629@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I'm not sure I see a use-case for timedelta // int at all.  To make sense of that, you first need some way to make sense of floor(timedelta), and as you say it's not clear what that should mean:  number of seconds?  number of days?  Either of those would seem more natural than number of microseconds, though.

timedelta // timedelta and timedelta / int on the other hand have an obvious meaning.

----------

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

From report at bugs.python.org  Sat Aug  3 18:39:45 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Aug 2013 16:39:45 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375547985.45.0.720415387332.issue18629@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

-1 on changing the behaviour in 2.7, though;  I think it's far too late for that.

----------

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

From report at bugs.python.org  Sat Aug  3 18:43:50 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 03 Aug 2013 16:43:50 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375547530.36.0.773109260979.issue18629@psf.upfronthosting.co.za>
Message-ID: <51FD333E.7010400@egenix.com>


Marc-Andre Lemburg added the comment:

On 03.08.2013 18:32, Alexander Belopolsky wrote:
> 
> Alexander Belopolsky added the comment:
> 
> What is so special about seconds?  Why not days? As in
> 
>>>> timedelta(3) // 2
> timedelta(1)
> 
> 
> Note that in 3.x we have timedelta over timedelta division that lets you do floor division in arbitrary time units.
> 
> What is the use case for timedelta // int that rounds down to a second?  I suspect in most cases you really want timedelta // timedelta(seconds=int) instead.

The notion of fraction in time usually applies to seconds, not
days, hours or minutes. Since floor removes fractions, the natural
expectation is to have // int apply to seconds, not microseconds
(which represent fractions of a second).

That said, I don't think having // division on timedeltas is useful
at all. I'd be +1 on removing this support and raise a TypeError
instead.

----------

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

From report at bugs.python.org  Sat Aug  3 19:30:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Aug 2013 17:30:51 +0000
Subject: [issue17998] internal error in regular expression engine
In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za>
Message-ID: <1375551051.28.0.843524148904.issue17998@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry for the delay. I have committed a simple patch which fixes this bug. But I don't close the issue still because there are other related issues.

----------

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

From report at bugs.python.org  Sat Aug  3 19:39:59 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Aug 2013 17:39:59 +0000
Subject: [issue17998] internal error in regular expression engine
In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za>
Message-ID: <1375551599.07.0.356100697633.issue17998@psf.upfronthosting.co.za>


R. David Murray added the comment:

This appears to have turned the buildbots red.

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

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

From report at bugs.python.org  Sat Aug  3 19:44:39 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 03 Aug 2013 17:44:39 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375551879.77.0.26001855626.issue18629@psf.upfronthosting.co.za>


Tim Peters added the comment:

Well, a timedelta is a duration.  timedelta // n is as close as possible to one n'th of that duration, but "rounding down" (if necessary) so that the result is representable as a timedelta.  In the same way, if i and j are integers, i // j is as close as possible to one j'th of i, but "rounding down" (if necessary) so that the result is representable as an integer.  Like:

>>> from datetime import timedelta
>>> timedelta(1) // 7
datetime.timedelta(0, 12342, 857142)
>>> timedelta(1) - 7 * _
datetime.timedelta(0, 0, 6)
>>>

The last line shows the part truncated away:  one seventh of a day is not representable as a timedetla. If `timedelta // int` rounded to the closest representable timedelta, it would return timedelta(0, 12342, 857143) instead.  That's a little bigger than a seventh of a day:

>>> timedelta(0, 12342, 857143) * 7
datetime.timedelta(1, 0, 1)

It has nothing directly to do with days, hours, seconds ... it so happens that timedelta has microsecond resolution, so the closest representable approximations to one n'th of a timedelta most often have non-zero microsecond components.  If timedelta had femtosecond resolution, they'd most often have non-zero femtosecond components ;-)

----------
nosy: +tim_one

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

From report at bugs.python.org  Sat Aug  3 19:50:54 2013
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 03 Aug 2013 17:50:54 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375552254.26.0.949469155399.issue18629@psf.upfronthosting.co.za>


Jean-Paul Calderone added the comment:

> I think that's a very obscure interpretation of floor division for
timedeltas :-)

Note - I don't care about this.  I just want `timedelta / int` to do the same thing in Python 2.7 with __future__.division as `timedelta / int` does in Python 3.

Please don't reject this because of some unrelated discussion about how floor division should be implemented for timedelta.

----------

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

From report at bugs.python.org  Sat Aug  3 20:13:39 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Aug 2013 18:13:39 +0000
Subject: [issue16067] UAC prompt for installation shows temporary file name
In-Reply-To: <1348796990.29.0.204354546612.issue16067@psf.upfronthosting.co.za>
Message-ID: <3c6tfB268JzPsH@mail.python.org>


Roundup Robot added the comment:

New changeset 797b1d13d16e by Martin v. L?wis in branch '3.3':
Issue #16067: Add description into MSI file to replace installer's temporary name.
http://hg.python.org/cpython/rev/797b1d13d16e

New changeset 7d661f47f73b by Martin v. L?wis in branch 'default':
Issue #16067: Merge with 3.3
http://hg.python.org/cpython/rev/7d661f47f73b

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Aug  3 20:19:06 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 03 Aug 2013 18:19:06 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375553946.9.0.369864291532.issue18264@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Yes, AFAIU PyNumber_Long is the equivalent of Python-level int(obj). With other constructors of PyLong you are limited by long long (while Python integers may be arbitrarily large).

Ethan - If you're still short on time I can pretty up this patch and put it for review with some tests. Let me know what you prefer.

----------

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

From report at bugs.python.org  Sat Aug  3 20:19:22 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Aug 2013 18:19:22 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375553962.15.0.974596598789.issue18629@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

There are two schools of thought here.  One school (MAL and Mark) thinks of durations as real number of seconds.  The other school (Tim and I) think of durations as integer number of resolution intervals.  This is why I and Tim before me resisted adding true division of timedelta by a number and multiplication of timedelta by a float.  Mark prevailed on that issue (see #1289118.)  His expertise in floating point computing certainly helped designing and implementing these operations correctly.  We still have a small quirk waiting to be ironed out (see #8860), but overall I am happy with the current state.

This said, the datetime module carries a long legacy of being a pure integer arithmetics in a funny variable-radix notation.  We can disagree on the utility of floor division as it is currently defined, but we cannot remove or change it in an incompatible way.

----------

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

From report at bugs.python.org  Sat Aug  3 20:20:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Aug 2013 18:20:47 +0000
Subject: [issue16741] `int()`, `float()`,
	etc think python strings are null-terminated
In-Reply-To: <1356046641.74.0.314140910069.issue16741@psf.upfronthosting.co.za>
Message-ID: <3c6tpQ3hZSzRN6@mail.python.org>


Roundup Robot added the comment:

New changeset ecc8512b427d by Serhiy Storchaka in branch '3.3':
Issue #16741: Fix an error reporting in int().
http://hg.python.org/cpython/rev/ecc8512b427d

New changeset 4fd48a807812 by Serhiy Storchaka in branch 'default':
Issue #16741: Fix an error reporting in int().
http://hg.python.org/cpython/rev/4fd48a807812

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Aug  3 20:21:52 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 03 Aug 2013 18:21:52 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375554112.04.0.23010670019.issue18264@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thanks for the offer, Eli, but I almost have the tests done.  :)

----------

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

From report at bugs.python.org  Sat Aug  3 20:24:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Aug 2013 18:24:41 +0000
Subject: [issue16067] UAC prompt for installation shows temporary file name
In-Reply-To: <1348796990.29.0.204354546612.issue16067@psf.upfronthosting.co.za>
Message-ID: <3c6ttx0wdJzS0x@mail.python.org>


Roundup Robot added the comment:

New changeset ee0bdc007a0f by Martin v. L?wis in branch '2.7':
Issue #16067: Add description into MSI file to replace installer's temporary name.
http://hg.python.org/cpython/rev/ee0bdc007a0f

----------

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

From report at bugs.python.org  Sat Aug  3 20:25:30 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 03 Aug 2013 18:25:30 +0000
Subject: [issue16067] UAC prompt for installation shows temporary file name
In-Reply-To: <1348796990.29.0.204354546612.issue16067@psf.upfronthosting.co.za>
Message-ID: <1375554330.04.0.938668422659.issue16067@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Thanks for the report. This is now fixed on the active branches.

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Aug  3 20:29:35 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 03 Aug 2013 18:29:35 +0000
Subject: [issue17998] internal error in regular expression engine
In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za>
Message-ID: <1375554575.39.0.249918694509.issue17998@psf.upfronthosting.co.za>


Larry Hastings added the comment:

This broke the test suite on all the 32-bit Linux buildbots.  Sample output is here:

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/8349/steps/test/logs/stdio

There's no obvious fix, and I want to cut 3.4a1 right about now, so I'm going to tag the version in trunk just before this checkin.

----------

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

From report at bugs.python.org  Sat Aug  3 20:33:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Aug 2013 18:33:00 +0000
Subject: [issue16741] `int()`, `float()`,
	etc think python strings are null-terminated
In-Reply-To: <1356046641.74.0.314140910069.issue16741@psf.upfronthosting.co.za>
Message-ID: <1375554780.74.0.253558087612.issue16741@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


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

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

From report at bugs.python.org  Sat Aug  3 20:35:51 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Aug 2013 18:35:51 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375554951.53.0.451762339009.issue18629@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> I just want `timedelta / int` to do the same thing in Python 2.7
> with __future__.division as `timedelta / int` does in Python 3.

It other words you want to backport timedelta / int true division.  I am afraid it is 3-4 years too late for this request, but I will let others make a call.  Count me as -0.

I usually prefer explicit error over an obscure bug.  If we backport true division the -Qnew flag will be changing the meaning of timedelta / int very slightly: instead of rounding down it will round to nearest.  There are cases where this difference is important.  Furthemore, when people compare timedeltas in tests they rarely do it with precision tolerance.  If you have a good test coverage change from floor to true division may break your tests.

My recommendation is: replace timedelta / int with timedelta // int in your 2.x code.

----------

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

From report at bugs.python.org  Sat Aug  3 20:45:09 2013
From: report at bugs.python.org (Al Korgun)
Date: Sat, 03 Aug 2013 18:45:09 +0000
Subject: [issue18642] enhancement for operator 'assert'
In-Reply-To: <1375530787.73.0.318484624842.issue18642@psf.upfronthosting.co.za>
Message-ID: <1375555509.25.0.525627652174.issue18642@psf.upfronthosting.co.za>


Al Korgun added the comment:

Mark Dickinson, #1 if dedug (and type check, respectively, as in this example, and 'raise') isn't needed we just need pyo
>> Python won't execute those asserts at all
that is convenient.

if not isinstance(data, basestring):
    raise TypeError(...)

- here we need additionally check debug variable, use wrapper or something.
#2 'assert' is a good breakpoint (sorry, bad english. not sure if this is what I wanted to say) on its own. And to orientate on check & 'raise' we have to mark it somehow.
#3 Well, the code is shorter, obviously.

R. David Murray, yes, maybe confusing, but I can imagine many ways when it is very convenient.

----------

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

From report at bugs.python.org  Sat Aug  3 20:58:04 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 03 Aug 2013 18:58:04 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375556284.55.0.153559485607.issue18264@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Okay, patch attached with C code (thanks, Eli!), more python code, and some new tests.

Only the `int` case is handled.

----------
Added file: http://bugs.python.org/file31141/issue18264.stoneleaf.01.patch

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

From report at bugs.python.org  Sat Aug  3 20:59:34 2013
From: report at bugs.python.org (Al Korgun)
Date: Sat, 03 Aug 2013 18:59:34 +0000
Subject: [issue18642] enhancement for operator 'assert'
In-Reply-To: <1375530787.73.0.318484624842.issue18642@psf.upfronthosting.co.za>
Message-ID: <1375556374.81.0.22615279146.issue18642@psf.upfronthosting.co.za>


Al Korgun added the comment:

Mark Dickinson, sorry, didn't answer the first questiuon.
>> In your original message,  is it your intention that the assert raises TypeError, or that it raises AssertionError?

I suggest to add the ability to raise relevant (for specific part of code) exception on checking assertion.

----------

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

From report at bugs.python.org  Sat Aug  3 21:02:15 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Aug 2013 19:02:15 +0000
Subject: [issue18570] OverflowError in division: wrong message
In-Reply-To: <1374924685.41.0.945479313268.issue18570@psf.upfronthosting.co.za>
Message-ID: <1375556535.32.0.423870214607.issue18570@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

With that fixed, I am inclined to close this.

----------

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

From report at bugs.python.org  Sat Aug  3 21:05:24 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 03 Aug 2013 19:05:24 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1375556724.19.0.569495933091.issue18606@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

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

From report at bugs.python.org  Sat Aug  3 21:09:30 2013
From: report at bugs.python.org (mrDoctorWho0 .)
Date: Sat, 03 Aug 2013 19:09:30 +0000
Subject: [issue18642] enhancement for operator 'assert'
In-Reply-To: <1375530787.73.0.318484624842.issue18642@psf.upfronthosting.co.za>
Message-ID: <1375556970.0.0.908420024544.issue18642@psf.upfronthosting.co.za>


mrDoctorWho0 . added the comment:

Assert with this feature will make code simplest. Simplification isn't python way? Why don't add it in python? It's must be really useful. Sometimes its necessary, when need to catch specified exception. Its easier to search errors by type, not by error body

----------
nosy: +mrDoctorWho0..

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

From report at bugs.python.org  Sat Aug  3 21:31:26 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Aug 2013 19:31:26 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1375558286.11.0.0812868181552.issue18606@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Here is the use-case that was presented to support adding additional operations on timedelta objects:

"""
I'm conducting a series of observation experiments where I
measure the duration of an event.  I then want to do various
statistical analysis such as computing the mean, median,
etc.  Originally, I tried using standard functions such as
lmean from the stats.py package.  However, these sorts of
functions divide by a float at the end, causing them to fail
on timedelta objects.  Thus, I have to either write my own
special functions, or convert the timedelta objects to
integers first (then convert them back afterwards).
"""  (Daniel Stutzbach, in msg26267 on issue1289118.)

The proposed statistics module does not support this use case:

>>> mean([timedelta(1)])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/sasha/Work/cpython-ro/Lib/statistics.py", line 387, in mean
    total = sum(data)
  File "/Users/sasha/Work/cpython-ro/Lib/statistics.py", line 223, in sum
    total += x
TypeError: unsupported operand type(s) for +=: 'int' and 'datetime.timedelta'
>>> sum([timedelta(1)], timedelta(0))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/sasha/Work/cpython-ro/Lib/statistics.py", line 210, in sum
    raise TypeError('sum only accepts numbers')
TypeError: sum only accepts numbers

----------
nosy: +agthorr

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

From report at bugs.python.org  Sat Aug  3 21:54:24 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Aug 2013 19:54:24 +0000
Subject: [issue18642] enhancement for operator 'assert'
In-Reply-To: <1375530787.73.0.318484624842.issue18642@psf.upfronthosting.co.za>
Message-ID: <1375559664.67.0.174720682228.issue18642@psf.upfronthosting.co.za>


R. David Murray added the comment:

If your code is catching an exception generated by an assert statement, your code is using assert incorrectly.  There is never any reason, as far as I can see, to catch an assert outside of a testing framework, and in a testing framework you definitely want to be catching an AssertionError when you are trying to catch an assert failing.  Making it some other error would just confuse the testing framework.

----------

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

From report at bugs.python.org  Sat Aug  3 22:41:43 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 03 Aug 2013 20:41:43 +0000
Subject: [issue18645] Add a configure option for performance guided
	optimization
Message-ID: <1375562503.45.0.752070512413.issue18645@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

We can make it easier for users make custom, high-performance builds tailored to their actual use cases.

Here's an example of how Firefox does it:

https://developer.mozilla.org/en-US/docs/Building_with_Profile-Guided_Optimization

----------
components: Build
messages: 194295
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add a configure option for performance guided optimization
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Aug  3 22:42:06 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Aug 2013 20:42:06 +0000
Subject: [issue18646] Improve tutorial entry on 'Lambda Forms'.
Message-ID: <1375562526.59.0.207872880438.issue18646@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

[0. On mailing lists, 'lambda expression' is used rather than 'lambda form'. Docs use both. Consistency across docs is a broader issue than this one. So leave title alone for this one.]

1. (first sentence) "By popular demand, a few features commonly found in functional programming languages like Lisp have been added to Python." (in early Python 1!) I think this should just be deleted. See 4. below as a replacement.

2. " With the lambda keyword, small anonymous functions can be created."
Change to
"Small anonymous functions can be created with the lambda keyword."

3. change "Here?s a function that returns" to "This function returns"

3.5 add a sentence about the different between def and lambda (the name attribute.

4. Add sentences about the purposes of lambda. Add an example that illustrates passing functions. 

>>> pairs = [(1, 'one'), (2, 'two'), (3, 'three'), (4, 'four')]
>>> pairs.sort(key=lambda pair: pair[1])
>>> pairs
[(4, 'four'), (1, 'one'), (3, 'three'), (2, 'two')]

----------
assignee: docs at python
components: Documentation
files: tut-lambda.diff
keywords: patch
messages: 194296
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Improve tutorial entry on 'Lambda Forms'.
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31142/tut-lambda.diff

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

From report at bugs.python.org  Sat Aug  3 22:42:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Aug 2013 20:42:07 +0000
Subject: [issue18647] re.error: nothing to repeat
Message-ID: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Now all doctests failed on 32-bit platforms due to the unlucky coincidence of my patch with at least two bugs which were hided before.

SubPattern.getwidth() is wrong, it truncates resulted values to sys.maxsize (should be MAXREPEAT). As side effect of my patch (on 32-bit MAXREPEAT == sys.maxsize) it now returns correct value in some cases on 32-bit platforms. On other hand, the _simple() function in sre_compile.py checks if getwidth() returns (0, MAXREPEAT) and raise an error in such case. Perhaps it should guards against such patterns as '(x*)*' (but it doesn't guards against '(x*y?)*' or '(x*y*)*' and can raise false positive). Now getwidth() returns (0, MAXREPEAT) for '(x*y?)*' on 32-bit platforms (this is a correct result) and triggers the check. The doctest module uses regular expression pattern '(?:.*$\n?)*' which now causes an error.

Definitely SubPattern.getwidth() is wrong and should be fixed. At least one of two, the _simple() function or doctest pattern should be fixed too. The simplest fix is disable the 'nothing to repeat' check.

----------
assignee: serhiy.storchaka
components: Library (Lib), Regular Expressions
messages: 194297
nosy: ezio.melotti, larry, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: re.error: nothing to repeat
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Aug  3 22:48:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Aug 2013 20:48:44 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <3c6y576Rd7zRky@mail.python.org>


Roundup Robot added the comment:

New changeset c243896e12be by Serhiy Storchaka in branch '3.3':
Issue #18647: Temporary disable the "nothing to repeat" check to make buildbots happy.
http://hg.python.org/cpython/rev/c243896e12be

New changeset 4faf9b73c3df by Serhiy Storchaka in branch 'default':
Issue #18647: Temporary disable the "nothing to repeat" check to make buildbots happy.
http://hg.python.org/cpython/rev/4faf9b73c3df

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Aug  3 22:50:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Aug 2013 20:50:35 +0000
Subject: [issue17998] internal error in regular expression engine
In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za>
Message-ID: <1375563035.64.0.539202997971.issue17998@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See issue18647.

----------

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

From report at bugs.python.org  Sat Aug  3 22:50:42 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 03 Aug 2013 20:50:42 +0000
Subject: [issue18635] Enum sets _member_type_ to instantiated values but not
	the class
In-Reply-To: <1375472056.62.0.564467694147.issue18635@psf.upfronthosting.co.za>
Message-ID: <1375563042.12.0.385781082655.issue18635@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Well, aside from not having a clue as to what Chris is trying to do, should we make _member_type_ public?  The only reason I put it there was to aid introspection -- Enum does not use it.

----------

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

From report at bugs.python.org  Sat Aug  3 22:55:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Aug 2013 20:55:24 +0000
Subject: [issue17119] Integer overflow when passing large string or tuple to
	Tkinter
In-Reply-To: <1359920139.05.0.774798858282.issue17119@psf.upfronthosting.co.za>
Message-ID: <1375563324.47.0.177895146654.issue17119@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

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

From report at bugs.python.org  Sat Aug  3 22:58:16 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Aug 2013 20:58:16 +0000
Subject: [issue18648] FP Howto and the PEP 8 lambda guildline
Message-ID: <1375563496.73.0.458556999556.issue18648@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Functional Programming HowTo, near the end, has a section
Small functions and the lambda expression
http://docs.python.org/3/howto/functional.html#small-functions-and-the-lambda-expression

To illustrate, it starts with
  adder = lambda x, y: x+y
  print_assign = lambda name, value: name + '=' + str(value)
which are now proscribed by PEP 8. "Always use a def statement instead of an assignment statement that binds a lambda expression directly to a name."

The text goes on to give the def equivalents and to discourage lambdas. "Which alternative is preferable? That?s a style question; my usual course is to avoid using lambda." But I think the section should instead start with lambda examples that would be acceptable in the stdlib.

----------
messages: 194301
nosy: akuchling, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: FP Howto and the PEP 8 lambda guildline
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Aug  3 23:00:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Aug 2013 21:00:15 +0000
Subject: [issue17478] Tkinter's split() inconsistent for bytes and unicode
	strings
In-Reply-To: <1363683519.76.0.514671428108.issue17478@psf.upfronthosting.co.za>
Message-ID: <1375563615.52.0.782071067049.issue17478@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Tk.split() doesn't work with nested Unicode strings

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

From report at bugs.python.org  Sat Aug  3 23:16:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Aug 2013 21:16:13 +0000
Subject: [issue16741] `int()`, `float()`,
	etc think python strings are null-terminated
In-Reply-To: <1356046641.74.0.314140910069.issue16741@psf.upfronthosting.co.za>
Message-ID: <1375564573.11.0.228128147446.issue16741@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is a test in test_unicode which expects an UnicodeError for int('\ud800'). Now it fails. Should we fix a test or int()?

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

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

From report at bugs.python.org  Sat Aug  3 23:23:28 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Aug 2013 21:23:28 +0000
Subject: [issue18629] future division breaks timedelta division by integer
In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>
Message-ID: <1375565008.8.0.000373272390575.issue18629@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

This issue is effectively a duplicate #1083 (see msg101281.)

----------

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

From report at bugs.python.org  Sat Aug  3 23:45:20 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Aug 2013 21:45:20 +0000
Subject: [issue16741] `int()`, `float()`,
	etc think python strings are null-terminated
In-Reply-To: <1356046641.74.0.314140910069.issue16741@psf.upfronthosting.co.za>
Message-ID: <1375566320.36.0.894957975592.issue16741@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I'd say fix the test.  Raising ValueError is correct in this case.  UnicodeError was an implementation artifact.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Sat Aug  3 23:48:31 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 03 Aug 2013 21:48:31 +0000
Subject: [issue18635] Enum sets _member_type_ to instantiated values but not
	the class
In-Reply-To: <1375472056.62.0.564467694147.issue18635@psf.upfronthosting.co.za>
Message-ID: <1375566511.26.0.569723652717.issue18635@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

-1 on making more internals public.

----------

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

From report at bugs.python.org  Sun Aug  4 00:00:28 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 03 Aug 2013 22:00:28 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375567228.62.0.278053355757.issue18264@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Posted a Rietveld code review

----------

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

From report at bugs.python.org  Sun Aug  4 00:00:42 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sat, 03 Aug 2013 22:00:42 +0000
Subject: [issue18649] list2cmdline function in subprocess module handles \"
	sequence wrong
Message-ID: <1375567242.02.0.673942606159.issue18649@psf.upfronthosting.co.za>


New submission from Piotr Dobrogost:

According to the docstring of list2cmdline function in subprocess module the sequence of a backslash followed by a double quote mark should denote double quote mark in the output string. However it's not the case

Python 2.7.4 (default, Apr  6 2013, 19:55:15) [MSC v.1500 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import subprocess
    >>> print subprocess.list2cmdline(r'\"1|2\"')
    \ \" 1 | 2 \ \"

The same behavior is in Python 3.3.1.

See "On Windows, how can I protect arguments to shell scripts using Python 2.7 subprocess?"(http://stackoverflow.com/q/4970194/95735) question on Stack Overflow.

----------
components: Library (Lib)
messages: 194307
nosy: Arve.Knudsen, exarkun, piotr.dobrogost, r.david.murray
priority: normal
severity: normal
status: open
title: list2cmdline function in subprocess module handles \" sequence wrong
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Aug  4 00:03:09 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Aug 2013 22:03:09 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1375567389.85.0.948369301117.issue8860@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I cleaned up the patch a little:

1. Removed now unused static round_to_long() function.
2. Removed commented out code.

Mark,

Any reason not to apply this?  Do we need a NEWS entry for something like this?

----------
priority: low -> normal
stage: test needed -> commit review
versions: +Python 3.4 -Python 3.2
Added file: http://bugs.python.org/file31143/issue8860a.patch

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

From report at bugs.python.org  Sun Aug  4 00:06:03 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Aug 2013 22:06:03 +0000
Subject: [issue18650] intermittent test_pydoc failure on 3.4.0a1
Message-ID: <1375567563.7.0.0482703899635.issue18650@psf.upfronthosting.co.za>


New submission from Ned Deily:

Testing the 3.4.0a1 OS X 10.6 installer on OS X 10.8, I've now seen test_pydoc fail twice when the tests are run in order but then passing when the test is automatically rerun.  I've not seen this failure previously.

/usr/local/bin/python3.4 -m test -w -uall,-largefile== CPython 3.4.0a1 (v3.4.0a1:46535f65e7f3, Aug 3 2013, 14:03:34) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
==   Darwin-12.5.0-x86_64-i386-32bit little-endian
==   /private/var/folders/42/hjgpmmxd2wbcrzh4r9vsk_6h0000gr/T/test_python_3742
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)
[  1/376] test_grammar
...
[250/376] test_pyclbr
[251/376] test_pydoc
test test_pydoc failed -- Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/test_pydoc.py", line 624, in test_url_requests
    self.assertEqual(result, title, text)
AssertionError: 'Pydoc: Error - ' != 'Pydoc: Index of Modules'
- Pydoc: Error -
+ Pydoc: Index of Modules
 : <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html><head><title>Pydoc: Error - </title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link rel="stylesheet" type="text/css" href="pydoc_data/_pydoc.css"></head><body bgcolor="#f0f0f8">
            <div style='float:left'>
                Python 3.4.0a1 [v3.4.0a1:46535f65e7f3, GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]<br>Darwin-12.5.0
            </div>
            <div style='float:right'>
                <div style='text-align:center'>
                  <a href="index.html">Module Index</a>
                  : <a href="topics.html">Topics</a>
                  : <a href="keywords.html">Keywords</a>
                </div>
                <div>
                    <form action="get" style='display:inline;'>
                      <input type=text name=key size=15>
                      <input type=submit value="Get">
                    </form>&nbsp;
                    <form action="search" style='display:inline;'>
                      <input type=text name=key size=15>
                      <input type=submit value="Search">
                    </form>
                </div>
            </div>
            <div style="clear:both;padding-top:.5em;">
<table width="100%" cellspacing=0 cellpadding=2 border=0 summary="heading">
<tr bgcolor="#7799ee">
<td valign=bottom>&nbsp;<br>
<font color="#ffffff" face="helvetica, arial">&nbsp;<br><big><big><strong>Error</strong></big></big></font></td
><td align=right valign=bottom
><font color="#ffffff" face="helvetica, arial">&nbsp;</font></td></tr></table>
    <p>
<table width="100%" cellspacing=0 cellpadding=2 border=0 summary="section">
<tr bgcolor="#bb0000">
<td colspan=3 valign=bottom>&nbsp;<br>
<font color="#ffffff" face="helvetica, arial"><big><strong></strong></big></font></td></tr>

<tr><td bgcolor="#bb0000"><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</tt></td><td>&nbsp;</td>
<td width="100%">KeyError: '/Users/pyi/Library/Python/3.4/lib/python/site-packages/setuptools-0.9.8-py3.4.egg'
</td></tr></table></div>
</body></html>

[252/376/1] test_pyexpat
...
Re-running failed tests in verbose mode
Re-running test 'test_pydoc' in verbose mode
...
test_url_requests (test.test_pydoc.PydocUrlHandlerTest) ... ok
test_keywords (test.test_pydoc.TestHelper) ... ok

----------------------------------------------------------------------
Ran 25 tests in 2.253s

OK

----------
components: Tests
messages: 194309
nosy: ned.deily
priority: normal
severity: normal
status: open
title: intermittent test_pydoc failure on 3.4.0a1
versions: Python 3.4

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

From report at bugs.python.org  Sun Aug  4 00:06:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Aug 2013 22:06:07 +0000
Subject: [issue16741] `int()`, `float()`,
	etc think python strings are null-terminated
In-Reply-To: <1356046641.74.0.314140910069.issue16741@psf.upfronthosting.co.za>
Message-ID: <3c6zpQ4GLJzSMR@mail.python.org>


Roundup Robot added the comment:

New changeset 7b023134ad83 by Serhiy Storchaka in branch '3.3':
Issue #16741: Remove testing of implementation artifact.
http://hg.python.org/cpython/rev/7b023134ad83

New changeset 1b4772ab420f by Serhiy Storchaka in branch 'default':
Issue #16741: Remove testing of implementation artifact.
http://hg.python.org/cpython/rev/1b4772ab420f

----------

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

From report at bugs.python.org  Sun Aug  4 00:19:11 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 03 Aug 2013 22:19:11 +0000
Subject: [issue3591] elementtree tests do not include bytes handling
In-Reply-To: <1219078669.04.0.473516144349.issue3591@psf.upfronthosting.co.za>
Message-ID: <1375568351.73.0.166839751864.issue3591@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


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

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

From report at bugs.python.org  Sun Aug  4 00:20:54 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Aug 2013 22:20:54 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1375568454.54.0.910339472729.issue8860@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

With the current patch we still have the following quirks:

>>> timedelta(seconds=0.6112295) == timedelta(seconds=1)*0.6112295
False
>>> timedelta(seconds=0.6112295) == timedelta(seconds=round(0.6112295, 6))
False

This is not a reason to hold the patch, though.

----------

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

From report at bugs.python.org  Sun Aug  4 00:25:43 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 03 Aug 2013 22:25:43 +0000
Subject: [issue17372] provide pretty printer for xml.etree.ElementTree
In-Reply-To: <1362640725.41.0.836381435016.issue17372@psf.upfronthosting.co.za>
Message-ID: <1375568743.85.0.919328041677.issue17372@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I've noticed this is a duplicate of issue #14465. Closing it - let's continue the discussion there, when the time comes.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> xml.etree.ElementTree: add feature to prettify XML output

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

From report at bugs.python.org  Sun Aug  4 00:26:04 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 03 Aug 2013 22:26:04 +0000
Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output
In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>
Message-ID: <1375568764.48.0.948009410711.issue14465@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

A patch exists in the duplicate #17372

----------

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

From report at bugs.python.org  Sun Aug  4 00:27:14 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 03 Aug 2013 22:27:14 +0000
Subject: [issue13368] Possible problem in documentation of module subprocess, 
	method send_signal
In-Reply-To: <1320722594.89.0.739080107592.issue13368@psf.upfronthosting.co.za>
Message-ID: <1375568834.51.0.95637155017.issue13368@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Brian - gentle ping

----------

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

From report at bugs.python.org  Sun Aug  4 00:31:14 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 03 Aug 2013 22:31:14 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375569074.5.0.196731062408.issue18647@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


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

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

From report at bugs.python.org  Sun Aug  4 01:07:48 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 03 Aug 2013 23:07:48 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375571268.84.0.857908285514.issue18647@psf.upfronthosting.co.za>


Changes by Tim Peters <tim.peters at gmail.com>:


----------
nosy: +tim_one

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

From report at bugs.python.org  Sun Aug  4 01:44:53 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 03 Aug 2013 23:44:53 +0000
Subject: [issue7990] xml.etree.cElementTree lacks full dir() on Element
In-Reply-To: <1266856563.54.0.534391635456.issue7990@psf.upfronthosting.co.za>
Message-ID: <1375573493.52.0.996658269343.issue7990@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Could you please refresh the patch for Python 3.3 and 3.4 (_elementtree went through many changes in 3.3)?

----------

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

From report at bugs.python.org  Sun Aug  4 02:49:02 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Aug 2013 00:49:02 +0000
Subject: [issue17011] ElementPath ignores different namespace mappings for the
	same path expression
In-Reply-To: <1358838984.91.0.0315362873275.issue17011@psf.upfronthosting.co.za>
Message-ID: <3c73QN3nGVz7LkL@mail.python.org>


Roundup Robot added the comment:

New changeset 854ded9135c2 by Eli Bendersky in branch '3.3':
Issue #17011: Fix caching of xpath path when namespaces are present.
http://hg.python.org/cpython/rev/854ded9135c2

New changeset ce0be0d03c0a by Eli Bendersky in branch 'default':
Merge fix for Issue #17011 from 3.3
http://hg.python.org/cpython/rev/ce0be0d03c0a

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Aug  4 02:49:28 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 04 Aug 2013 00:49:28 +0000
Subject: [issue17011] ElementPath ignores different namespace mappings for the
	same path expression
In-Reply-To: <1358838984.91.0.0315362873275.issue17011@psf.upfronthosting.co.za>
Message-ID: <1375577368.95.0.165568350275.issue17011@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Fixed. Thanks!

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

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

From report at bugs.python.org  Sun Aug  4 02:54:49 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 04 Aug 2013 00:54:49 +0000
Subject: [issue17359] Mention "__main__.py" explicitly in command line docs
In-Reply-To: <1362512425.64.0.937549165034.issue17359@psf.upfronthosting.co.za>
Message-ID: <1375577689.27.0.355037377612.issue17359@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy:  -eli.bendersky

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

From report at bugs.python.org  Sun Aug  4 03:00:05 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 04 Aug 2013 01:00:05 +0000
Subject: [issue18268] ElementTree.fromstring non-deterministically gives
	unicode text data
In-Reply-To: <1371676914.3.0.530507394222.issue18268@psf.upfronthosting.co.za>
Message-ID: <1375578005.8.0.679954416958.issue18268@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I'm not sure what the issue here is, exactly. Python 2.7 is known for implicit conversions between ascii and unicode, and this appears to be an artifact of your data. Note that Python 2.7 only gets fixes for serious bugs at this point.

Can you reproduce this problem with Python 3.3? More generally, can you provide a small reproducer? Without this I don't think this is a constructive report, and will close the issue in a few days.

----------

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

From report at bugs.python.org  Sun Aug  4 03:02:49 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 04 Aug 2013 01:02:49 +0000
Subject: [issue17963] Deprecate the frame hack for implicitly getting module
	details
In-Reply-To: <1368364153.58.0.131087315276.issue17963@psf.upfronthosting.co.za>
Message-ID: <1375578169.55.0.210077917007.issue17963@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I'm (somewhat) back looking at this. Should the first step be sys.get_calling_module_name()? I can provide a patch. Re its name, perhaps the long name isn't that bad given that this is a rather obscure API. But suggestions for something shorter/better will be welcome.

----------

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

From report at bugs.python.org  Sun Aug  4 03:13:19 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 04 Aug 2013 01:13:19 +0000
Subject: [issue18648] FP Howto and the PEP 8 lambda guildline
In-Reply-To: <1375563496.73.0.458556999556.issue18648@psf.upfronthosting.co.za>
Message-ID: <1375578799.33.0.828536077651.issue18648@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I would just change "my usual course is to avoid using lambda" to "PEP 8 prescribes using def."  Note that PEP 8 itself displays f = lambda x: 2*x as an example of what not to do.  I see no problem with the current examples.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Sun Aug  4 03:40:36 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 04 Aug 2013 01:40:36 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375558286.11.0.0812868181552.issue18606@psf.upfronthosting.co.za>
Message-ID: <51FDB0FE.205@pearwood.info>


Steven D'Aprano added the comment:

On 04/08/13 05:31, Alexander Belopolsky wrote:
>
> Alexander Belopolsky added the comment:
>
> Here is the use-case that was presented to support adding additional operations on timedelta objects:
>
> """
> I'm conducting a series of observation experiments where I
> measure the duration of an event.  I then want to do various
> statistical analysis such as computing the mean, median,
> etc.  Originally, I tried using standard functions such as
> lmean from the stats.py package.  However, these sorts of
> functions divide by a float at the end, causing them to fail
> on timedelta objects.  Thus, I have to either write my own
> special functions, or convert the timedelta objects to
> integers first (then convert them back afterwards).
> """  (Daniel Stutzbach, in msg26267 on issue1289118.)
>
> The proposed statistics module does not support this use case:
[...]
> TypeError: sum only accepts numbers

That's a nice use-case, but I'm not sure how to solve it, or whether it needs to be.

I'm not going to add support for timedelta objects as a special-case. Once we start special-casing types, where will it end?

At first I thought that registering timedelta as a numeric type would help, but that is a slightly dubious thing to do since timedelta doesn't support all numeric operations:

py> datetime.timedelta(1, 1, 1)+2
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'datetime.timedelta' and 'int'

(What would that mean, anyway? Add two days, two seconds, or two milliseconds?)

Perhaps timedelta objects should be enhanced to be (Integral?) numbers. In the meantime, there's a simple way to do this:

py> from datetime import timedelta as td
py> data = [td(2), td(1), td(3), td(4)]
py> m = statistics.mean([x.total_seconds() for x in data])
py> m
216000.0
py> td(seconds=m)
datetime.timedelta(2, 43200)

And for standard deviation:

py> s = statistics.stdev([x.total_seconds() for x in data])
py> td(seconds=s)
datetime.timedelta(1, 25141, 920371)

median works without any wrapper:

py> statistics.median(data)
datetime.timedelta(2, 43200)

I'm now leaning towards "will not fix" for supporting timedelta objects. If they become proper numbers, then they should just work, and if they don't, supporting them just requires a tiny bit of extra code.

However, I will add documentation and tests for them.

----------

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

From report at bugs.python.org  Sun Aug  4 03:52:56 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 04 Aug 2013 01:52:56 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1375581176.82.0.514287640678.issue18606@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

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

From report at bugs.python.org  Sun Aug  4 03:53:07 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Aug 2013 01:53:07 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1375567228.62.0.278053355757.issue18264@psf.upfronthosting.co.za>
Message-ID: <CADiSq7errt7EOub9sFpi=3qOYQvht8TUu+yVn=3rmD-L28zz8w@mail.gmail.com>


Nick Coghlan added the comment:

It occurs to me that operator.index() (without a preceding type check) is
likely the more ducktyping friendly option here.

----------

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

From report at bugs.python.org  Sun Aug  4 03:53:50 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 04 Aug 2013 01:53:50 +0000
Subject: [issue7990] xml.etree.cElementTree lacks full dir() on Element
In-Reply-To: <1266856563.54.0.534391635456.issue7990@psf.upfronthosting.co.za>
Message-ID: <1375581230.8.0.579994012284.issue7990@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

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

From report at bugs.python.org  Sun Aug  4 03:55:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Aug 2013 01:55:30 +0000
Subject: [issue17902] Document that _elementtree C API cannot use custom
	TreeBuilder for iterparse or IncrementalParser
In-Reply-To: <1367614578.64.0.34953241054.issue17902@psf.upfronthosting.co.za>
Message-ID: <3c74v55gcnzStl@mail.python.org>


Roundup Robot added the comment:

New changeset a5a5ba4f71ad by Eli Bendersky in branch '3.3':
Issue #17902: Clarify doc of ElementTree.iterparse
http://hg.python.org/cpython/rev/a5a5ba4f71ad

New changeset 96f45011957e by Eli Bendersky in branch 'default':
Issue #17902: Clarify doc of ElementTree.iterparse and IncrementalParser
http://hg.python.org/cpython/rev/96f45011957e

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Aug  4 03:55:45 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 04 Aug 2013 01:55:45 +0000
Subject: [issue17902] Document that _elementtree C API cannot use custom
	TreeBuilder for iterparse or IncrementalParser
In-Reply-To: <1367614578.64.0.34953241054.issue17902@psf.upfronthosting.co.za>
Message-ID: <1375581345.82.0.234287163831.issue17902@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


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

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

From report at bugs.python.org  Sun Aug  4 04:07:58 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 04 Aug 2013 02:07:58 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1375582078.36.0.764112705453.issue18606@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> Once we start special-casing types, where will it end?

At the point where all stdlib types are special-cased. :-)


> In the meantime, there's a simple way to do this:

py> from datetime import timedelta as td
py> data = [td(2), td(1), td(3), td(4)]
py> m = statistics.mean([x.total_seconds() for x in data])
py> td(seconds=m)
datetime.timedelta(2, 43200)

Simple, but as simple ways go in this area not correct.  Here is the right way:

py> td.resolution * statistics.mean(d//td.resolution for d in data)
datetime.timedelta(2, 43200)

I wish I had a solution to make sum() work properly on timedeltas without special-casing.  I thought that start could default to type(data[0])(0), but that would bring in strings.  Maybe statistics.mean() should support non-numbers that support addition and division by a number?  Will it be too confusing if mean() supports types that sum() does not?

----------

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

From report at bugs.python.org  Sun Aug  4 09:02:05 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Aug 2013 07:02:05 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1375599725.43.0.408095725082.issue8860@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Alexander:  applying this is fine by me.  As a user-visible change, yes, I think it should have a Misc/NEWS entry.  (It's too small a change to be worth mentioning in the 'whatsnew' documents though.)

----------

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

From report at bugs.python.org  Sun Aug  4 09:19:00 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Aug 2013 07:19:00 +0000
Subject: [issue18642] enhancement for operator 'assert'
In-Reply-To: <1375530787.73.0.318484624842.issue18642@psf.upfronthosting.co.za>
Message-ID: <1375600740.77.0.340258215884.issue18642@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Okay, I'm closing this for now.  Al Korgun and mrDoctorWho0 .: if you think this idea deserves wider discussion, you should feel free to bring it up again on the python-ideas mailing list;  that's a better forum to discuss these sorts of language changes anyway (too few developers will look at any particular bug on the bug tracker; many more read python-ideas).  It seems unlikely to me that the idea would receive widespread acceptance, but I may well be wrong.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Sun Aug  4 09:21:43 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 04 Aug 2013 07:21:43 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375600903.09.0.48656966351.issue18264@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I don't understand.

Type checks are already performed throughout the code (int, float, True, False, NaN, Inf, etc.).

What will opereator.index buy us?

----------

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

From report at bugs.python.org  Sun Aug  4 09:30:24 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Aug 2013 07:30:24 +0000
Subject: [issue18570] OverflowError in division: wrong message
In-Reply-To: <1374924685.41.0.945479313268.issue18570@psf.upfronthosting.co.za>
Message-ID: <1375601424.81.0.304513811112.issue18570@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> With that fixed, I am inclined to close this.

Agreed.  I'll try to find some time for a PEP at some point in the next few weeks.

> I had thought of a set-mode function (method), but anticipate objection
> to such modal action-at-distance behavior.

Yes;  I'm not a big fan of global state[*] either in general, but there aren't many other good options:  specifying the mode to each operation individually would be painful and prevent natural use of infix operators, generally making code more unreadable.  There *would* need to be some kind of set-mode function (or perhaps writable sys module attribute) as you suggest, but the context manager could be promoted as the recommended way to change the state in a manner that's reasonably safe and explicit.


[*] We'd want it to be thread-local rather than global, of course.

----------

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

From report at bugs.python.org  Sun Aug  4 09:31:07 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Aug 2013 07:31:07 +0000
Subject: [issue18570] OverflowError in division: wrong message
In-Reply-To: <1374924685.41.0.945479313268.issue18570@psf.upfronthosting.co.za>
Message-ID: <1375601467.54.0.730299988186.issue18570@psf.upfronthosting.co.za>


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


----------
resolution:  -> postponed
status: open -> closed

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

From report at bugs.python.org  Sun Aug  4 09:38:45 2013
From: report at bugs.python.org (Brendan O'Connor)
Date: Sun, 04 Aug 2013 07:38:45 +0000
Subject: [issue11033] ElementTree.fromstring doesn't work with Unicode
In-Reply-To: <1296173256.62.0.363094614198.issue11033@psf.upfronthosting.co.za>
Message-ID: <1375601924.99.0.377402579068.issue11033@psf.upfronthosting.co.za>


Brendan O'Connor added the comment:

Sure, go ahead and close it.  I was just trying to be helpful and report a bug in the Python standard library.  I don't use Python 3.3 so cannot test it.

----------
nosy: +Brendan.OConnor

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

From report at bugs.python.org  Sun Aug  4 09:49:06 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Aug 2013 07:49:06 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375602546.69.0.745119009172.issue18264@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The two "isinstance" checks that bother me are the ones for int and float. However, given that the JSON serialiser *already* includes those explicit checks, I now think it makes sense to just do the minimal fix of coercing subclasses to the base type for both of those cases, especially since such a change should be able to be ported to simplejson as well.

Anything more elaborate (including making JSON explicitly enum aware, or else offering a new encoder that supports singledispatch) should be handled in a separate issue.

----------

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

From report at bugs.python.org  Sun Aug  4 10:07:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 08:07:20 +0000
Subject: [issue18151] Idlelib: update to "with open ... except OSError" (in
	2.7, leave IOError)
In-Reply-To: <1370538152.36.0.501706446334.issue18151@psf.upfronthosting.co.za>
Message-ID: <1375603640.3.0.783921841198.issue18151@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which replace the "open ... close" idiom to the "with open" idiom in IDLE.

----------
stage: commit review -> patch review
Added file: http://bugs.python.org/file31144/idle_with_open.patch

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

From report at bugs.python.org  Sun Aug  4 10:08:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 08:08:32 +0000
Subject: [issue18151] Idlelib: update to "with open ... except OSError" (in
	2.7, leave IOError)
In-Reply-To: <1370538152.36.0.501706446334.issue18151@psf.upfronthosting.co.za>
Message-ID: <1375603712.83.0.639368446077.issue18151@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which replace the "open ... close" idiom to the "with open" idiom in IDLE.

----------
Added file: http://bugs.python.org/file31145/idle_with_open.patch

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

From report at bugs.python.org  Sun Aug  4 10:16:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 08:16:37 +0000
Subject: [issue14012] Misc tarfile fixes
In-Reply-To: <1329235837.42.0.144867770777.issue14012@psf.upfronthosting.co.za>
Message-ID: <1375604197.55.0.618937911221.issue14012@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is updated for 3.4 patch.

----------
Added file: http://bugs.python.org/file31146/tarfile-misc-bugs-3.4.diff

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

From report at bugs.python.org  Sun Aug  4 10:37:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 08:37:10 +0000
Subject: [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1375605430.15.0.944692441092.issue8865@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Gregory, could you commit the patch or allow me to do this?

----------

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

From report at bugs.python.org  Sun Aug  4 10:56:17 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Aug 2013 08:56:17 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
	operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1375606577.3.0.541077109007.issue17576@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

See the related python-dev discussion started by Mark Shannon here:

http://mail.python.org/pipermail/python-dev/2013-March/125022.html

and continuing well into April here:

http://mail.python.org/pipermail/python-dev/2013-April/125042.html

The consensus that emerged from that thread seems to be that calls to operator.index and to int() should always return something of exact type int.

The attached patch:

- Raises TypeError for implicit calls to nb_int that fail to return something of exact type int.  (Results of direct calls to __int__ are not checked.)

- Ensures that *all* conversions from a non-int to an int via nb_int make use of the nb_int slot, even for int subclasses.  Prior to this patch, some of the PyLong_As... functions would bypass __int__ for int subclasses.

- Adds a new private _PyLong_FromNbInt function to Objects/longobject.c, so that we have a single place for performing these conversions and making type checks, and refactors existing uses of the nb_int slot to go via this function.

- Makes corresponding changes for nb_index, which should address the original bug report.

I guess this may be too dangerous a change for Python 3.4.  In that case, I propose raising warnings instead of TypeErrors for Python 3.4 and turning those into TypeErrors in Python 3.5.

One other question:  should direct calls to __int__ and __index__ also have their return values type-checked?  That doesn't seem to happen at the moment for other magic methods (see below), so it would seem consistent to only do the type checking for interpreter-generated implicit calls to __int__ and __index__.  Nick: any opinion?

>>> class A:
...     def __len__(self): return "a string"
...     def __bool__(self): return "another string"
... 
>>> a = A()
>>> a.__len__()
'a string'
>>> a.__bool__()
'another string'
>>> len(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' object cannot be interpreted as an integer
>>> bool(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __bool__ should return bool, returned str

----------
assignee: docs at python -> mark.dickinson
components: +Interpreter Core -Documentation
keywords: +patch
nosy: +ncoghlan
Added file: http://bugs.python.org/file31147/issue17576.patch

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

From report at bugs.python.org  Sun Aug  4 12:07:06 2013
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 04 Aug 2013 10:07:06 +0000
Subject: [issue18651] test failures on KFreeBSD
Message-ID: <1375610825.98.0.456814475805.issue18651@psf.upfronthosting.co.za>


New submission from Matthias Klose:

Some tests fail on KFreeBSD, attaching a first patch from Petr Salinger. 

see http://bugs.debian.org/708653 for further issues.

Ronald, could you check if that this works for OSX too?

----------
components: Tests
files: kfreebsd.diff
keywords: patch
messages: 194336
nosy: doko, ronaldoussoren
priority: normal
severity: normal
status: open
title: test failures on KFreeBSD
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31148/kfreebsd.diff

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

From report at bugs.python.org  Sun Aug  4 12:07:25 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Aug 2013 10:07:25 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
	operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1375610845.51.0.566366228358.issue17576@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

New patch that replaces the TypeErrors with warnings and fixes a refleak in the original patch.

----------
Added file: http://bugs.python.org/file31149/issue17576_v2.patch

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

From report at bugs.python.org  Sun Aug  4 12:08:55 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 04 Aug 2013 10:08:55 +0000
Subject: =?utf-8?q?=5Bissue18652=5D_Add_a_=E2=80=9Cfirst=E2=80=9D_function_to_the_?=
	=?utf-8?q?stdlib?=
Message-ID: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>


New submission from Hynek Schlawack:

Let met try to get you sold on adding the ?first? function I released on PyPI roughly a year ago:

https://github.com/hynek/first

It?s a very nice complement to functions like `any()` or itertools. I consists effectively of 9 lines of code but it proved extremely handy in production.

***

It returns the first true value from an iterable or a default:

>>> first([0, None, False, [], (), 42])
42

>>> first([0, None, False, [], ()], default=42)
42

Additionally it also allows for a key function:

>>> first([1, 1, 3, 4, 5], key=lambda x: x % 2 == 0)
4

***

First happens to be especially useful together with the re module:

import re

from first import first


re1 = re.compile('b(.*)')
re2 = re.compile('a(.*)')

m = first(regexp.match('abc') for regexp in [re1, re2])
if not m:
   print('no match!')
elif m.re is re1:
   print('re1', m.group(1))
elif m.re is re2:
   print('re2', m.group(1))


All the knee-jerk alternatives to it have some shortcomings:

next(itertools.ifilter(None, (regexp.match('abc') for regexp in [re1, re2])), None)
next((regexp.match('abc') for regexp in [re1, re2] if regexp.match('abc')), None)

None of them is Pythonic and the second one even has to call match() twice, which is *not* a cheap method to call.

Here the first version for comparison again:

first(regexp.match('abc') for regexp in [re1, re2])

It doesn?t even exhaust the iterator if not necessary.

***

I don?t cling to neither the name or the exact function signature (although it got polished with the help of several people, two of them core developers).  I also don?t really care whether it gets added along of any() or put into itertools.  I just know that I and several other people would appreciate to have such a handy function in the stdlib ? I even got an e-mail from OpenStack folks asking when it will be added because they would like to use it and there?s even a debian package by now: http://packages.debian.org/unstable/python-first

There?s also this question on StackOverflow: http://stackoverflow.com/questions/1077307/why-is-there-no-firstiterable-built-in-function-in-python which is nice but doesn?t fix the subtleties like when there is no true value etc which makes it useless for production code and one has to write boilerplate code every single time.

It was even one of five Python packages Lukasz Langa deemed worthy to be highlighted in his PyCon 2013 lightning talk: http://youtu.be/1vui-LupKJI?t=20m40s

FWIW, SQL has a similar function called COALESCE ( https://en.wikipedia.org/wiki/Null_(SQL)#COALESCE ) which only handles NULL though.

***

I?ll happily respond to any questions or concerns that may arise and supply a patch as soon as we agree on a place to add it.

----------
assignee: hynek
components: Library (Lib)
messages: 194338
nosy: hynek, lukasz.langa, ncoghlan, rhettinger
priority: normal
severity: normal
status: open
title: Add a ?first? function to the stdlib
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Aug  4 12:23:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Aug 2013 10:23:13 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <3c7J8w3WfZz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset e2ba4592ce3a by Serhiy Storchaka in branch '2.7':
Issue #18647: Temporary disable the "nothing to repeat" check to make buildbots happy.
http://hg.python.org/cpython/rev/e2ba4592ce3a

----------

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

From report at bugs.python.org  Sun Aug  4 12:24:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 10:24:34 +0000
Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular
	encoding
In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za>
Message-ID: <1375611874.73.0.740222320733.issue13612@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch for 2.7.

----------
Added file: http://bugs.python.org/file31150/expat_buffer_overflow-2.7.patch

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

From report at bugs.python.org  Sun Aug  4 12:28:59 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 10:28:59 +0000
Subject: =?utf-8?q?=5Bissue18652=5D_Add_a_=E2=80=9Cfirst=E2=80=9D_function_to_the_?=
	=?utf-8?q?stdlib?=
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375612139.61.0.282526724055.issue18652@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The function name looks a little misleading. I expected first([0, None, False, [], (), 42]) returns 0.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sun Aug  4 12:43:05 2013
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sun, 04 Aug 2013 10:43:05 +0000
Subject: [issue18201] distutils write into symlinks instead of replacing them
In-Reply-To: <1371100735.33.0.721782392161.issue18201@psf.upfronthosting.co.za>
Message-ID: <1375612985.88.0.0161748963567.issue18201@psf.upfronthosting.co.za>


Micha? G?rny added the comment:

Oh, sorry. I've looked throughout the code again and it seems that distutils is doing the right thing. It's setuptools/distribute that is broken.

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

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

From report at bugs.python.org  Sun Aug  4 12:58:38 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Aug 2013 10:58:38 +0000
Subject: =?utf-8?q?=5Bissue18652=5D_Add_a_=E2=80=9Cfirst=E2=80=9D_function_to_the_?=
	=?utf-8?q?stdlib?=
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375613918.37.0.222692945276.issue18652@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

It's a direct counterpart to any() and all() - first([0, [], ()]) is None for the same reason that any([0, [], ()]) and all([0, [], ()]) are both False.

If first returned the actual first item in the iterable (regardless of truth value), then it would just be "next" under a different name, which would be rather pointless.

That said, if "first" is deemed too ambiguous, then I believe "filterednext" would be a reasonable more explicit name:

>>> filterednext([0, None, False, [], (), 42])
42

>>> filterednext([0, None, False, [], ()], default=42)
42

>>> filterednext([1, 1, 3, 4, 5], key=lambda x: x % 2 == 0)
4

>>> m = filterednext(regexp.match('abc') for regexp in [re1, re2])

I also believe itertools would be a more appropriate initial home than the builtins.

----------

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

From report at bugs.python.org  Sun Aug  4 12:58:43 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sun, 04 Aug 2013 10:58:43 +0000
Subject: [issue13238] Add shell command helpers to subprocess module
In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za>
Message-ID: <1375613923.49.0.908105803244.issue13238@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

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

From report at bugs.python.org  Sun Aug  4 13:09:38 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 04 Aug 2013 11:09:38 +0000
Subject: [issue17684] Skip tests in test_socket like testFDPassSeparate on OS X
In-Reply-To: <1365563429.51.0.176752850468.issue17684@psf.upfronthosting.co.za>
Message-ID: <1375614578.82.0.0498581931558.issue17684@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Charles-Francois: why did you commit this to default only, and not to 3.3?
(see also issue18651)

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

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

From report at bugs.python.org  Sun Aug  4 13:10:52 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 04 Aug 2013 11:10:52 +0000
Subject: [issue18651] test failures on KFreeBSD
In-Reply-To: <1375610825.98.0.456814475805.issue18651@psf.upfronthosting.co.za>
Message-ID: <1375614652.42.0.712383481358.issue18651@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Note that 3.4 will need a different patch, due to issue17684.

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

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

From report at bugs.python.org  Sun Aug  4 13:27:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 11:27:24 +0000
Subject: =?utf-8?q?=5Bissue18652=5D_Add_a_=E2=80=9Cfirst=E2=80=9D_function_to_the_?=
	=?utf-8?q?stdlib?=
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375615644.73.0.626898110146.issue18652@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In this case it would be pointless too. It is just

    next(filter(key, iterable), default)

Are you need a special function for combination of two builtins?

----------

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

From report at bugs.python.org  Sun Aug  4 13:29:25 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Aug 2013 11:29:25 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
	operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1375615765.09.0.934256182267.issue17576@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The deprecation warning version looks good to me.

Something I'll mention explicitly (regarding the PyCon discussions that Eric mentioned above), is that we unfortunately couldn't do something like this for the various concrete APIs with overly permissive subclass checks. For those APIs, calling them directly was often the *right* thing for simple subtypes implemented in C to use to call up to the parent implementation.

This case is different, as it's the *abstract* APIs that currently have the overly permissive checks.

----------

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

From report at bugs.python.org  Sun Aug  4 13:36:23 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 04 Aug 2013 11:36:23 +0000
Subject: =?utf-8?q?=5Bissue18652=5D_Add_a_=E2=80=9Cfirst=E2=80=9D_function_to_the_?=
	=?utf-8?q?stdlib?=
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375616183.4.0.233060893218.issue18652@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

`filter()` exhausts the full iterator which is potentially very expensive ? like in conduction with regular expressions.

----------

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

From report at bugs.python.org  Sun Aug  4 13:38:39 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 04 Aug 2013 11:38:39 +0000
Subject: =?utf-8?q?=5Bissue18652=5D_Add_a_=E2=80=9Cfirst=E2=80=9D_function_to_the_?=
	=?utf-8?q?stdlib?=
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375616319.28.0.683056445036.issue18652@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I also think it should go to itertools.

I also found the name "first" confusing, in particular since it means what Serhiy assumes in LISP, which might be familiar to people interested in functional list processing. Also, Ruby and Smalltalk use "first" in that sense.

To add to the bike shedding, I propose "find_if" (from LISP), "coalesce" (from SQL), or "detect" (from Smalltalk).

-1 on calling the filter function "key=". How about "pred=" (like all other itertools predicates) or "filter="?

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

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

From report at bugs.python.org  Sun Aug  4 13:38:46 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Aug 2013 11:38:46 +0000
Subject: =?utf-8?q?=5Bissue18652=5D_Add_a_=E2=80=9Cfirst=E2=80=9D_function_to_the_?=
	=?utf-8?q?stdlib?=
In-Reply-To: <1375615644.73.0.626898110146.issue18652@psf.upfronthosting.co.za>
Message-ID: <CADiSq7duwPoFDCh3fWQ9Uh_zBr95YqwWOxtQkZiHKpqUOzeSZg@mail.gmail.com>


Nick Coghlan added the comment:

Serhiy, Hynek covered the issue with the status quo in the original
proposal.The existing alternative are painful to try and decipher by
comparison with the named function:

    filterednext([0, None, False, [], (), 42])
vs
    next(filter(None, [0, None, False, [], (), 42]))

    filterednext([0, None, False, [], ()], default=42)
vs
    next(filter(None, [0, None, False, [], (), 42]), 42)

    filterednext([1, 1, 3, 4, 5], key=lambda x: x % 2 == 0)
vs
    next(filter(lambda x: x % 2 == 0, [1, 1, 3, 4, 5]))

    m = filterednext(regexp.match('abc') for regexp in [re1, re2])
vs
    m = next(filter(None, (regexp.match('abc') for regexp in [re1, re2])))

Hynek - the Python 3 filter is an iterator, so it works like the
itertools.ifilter version in Python 2.

----------

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

From report at bugs.python.org  Sun Aug  4 13:41:34 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 04 Aug 2013 11:41:34 +0000
Subject: =?utf-8?q?=5Bissue18652=5D_Add_a_=E2=80=9Cfirst=E2=80=9D_function_to_the_?=
	=?utf-8?q?stdlib?=
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375616494.65.0.976909182856.issue18652@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

Ah ok sorry. Anyhow, it?s just a very common idiom that should be easy and readable.

As said, I?m not married to any names at all and would happily add a compatibility package to PyPI with the new names/parameters.

----------

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

From report at bugs.python.org  Sun Aug  4 13:49:38 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 04 Aug 2013 11:49:38 +0000
Subject: =?utf-8?q?=5Bissue18652=5D_Add_a_=E2=80=9Cfirst=E2=80=9D_function_to_the_?=
	=?utf-8?q?stdlib?=
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375616978.47.0.912634231601.issue18652@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Nick: that the code is difficult to decipher is really the fault of functional programming, which is inherently difficult to decipher (since last function applied is written first).

Explicit iteration is easier to read. I would write Hynek's example as

for r in (re1, re2):
    m = r.match('abc')
    if not m:
        print('No match)
    elif r is re1:
        print('re1', m.group(1))
    elif r is re2:
        print('re1', m.group(1))
    break # always

This is only two additional lines, very Pythonic (IMO), and doesn't invoke match unnecessarily.

----------

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

From report at bugs.python.org  Sun Aug  4 13:50:16 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Aug 2013 11:50:16 +0000
Subject: =?utf-8?q?=5Bissue18652=5D_Add_a_=E2=80=9Cfirst=E2=80=9D_function_to_the_?=
	=?utf-8?q?stdlib?=
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375617016.12.0.217582215461.issue18652@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Regarding the key parameter name, I believe this is closer to itertools.groupby (which uses "key=" as an optional argument, akin to min, max and sorted) than it is to filterfalse, dropwhile or takewhile (which use "pred" as the first positional argument)

The only use of "pred" in the optional key argument sense appears to be the "quantify" recipe.

+1 for itertools.coalesce, taking the name from SQL. It's designed to serve exactly the same purpose as COALESCE does there, doesn't risk confusion with next-like behaviour the way "first" does and hints strongly at the fact it is a reduction operation from an iterable to a single value.

----------

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

From report at bugs.python.org  Sun Aug  4 13:58:16 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 04 Aug 2013 11:58:16 +0000
Subject: =?utf-8?q?=5Bissue18652=5D_Add_a_=E2=80=9Cfirst=E2=80=9D-like_function_to?=
	=?utf-8?q?_the_stdlib?=
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375617496.41.0.962119043333.issue18652@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

Martin, I don?t find the loop easier to read because you have to *remember* the `break` otherwise ?weird stuff happens?.

Coalesce seems common enough, I would +1 on that too.

----------
title: Add a ?first? function to the stdlib -> Add a ?first?-like function to the stdlib

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

From report at bugs.python.org  Sun Aug  4 14:09:45 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Aug 2013 12:09:45 +0000
Subject: [issue18652] Add itertools.coalesce
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375618185.88.0.0505194668165.issue18652@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

(Updated the issue title to reflect the currently proposed name and location for the functionality)

While I'm a fan of explicit iteration as well ("inside every reduce is a loop trying to get out"), I think the fact Martin's explicit loop is buggy (it will never match re2 as it always bails on the first iteration) helps make the case for coalesce. The correct explicit loop looks something like this:

    for r in (re1, re2):
        m = r.match('abc')
        if m is None:
            continue
        if r is re1:
            print('re1', m.group(1))
        elif r is re2:
            print('re1', m.group(1))
        break # Matched something
    else:
        print('No match')

(Or the equivalent that indents the loop body further and avoids the continue statement)

The coalesce version has a definite advantage in not needing a loop else clause to handle the "nothing matched" case:

    m = coalesce(regexp.match('abc') for regexp in [re1, re2])
    if m is None:
        print('no match!')
    elif m.re is re1:
        print('re1', m.group(1))
    elif m.re is re2:
        print('re2', m.group(1))

----------
title: Add a ?first?-like function to the stdlib -> Add itertools.coalesce

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

From report at bugs.python.org  Sun Aug  4 14:14:26 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 04 Aug 2013 12:14:26 +0000
Subject: [issue18652] Add itertools.coalesce
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375618466.68.0.538218853272.issue18652@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Simplicity is in the eye of the beholder, yet... you need to remember the break when *writing* the code, so the loop might be more difficult to write (but then, I need to remember/lookup the function name and parameters for coalesce)... when reading the code, the break is already there, and easy to notice. With Nick's remark, it's even more obvious that it is difficult to write :-)

If an unknown (to the reader) function is used, reading the code becomes actually difficult, since the reader either needs to guess what the function does, or look it up.

Note that I'm not objecting the addition of the function (I'm neutral), just the claim that there are no simple alternatives. I'm neutral because it falls under the "not every two-line function needs to go into the standard library" rule; but then, if it is really popular, it helps readability if it is in the library (rather than duplicated by users).

----------

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

From report at bugs.python.org  Sun Aug  4 14:15:47 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sun, 04 Aug 2013 12:15:47 +0000
Subject: [issue1300] subprocess.list2cmdline doesn't do pipe symbols
In-Reply-To: <1192729254.96.0.285794085895.issue1300@psf.upfronthosting.co.za>
Message-ID: <1375618547.52.0.649224369432.issue1300@psf.upfronthosting.co.za>


Piotr Dobrogost added the comment:

>Maybe the solution is to make what I was trying to do easier without
>fooling with the shell instead of playing the fool's game of trying to
>improve the ability to deal with the shell so we can pass things
>through it unnecessarily.

You are too harsh for yourself :) We should be able to make use of shell easily the same way it's possible in other languages like Perl or Ruby.

>It sure would be nice on Windows to have an equivalent of
>list2cmdline() that works for the shell.

I agree. See issue 13238 for a list of libraries which make is easier to use shell from Python.

----------
nosy: +piotr.dobrogost

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

From report at bugs.python.org  Sun Aug  4 14:35:20 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Aug 2013 12:35:20 +0000
Subject: [issue18653] mingw-meta: build core modules
Message-ID: <1375619720.06.0.766677441218.issue18653@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871 - this is meta issue only for part related to build core. Remark: build of interpreter core is in issue17605 .

Now split is:
- 01 issue13756 : Python make fail on cygwin
- 02 issue17219 : add current dir in library path if building python standard extensions
- 03 issue6672   : Add Mingw recognition to pyport.h to allow building extensions
- 04 issue18485 : configure for shared build
- 05 issue18486 : dynamic loading support
- 06 issue18487 : implement exec prefix
- 07 issue18495 : ignore main program for frozen scripts
- 08 issue18496 : setup exclude termios module
- 09 issue18497 : setup _multiprocessing module
- 10 issue18498 : setup select module
- 11 issue18499 : setup _ctypes module with system libffi
- 12 issue18500 : defect winsock2 and setup _socket module
- 13 issue18630 : exclude unix only modules
- 14 issue18631 : setup msvcrt and _winapi modules
- 15 issue18632 : build extensions with GCC
- 16 issue18633 : use Mingw32CCompiler as default compiler for mingw* build
- 17 issue18634 : find import library
- 18 issue18636 : setup _ssl module
- 19 issue18637 : export _PyNode_SizeOf as PyAPI for parser module
- 20 issue18638 : generalization of posix build in sysconfig.py
- 21 issue18639 : avoid circular dependency from time module during native build of extentions
- 22 issue18640 : generalization of posix build in distutils/sysconfig.py
- 23 issue18641 : customize site
- 24 after above patches user must regenerate configure script.

Hints:
a) at configure time define environment variable CPPFLAGS with minimum supported version like this   "-DWINVER=0x501 -D_WIN32_WINNT=0x501  -DMS_COREDLL=1", i.e XP is now minimum. MS_COREDLL is required for ctype module
b) at configure time define environment variable CCSHARED with minimum supported version like this: "-DWINVER=0x501 -D_WIN32_WINNT=0x501". Remark use same values as CPPFLAGS
c) use --without-libm
d) use --enable-shared
e) use --with-system-ffi

----------
components: Build, Cross-Build, Extension Modules
messages: 194358
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw-meta: build core modules
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Aug  4 14:39:05 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Aug 2013 12:39:05 +0000
Subject: [issue18652] Add itertools.coalesce
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375619945.39.0.808704141651.issue18652@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

[Nick]
> Regarding the key parameter name, I believe this is closer to
> itertools.groupby ...

Isn't this mostly about the return type?  `pred` is an indication that a boolean is being returned (or that the return value will be interpreted in a boolean context), while `key` is used for more general transformations.  In that sense, `pred` makes more sense here.

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

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

From report at bugs.python.org  Sun Aug  4 14:42:13 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 04 Aug 2013 12:42:13 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375620133.77.0.43384807032.issue18264@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I also think that exchanging the explicit type checks by __index__ merits more thought and is outside the scope of this local fix. The proposed patch does not add any new type checks, but acts within the bounds of code for which the type is already established.

----------

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

From report at bugs.python.org  Sun Aug  4 14:43:01 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Aug 2013 12:43:01 +0000
Subject: [issue18652] Add itertools.coalesce
In-Reply-To: <1375619945.39.0.808704141651.issue18652@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fAVxG5zkXg_XPW+vpZr+U1ySfYSPXMmXqCS4TGWDYWMA@mail.gmail.com>


Nick Coghlan added the comment:

Mark's rationale makes sense to me. I believe that would make the
latest version of the proposed API (in the itertools module):

    def coalesce(iterable, default=None, pred=None):
        ...

----------

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

From report at bugs.python.org  Sun Aug  4 14:51:47 2013
From: report at bugs.python.org (=?utf-8?q?Dan_S=C3=B8ndergaard?=)
Date: Sun, 04 Aug 2013 12:51:47 +0000
Subject: [issue18624] Add alias for iso-8859-8-i which is the same as
	iso-8859-8
In-Reply-To: <1375398269.06.0.0330535739148.issue18624@psf.upfronthosting.co.za>
Message-ID: <1375620707.42.0.0891847384207.issue18624@psf.upfronthosting.co.za>


Dan S?ndergaard added the comment:

Is it satisfactory to just add the -i and -e variants to ALIASES in charset.py? Or don't they qualify as "Aliases for other commonly-used names for character sets"?

----------
nosy: +das

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

From report at bugs.python.org  Sun Aug  4 15:05:00 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Aug 2013 13:05:00 +0000
Subject: [issue18654] modernize mingw&cygwin compiler classes
Message-ID: <1375621500.14.0.511859388859.issue18654@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Python mingw and cygwin compiler classes tests for outdated features. Also python code set some flags like zero optimization level and etc. that prevent users to build optimized python or even worse build to fail.

This issue is part of split of issue3871 with clean-up and enhancements:
- archive contain set of 10 patches - remove of outdated (15 years old !!!!) features one by one.
- enhance unix compiler customization with mingw and cygwin compilers

----------
assignee: eric.araujo
components: Build, Cross-Build, Distutils
files: modernize-mingw+cygwin-compiler-class.tar.gz
messages: 194363
nosy: eric.araujo, rpetrov, tarek
priority: normal
severity: normal
status: open
title: modernize mingw&cygwin compiler classes
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31151/modernize-mingw+cygwin-compiler-class.tar.gz

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

From report at bugs.python.org  Sun Aug  4 15:10:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Aug 2013 13:10:41 +0000
Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular
	encoding
In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za>
Message-ID: <3c7Mt83ZfpzSXj@mail.python.org>


Roundup Robot added the comment:

New changeset b3efc140d8a6 by Eli Bendersky in branch '2.7':
Issue #13612: Fix a buffer overflow in case of a multi-byte encoding.
http://hg.python.org/cpython/rev/b3efc140d8a6

----------

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

From report at bugs.python.org  Sun Aug  4 15:11:32 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 04 Aug 2013 13:11:32 +0000
Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular
	encoding
In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za>
Message-ID: <1375621892.59.0.970233813371.issue13612@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Thanks, Serhiy.

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

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

From report at bugs.python.org  Sun Aug  4 15:13:50 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 04 Aug 2013 13:13:50 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375622030.15.0.87312821702.issue18647@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Would it not be better to temporarily-fix the test rather than the code?

----------
nosy: +eli.bendersky

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

From report at bugs.python.org  Sun Aug  4 15:18:24 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Aug 2013 13:18:24 +0000
Subject: [issue18654] modernize mingw&cygwin compiler classes
In-Reply-To: <1375621500.14.0.511859388859.issue18654@psf.upfronthosting.co.za>
Message-ID: <1375622304.14.0.842844631619.issue18654@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

Proposed customization allow users to build extension module for windows with GNU compiler in all environments:
- native with installed official build of python for windows
- native either MSYS or CYGWIN enviroment and python build with GCC
- cross-build in cygwin using official build of python for windows
- cross-build in cygwin or linux with use of preset configuration from distribution
- cross-build in linux and cross build python with GCC

In addition patch allow user to build (native or cross) core modules with recent gnu compilers.

----------
keywords: +patch
Added file: http://bugs.python.org/file31152/0011-MINGW-compiler-customize-mingw-cygwin-compilers.patch

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

From report at bugs.python.org  Sun Aug  4 15:22:38 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Aug 2013 13:22:38 +0000
Subject: [issue18653] mingw-meta: build core modules
In-Reply-To: <1375619720.06.0.766677441218.issue18653@psf.upfronthosting.co.za>
Message-ID: <1375622558.44.0.176475598462.issue18653@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

This patch require "modernize mingw&cygwin compiler classes" now opened as separate issue18654 .

----------

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

From report at bugs.python.org  Sun Aug  4 15:29:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 13:29:41 +0000
Subject: [issue18652] Add itertools.coalesce
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375622981.3.0.387078682534.issue18652@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

def coalesce(iterable, default=None, pred=None):
        return next(filter(pred, iterable), default)

Are you sure you want add this one-line function to the itertools module rather then to recipes?

----------

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

From report at bugs.python.org  Sun Aug  4 15:34:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 13:34:33 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375623273.77.0.571238283172.issue18647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

All doctests affected.

----------

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

From report at bugs.python.org  Sun Aug  4 15:40:02 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Aug 2013 13:40:02 +0000
Subject: [issue17684] Skip tests in test_socket like testFDPassSeparate on OS X
In-Reply-To: <1365563429.51.0.176752850468.issue17684@psf.upfronthosting.co.za>
Message-ID: <3c7NX13WlFz7Ljs@mail.python.org>


Roundup Robot added the comment:

New changeset b7d764807343 by Charles-Francois Natali in branch '3.3':
Issue #17684: Fix some test_socket failures due to limited FD passing support
http://hg.python.org/cpython/rev/b7d764807343

----------

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

From report at bugs.python.org  Sun Aug  4 15:42:35 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 04 Aug 2013 13:42:35 +0000
Subject: [issue17684] Skip tests in test_socket like testFDPassSeparate on OS X
In-Reply-To: <1365563429.51.0.176752850468.issue17684@psf.upfronthosting.co.za>
Message-ID: <1375623755.19.0.399226990034.issue17684@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

> Charles-Francois: why did you commit this to default only, and not
> to 3.3?

I overlooked it (apparently, the issue was tagged 3.4 only, and I didn't double-check that the code was present in 3.3 as well).

Should be better now!

----------
versions: +Python 3.3

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

From report at bugs.python.org  Sun Aug  4 15:44:10 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 04 Aug 2013 13:44:10 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375623850.08.0.994035596655.issue18647@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Wonderfully terse, as usual. Can you be so kind to elaborate just a tiny bit more? Is the amount of doctests this affects so large that it's better to change the implementation? What are the plans for this "temporary" stage - is there an intention to fix the code "soon" and revert the disabling of this error check?

----------

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

From report at bugs.python.org  Sun Aug  4 15:49:14 2013
From: report at bugs.python.org (netrick)
Date: Sun, 04 Aug 2013 13:49:14 +0000
Subject: [issue18655] GUI apps take long to launch on Windows
Message-ID: <1375624154.73.0.44206476328.issue18655@psf.upfronthosting.co.za>


New submission from netrick:

On both Python 2 or 3, when you have GUI app (for example something in pygame or pyside or tk), when you launch it on Windows it takes about 4-6 seconds to display the Window for the first run. The next runs are faster, but only untill you reboot the PC.

The thing is that on Linux even when launching the script for first time ever, the GUI Window shows instantly. 

Something how Python displays windows on Windows is wrong, there is something that causes the serious lag.

You can see it very easy with IDLE. On Linux it launches instantly, on Windows XP on the same PC takes about 6 seconds to launch. I asked other people with different config and they have the same issue on Windows.

----------
components: Windows
messages: 194374
nosy: netrick
priority: normal
severity: normal
status: open
title: GUI apps take long to launch on Windows
type: performance
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Aug  4 15:49:49 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sun, 04 Aug 2013 13:49:49 +0000
Subject: [issue9148] os.execve puts process to background on windows
In-Reply-To: <1278156575.44.0.771660264126.issue9148@psf.upfronthosting.co.za>
Message-ID: <1375624189.67.0.560536146819.issue9148@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

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

From report at bugs.python.org  Sun Aug  4 15:51:15 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Aug 2013 13:51:15 +0000
Subject: [issue17605] mingw-meta: build interpeter core
In-Reply-To: <1364762524.12.0.901415822586.issue17605@psf.upfronthosting.co.za>
Message-ID: <1375624275.39.0.4926247619.issue17605@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

please follow build of core modules - issue18653 .

----------

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

From report at bugs.python.org  Sun Aug  4 15:55:36 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 04 Aug 2013 13:55:36 +0000
Subject: [issue18649] list2cmdline function in subprocess module handles \"
	sequence wrong
In-Reply-To: <1375567242.02.0.673942606159.issue18649@psf.upfronthosting.co.za>
Message-ID: <1375624536.33.0.907592090443.issue18649@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

Firstly, list2cmdline() takes a list as its argument, not a string:

  >>> import subprocess
  >>> print subprocess.list2cmdline([r'\"1|2\"'])
  \\\"1|2\\\"

But the problem with passing arguments to a batch file is that cmd.exe parses arguments differently from how normal executables do.  In particular, "|" is treated specially and "^" is used as an escape character.

If you define test.bat as

  @echo off
  echo "%1"

then

  subprocess.call(['test.bat', '1^|2'])

prints

  "1|2"

as expected.

This is a duplicate of http://bugs.python.org/issue1300.

----------
nosy: +sbt
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Sun Aug  4 15:57:51 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Aug 2013 13:57:51 +0000
Subject: [issue6335] Add support for mingw
In-Reply-To: <1245849042.65.0.399048729588.issue6335@psf.upfronthosting.co.za>
Message-ID: <1375624671.11.0.537455557017.issue6335@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

I would like to config that path to this issue is one of those for issue3871 - my patch for 2.6/2.7  enhanced by "?? (sorry I forgot user :( ) " for 3.0 .

Now as requested "all in one patch" is split and first set is listed in issue17605 "build interpeter core", second issue18653 "build core modules" plus modernization of mingw&cygwin compiler classes in scope of issue18654 .

----------

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

From report at bugs.python.org  Sun Aug  4 15:58:51 2013
From: report at bugs.python.org (Matt Joiner)
Date: Sun, 04 Aug 2013 13:58:51 +0000
Subject: [issue9148] os.execve puts process to background on windows
In-Reply-To: <1278156575.44.0.771660264126.issue9148@psf.upfronthosting.co.za>
Message-ID: <1375624731.19.0.00746921845303.issue9148@psf.upfronthosting.co.za>


Changes by Matt Joiner <anacrolix at gmail.com>:


----------
nosy: +anacrolix

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

From report at bugs.python.org  Sun Aug  4 16:00:14 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 04 Aug 2013 14:00:14 +0000
Subject: [issue17684] Skip tests in test_socket like testFDPassSeparate on OS X
In-Reply-To: <1365563429.51.0.176752850468.issue17684@psf.upfronthosting.co.za>
Message-ID: <1375624814.7.0.708861560535.issue17684@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Thanks!

----------

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

From report at bugs.python.org  Sun Aug  4 16:19:52 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Aug 2013 14:19:52 +0000
Subject: [issue9098] MSYS build fails with `S_IXGRP' undeclared
In-Reply-To: <1277729031.36.0.263470334817.issue9098@psf.upfronthosting.co.za>
Message-ID: <1375625992.14.0.676061575371.issue9098@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
nosy: +rpetrov

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

From report at bugs.python.org  Sun Aug  4 16:20:18 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Aug 2013 14:20:18 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1375626018.54.0.13473583101.issue4709@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
nosy: +rpetrov

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

From report at bugs.python.org  Sun Aug  4 16:22:31 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sun, 04 Aug 2013 14:22:31 +0000
Subject: [issue9148] os.execve puts process to background on windows
In-Reply-To: <1278156575.44.0.771660264126.issue9148@psf.upfronthosting.co.za>
Message-ID: <1375626151.15.0.817480810318.issue9148@psf.upfronthosting.co.za>


Piotr Dobrogost added the comment:

This is unexpected and makes people wonder what's going on. See http://stackoverflow.com/q/7004687/95735 and http://stackoverflow.com/q/7264571/95735.

----------

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

From report at bugs.python.org  Sun Aug  4 16:23:42 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 04 Aug 2013 14:23:42 +0000
Subject: [issue18652] Add itertools.coalesce
In-Reply-To: <1375622981.3.0.387078682534.issue18652@psf.upfronthosting.co.za>
Message-ID: <EAE0DFF2-2FF2-4186-8661-C080BCC895CE@ox.cx>


Hynek Schlawack added the comment:

> def coalesce(iterable, default=None, pred=None):
>        return next(filter(pred, iterable), default)
> 
> Are you sure you want add this one-line function to the itertools module rather then to recipes?

Well, for many ? including me ? it would mean to have this one-line function in every other project or a PyPI dependency.  I?m certain there are other short but useful functions in the stdlib.

----------

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

From report at bugs.python.org  Sun Aug  4 16:24:23 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Aug 2013 14:24:23 +0000
Subject: [issue15315] Can't build Python extension with mingw32 on Windows
In-Reply-To: <1341895923.16.0.599445307566.issue15315@psf.upfronthosting.co.za>
Message-ID: <1375626263.73.0.611461841887.issue15315@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
nosy: +rpetrov

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

From report at bugs.python.org  Sun Aug  4 16:39:06 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sun, 04 Aug 2013 14:39:06 +0000
Subject: [issue18649] list2cmdline function in subprocess module handles \"
	sequence wrong
In-Reply-To: <1375567242.02.0.673942606159.issue18649@psf.upfronthosting.co.za>
Message-ID: <1375627146.6.0.162138756983.issue18649@psf.upfronthosting.co.za>


Piotr Dobrogost added the comment:

I think you're missing the point. The implementation is wrong as it does not do what documentation says which is "A double quotation mark preceded by a backslash is interpreted as a literal double quotation mark." How the output of list2cmdline interacts with the cmd.exe is another issue (It just happens here that if implementation of list2cmdline were in line with its documentation then there wouldn't be any subsequent problem with cmd.exe). Also issue 1300 is about escaping a pipe character (|) on the basis of how it's treated by cmd.exe and does not even refer to the docstring of list2cmdline function.

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

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

From report at bugs.python.org  Sun Aug  4 16:55:00 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 04 Aug 2013 14:55:00 +0000
Subject: [issue18655] GUI apps take long to launch on Windows
In-Reply-To: <1375624154.73.0.44206476328.issue18655@psf.upfronthosting.co.za>
Message-ID: <1375628100.26.0.199439033384.issue18655@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Can you provide a short script that reproduces this problem?
AFAIK, Python doesn't display windows, the tcl/pygame libraries' C code creates the windows.

----------
nosy: +Ramchandra Apte

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

From report at bugs.python.org  Sun Aug  4 17:20:55 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Aug 2013 15:20:55 +0000
Subject: [issue2445] Use The CygwinCCompiler Under Cygwin
In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za>
Message-ID: <1375629655.25.0.52757906739.issue2445@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

Hi, 
Now issue18654 "modernize mingw&cygwin compiler classes" contain enhancement that could be reused by this issue: patch "0007-MINGW-compiler-cygwin-provides-its-own-C-runtime.patch
" from archive , i.e. lets avoid change in get_msvcr() that return. Mingw is also impacted but is addresses in another patches.  As separate patch is 'compiler customization' -  more advanced version then proposed by Jeevan Varshney (jayvee)

A separate issue18634 "find import library" address .dll.a suffix based on existing distutil functionality.

Also issue18633 "Mingw32CCompiler as default compiler for mingw* build" adds same fixes from unix compiler class into Cygwin one - ref '# Chop off the drive'

So with above I think that cygwin compiler could be switched back from unix to own.

----------

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

From report at bugs.python.org  Sun Aug  4 17:42:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Aug 2013 15:42:42 +0000
Subject: [issue18635] Enum sets _member_type_ to instantiated values but not
	the class
In-Reply-To: <1375472056.62.0.564467694147.issue18635@psf.upfronthosting.co.za>
Message-ID: <3c7RFZ0Qnxz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset b034418e840b by Ethan Furman in branch 'default':
Close #18635: Move class level private attribute from instance to class.
http://hg.python.org/cpython/rev/b034418e840b

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

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

From report at bugs.python.org  Sun Aug  4 17:42:49 2013
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Sun, 04 Aug 2013 15:42:49 +0000
Subject: [issue18418] Thread.isAlive() sometimes True after fork
In-Reply-To: <1375427255.41.0.51637343076.issue18418@psf.upfronthosting.co.za>
Message-ID: <CAFRUCtZ4FsGKgct0eproB0z9+qw2PchTAz2e-W2npnmn0JgvsQ@mail.gmail.com>


A. Jesse Jiryu Davis added the comment:

I'm back from a Zen retreat--no email!--will address your comments
momentarily.

On Fri, Aug 2, 2013 at 3:07 AM, Charles-Fran?ois Natali <
report at bugs.python.org> wrote:

>
> Charles-Fran?ois Natali added the comment:
>
> I've posted another review (not sure you receive notifications).
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue18418>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sun Aug  4 17:50:03 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Aug 2013 15:50:03 +0000
Subject: [issue18624] Add alias for iso-8859-8-i which is the same as
	iso-8859-8
In-Reply-To: <1375398269.06.0.0330535739148.issue18624@psf.upfronthosting.co.za>
Message-ID: <1375631403.72.0.503798944447.issue18624@psf.upfronthosting.co.za>


R. David Murray added the comment:

This issue is actually about adding the aliases to the codecs module.  I'm not entirely sure at this point what the canonical character set name should be for email output (which is what the ALIASES table controls).

----------

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

From report at bugs.python.org  Sun Aug  4 17:50:59 2013
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Sun, 04 Aug 2013 15:50:59 +0000
Subject: [issue18418] Thread.isAlive() sometimes True after fork
In-Reply-To: <1373408030.66.0.77258289483.issue18418@psf.upfronthosting.co.za>
Message-ID: <1375631459.92.0.484362556263.issue18418@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

New patch for 3.3 branch after Charles-Fran?ois's critique: use _enumerate() where appropriate, and join the test thread before finishing the test.

----------
Added file: http://bugs.python.org/file31153/issue18418-3.patch

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

From report at bugs.python.org  Sun Aug  4 18:09:59 2013
From: report at bugs.python.org (netrick)
Date: Sun, 04 Aug 2013 16:09:59 +0000
Subject: [issue18655] GUI apps take long to launch on Windows
In-Reply-To: <1375624154.73.0.44206476328.issue18655@psf.upfronthosting.co.za>
Message-ID: <1375632599.1.0.836067329197.issue18655@psf.upfronthosting.co.za>


netrick added the comment:

The simplest way to reproduce it is:

1) Reboot your PC
2) Launch IDLE (pre-installed with Python)
3) Look how long it takes to launch and then compare that with instant launch on Linux

----------

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

From report at bugs.python.org  Sun Aug  4 18:12:55 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Aug 2013 16:12:55 +0000
Subject: [issue18649] list2cmdline function in subprocess module handles \"
	sequence wrong
In-Reply-To: <1375567242.02.0.673942606159.issue18649@psf.upfronthosting.co.za>
Message-ID: <1375632775.42.0.0798050769629.issue18649@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is a only a duplicate of issue 1300 in the sense that that issue points out that list2cmdline has nothing to do with passing/quoting strings for cmd.exe.

list2cmdline is an internal function of the subprocess module.  Its docstring documents the MS C quoting rules, *not* the input quoting rules.  So its output is correct according to its doc string.  If you pass ["test.bat", r'\"1|2\"'] to Popen using Richard's version of test.bat, you should get

  \"1|2\"

as the output, which would be correct, since that is what you passed in as the argument to test.bat in the Popen call.  The point is that the arguments specified in the list (shell=False) Popen call is supposed to be exactly what arguments get passed to the called program, and list2cmdline takes care of the MS C quoting to make that happen. (I don't use Windows much, so it is a bit of a pain for me to confirm the above example, but I'm nearly certain it will work as I say, modulo whatever quoting rule 'echo' uses for output.)

----------
components: +Benchmarks -Library (Lib)
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sun Aug  4 18:18:29 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Aug 2013 16:18:29 +0000
Subject: [issue18649] list2cmdline function in subprocess module handles \"
	sequence wrong
In-Reply-To: <1375567242.02.0.673942606159.issue18649@psf.upfronthosting.co.za>
Message-ID: <1375633109.3.0.838343956296.issue18649@psf.upfronthosting.co.za>


R. David Murray added the comment:

The first line above is incomplete.  I meant that issue 1300 is only a duplicate in the sense that it points out that list2cmdline implements the MS C quoting rules, *not* the cmd.exe quoting rules.

----------

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

From report at bugs.python.org  Sun Aug  4 18:21:56 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 04 Aug 2013 16:21:56 +0000
Subject: [issue18649] list2cmdline function in subprocess module handles \"
	sequence wrong
In-Reply-To: <1375567242.02.0.673942606159.issue18649@psf.upfronthosting.co.za>
Message-ID: <1375633316.16.0.52863653465.issue18649@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> I think you're missing the point. The implementation is wrong as it 
> does not do what documentation says which is "A double quotation mark 
> preceded by a backslash is interpreted as a literal double quotation 
> mark."

That docstring describes how the string returned by list2cmdline() is interpreted by the MS C runtime.  I assume you mean this bit:

    3) A double quotation mark preceded by a backslash is
       interpreted as a literal double quotation mark.

This looks correct to me: it implies that list2cmdline() must convert a double quotation mark to a double quotation mark preceded by a backslash.  e.g.

  >>> print(subprocess.list2cmdline(['"']))
  \"

> How the output of list2cmdline interacts with the cmd.exe is another 
> issue (It just happens here that if implementation of list2cmdline were 
> in line with its documentation then there wouldn't be any subsequent 
> problem with cmd.exe).

As I said, list2cmdline() behaves as expected.  Whatever else happens, "|" must be escaped with "^" or else cmd will interpret it specially.

----------

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

From report at bugs.python.org  Sun Aug  4 18:31:00 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Aug 2013 16:31:00 +0000
Subject: [issue18652] Add itertools.coalesce
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375633860.29.0.0162642167132.issue18652@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm not going to object to the name, since I see that it is used elsewhere in programming for the proposed meaning.  But allow me to rant about the corruption of the English language here.  To me, "coalesce" should involve a computation based on all of the elements of a list, not just picking out the first non-false value.

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

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

From report at bugs.python.org  Sun Aug  4 18:39:09 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Aug 2013 16:39:09 +0000
Subject: [issue18649] list2cmdline function in subprocess module handles \"
	sequence wrong
In-Reply-To: <1375567242.02.0.673942606159.issue18649@psf.upfronthosting.co.za>
Message-ID: <1375634349.39.0.801761082746.issue18649@psf.upfronthosting.co.za>


R. David Murray added the comment:

The list form of Popen should never be used with shell=True.

It would be very good if someone would propose a 'cmd.exe quote' function for the stdlib.

But both of these points don't have anything to do with this issue, as far as I can see :)

----------

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

From report at bugs.python.org  Sun Aug  4 18:52:25 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 04 Aug 2013 16:52:25 +0000
Subject: [issue18484] No unit test for iso2time function from http.cookiejar
	module
In-Reply-To: <1374079077.48.0.0605853512742.issue18484@psf.upfronthosting.co.za>
Message-ID: <1375635145.81.0.0969913283295.issue18484@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

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

From report at bugs.python.org  Sun Aug  4 18:55:25 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 04 Aug 2013 16:55:25 +0000
Subject: [issue18656] setting function.__name__ doesn't affect repr()
Message-ID: <1375635325.22.0.0227611021818.issue18656@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

In Python 3.2 and earlier:

>>> def f(): pass
...
>>> f.__name__ = 'g'
>>> f
<function g at 0x100487628>

However in Python 3.3 and later, the last line shows 'f' instead of 'g'.

----------
components: Interpreter Core
messages: 194394
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: setting function.__name__ doesn't affect repr()
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Aug  4 19:02:50 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Aug 2013 17:02:50 +0000
Subject: [issue18656] setting function.__name__ doesn't affect repr()
In-Reply-To: <1375635325.22.0.0227611021818.issue18656@psf.upfronthosting.co.za>
Message-ID: <1375635770.29.0.871009922958.issue18656@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I guess this is a direct consequence of PEP 3155 [1].  From the PEP:

"""
The repr() and str() of functions and classes is modified to use __qualname__ rather than __name__.
"""

[1] http://www.python.org/dev/peps/pep-3155/

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

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

From report at bugs.python.org  Sun Aug  4 19:11:13 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 04 Aug 2013 17:11:13 +0000
Subject: [issue18656] setting function.__name__ doesn't affect repr()
In-Reply-To: <1375635325.22.0.0227611021818.issue18656@psf.upfronthosting.co.za>
Message-ID: <1375636273.47.0.64137214429.issue18656@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Sun Aug  4 19:12:08 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Aug 2013 17:12:08 +0000
Subject: [issue18656] setting function.__name__ doesn't affect repr()
In-Reply-To: <1375635325.22.0.0227611021818.issue18656@psf.upfronthosting.co.za>
Message-ID: <1375636328.82.0.550513315433.issue18656@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Python 3.4.0a0 (default:62658d9d8926+, Aug  1 2013, 23:05:18) 
[GCC 4.4.1 20090725 (Red Hat 4.4.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def func(): pass
... 
>>> func
<function func at 0xb7698a54>

>>> func.__qualname__="PEP 3155"
>>> func
<function PEP 3155 at 0xb7698a54>

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

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

From report at bugs.python.org  Sun Aug  4 19:19:27 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 04 Aug 2013 17:19:27 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375636767.51.0.973205058605.issue18647@psf.upfronthosting.co.za>


Tim Peters added the comment:

Serhiy, I don't see the regexp '(?:.*$\n?)*' anywhere in doctest.py.  Are you talking about the _EXAMPLE_RE regexp?  That's the closest I see.

If that's the case, the "nothing to repeat" error is incorrect:  _EXAMPLE_RE also contains a negative lookahead assertion '(?![ ]*$)' to ensure that the later '.*$\n?' part never tries to match an empty string.

That said, it takes some intelligence to realize that the negative lookahead assertion prevents repeating an empty match in this regexp, so it may not be easy to fix this false positive.

A compromise may be to replace

.*$\n?

with

.+$\n? | .*$\n

Both branches then "obviously" consume at least one character.

----------

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

From report at bugs.python.org  Sun Aug  4 19:24:59 2013
From: report at bugs.python.org (Matt McClure)
Date: Sun, 04 Aug 2013 17:24:59 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1375637099.36.0.102156383511.issue11798@psf.upfronthosting.co.za>


Matt McClure added the comment:

Michael Foord <fuzzyman <at> voidspace.org.uk> writes:
> On 2 Aug 2013, at 19:19, Antoine Pitrou <solipsis <at> pitrou.net> wrote:
> > The patch is basically ready for commit, except for a possible doc
> > addition, no?
> 
> Looks to be the case, reading the patch it looks fine. I'm currently on
> holiday until Monday. If anyone is motivated to do the docs too and 
> commit that would be great. Otherwise I'll get to it on my return.

It looks like the patch is based on what will become 3.4. Would backporting it to 2.7 be feasible?  What's involved in doing so?

I took a crack at the docs. I'm attaching an updated patch.

----------
nosy: +matthewlmclure

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

From report at bugs.python.org  Sun Aug  4 19:25:37 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Aug 2013 17:25:37 +0000
Subject: [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1375637137.73.0.61232713083.issue8865@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Aug  4 19:25:57 2013
From: report at bugs.python.org (Matt McClure)
Date: Sun, 04 Aug 2013 17:25:57 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1375637157.96.0.923474031023.issue11798@psf.upfronthosting.co.za>


Changes by Matt McClure <matthewlmcclure at gmail.com>:


Added file: http://bugs.python.org/file31154/11798-20130803-matthewlmcclure.patch

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

From report at bugs.python.org  Sun Aug  4 19:27:02 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Aug 2013 17:27:02 +0000
Subject: [issue18651] test failures on KFreeBSD
In-Reply-To: <1375610825.98.0.456814475805.issue18651@psf.upfronthosting.co.za>
Message-ID: <1375637222.49.0.0722594377576.issue18651@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Aug  4 19:35:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 17:35:34 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375637734.65.0.522417415939.issue18647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The doctest engine uses a regexp which contains subpattern which now considered as illegal be the regexp engine (due to unlucky coincidence MAXREPEAT == sys.maxsize on 32-bit platforms). We should rewrite the _simple() function in the re module to be more smart. But if this assumption is correct and this subpattern is really dangerous we should also rewrite a regular expression in the doctest module. In any case we should fix SubPattern.getwidth() so that the behavior on 32-bit and 64-bit platforms should be the same.

----------

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

From report at bugs.python.org  Sun Aug  4 19:37:09 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 04 Aug 2013 17:37:09 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375637829.49.0.644900123275.issue18647@psf.upfronthosting.co.za>


Tim Peters added the comment:

Serhiy, I'm asking you to be very explicit about which regexp in doctest.py you're talking about.  If you're talking about the _EXAMPLE_RE regexp, I already explained what's going on with that.  If you're talking about some other regexp, I have no idea which one you're talking about.

----------

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

From report at bugs.python.org  Sun Aug  4 19:48:43 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 04 Aug 2013 17:48:43 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375638523.87.0.312436314913.issue18264@psf.upfronthosting.co.za>


Ethan Furman added the comment:

This patch handles both float and int subclasses, and includes fixes/improvements from the review.

----------
Added file: http://bugs.python.org/file31155/issue18264.stoneleaf.02.patch

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

From report at bugs.python.org  Sun Aug  4 20:05:27 2013
From: report at bugs.python.org (Madison May)
Date: Sun, 04 Aug 2013 18:05:27 +0000
Subject: [issue18656] setting function.__name__ doesn't affect repr()
In-Reply-To: <1375635325.22.0.0227611021818.issue18656@psf.upfronthosting.co.za>
Message-ID: <1375639527.14.0.617787396713.issue18656@psf.upfronthosting.co.za>


Madison May added the comment:

Yup, here are the relevant lines of the diff for PEP 3155:

@@ -568,7 +607,7 @@
 func_repr(PyFunctionObject *op)
 {
     return PyUnicode_FromFormat("<function %U at %p>",
-                               op->func_name, op);
+                               op->func_qualname, op);
 }

----------
nosy: +madison.may

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

From report at bugs.python.org  Sun Aug  4 20:11:14 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 04 Aug 2013 18:11:14 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375639874.31.0.371351313402.issue18264@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Forgot to add float tests.  Included in this patch.

----------
Added file: http://bugs.python.org/file31156/issue18264.stoneleaf.03.patch

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

From report at bugs.python.org  Sun Aug  4 20:12:40 2013
From: report at bugs.python.org (Wes Turner)
Date: Sun, 04 Aug 2013 18:12:40 +0000
Subject: [issue16692] Support TLS 1.1 and TLS 1.2
In-Reply-To: <1355592665.89.0.539973629387.issue16692@psf.upfronthosting.co.za>
Message-ID: <1375639960.34.0.673518586683.issue16692@psf.upfronthosting.co.za>


Wes Turner added the comment:

http://docs.python.org/3.4/whatsnew/3.4.html#ssl

re: Backporting to Python 2.7: maybe something like:

backports.ssl (like backports.ssl_match_hostname)

https://pypi.python.org/pypi/backports/

----------
nosy: +westurner

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

From report at bugs.python.org  Sun Aug  4 20:22:59 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 04 Aug 2013 18:22:59 +0000
Subject: [issue11033] ElementTree.fromstring doesn't work with Unicode
In-Reply-To: <1296173256.62.0.363094614198.issue11033@psf.upfronthosting.co.za>
Message-ID: <1375640579.77.0.983892341274.issue11033@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


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

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

From report at bugs.python.org  Sun Aug  4 20:25:41 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sun, 04 Aug 2013 18:25:41 +0000
Subject: [issue18649] list2cmdline function in subprocess module handles \"
	sequence wrong
In-Reply-To: <1375567242.02.0.673942606159.issue18649@psf.upfronthosting.co.za>
Message-ID: <1375640741.09.0.582900742409.issue18649@psf.upfronthosting.co.za>


Piotr Dobrogost added the comment:

The docstring starts with this statement
"Translate a sequence of arguments into a command line string, using the same rules as the MS C runtime:"
which clearly makes the impression that function list2cmdline uses the same rules as the MS C runtime. However after reading comments in this issue I believe I misunderstood the true meaning as the docstring is highly misleading. According to your comments, the word "using" was meant to pertain to the "command line string" (which is the output of the list2cmdline function) and _not_ to the translation phase itself. This makes sense taking into account the flow of events which is; a list of arguments -> list2cmdline -> CreateProcess.

----------
components: +Library (Lib) -Benchmarks
resolution: invalid -> 
status: closed -> open

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

From report at bugs.python.org  Sun Aug  4 20:26:42 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sun, 04 Aug 2013 18:26:42 +0000
Subject: [issue18649] list2cmdline function in subprocess module handles \"
	sequence wrong
In-Reply-To: <1375567242.02.0.673942606159.issue18649@psf.upfronthosting.co.za>
Message-ID: <1375640802.05.0.975039140965.issue18649@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


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

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

From report at bugs.python.org  Sun Aug  4 20:31:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 18:31:38 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375641098.52.0.926313515714.issue18647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Serhiy, I don't see the regexp '(?:.*$\n?)*' anywhere in doctest.py.  Are you talking about the _EXAMPLE_RE regexp?  That's the closest I see.

Yes, it is. In my previous message I answered Eli.

> If that's the case, the "nothing to repeat" error is incorrect:  _EXAMPLE_RE also contains a negative lookahead assertion '(?![ ]*$)' to ensure that the later '.*$\n?' part never tries to match an empty string.

Thank you for explanation. Unlucky the getwidth() method is not smart enough to detect that minimal length of matched string is not 0. We should made either the getwidth() method or the _simple() function (or both) more smart.

> A compromise may be to replace
> .*$\n?
> with
> .+$\n? | .*$\n

I'm sure similar patterns are used in third-party code. We shouldn't break them, therefore we should fix _simple()/getwidth().

----------

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

From report at bugs.python.org  Sun Aug  4 20:32:12 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Aug 2013 18:32:12 +0000
Subject: [issue18649] list2cmdline function in subprocess module handles \"
	sequence wrong
In-Reply-To: <1375567242.02.0.673942606159.issue18649@psf.upfronthosting.co.za>
Message-ID: <1375641132.2.0.440768711693.issue18649@psf.upfronthosting.co.za>


R. David Murray added the comment:

"Using the same rules as the MS C runtime" means that, given a sequence (list) of arguments, create a string that uses the same quoting that the MS C runtime uses.  That is, if you have a sequence of arguments in a C program, and you want to call another windows program, you quote that sequence into a string using the same rules that list2cmdline uses.

Can you suggest a wording for the doctring that would make this clearer?

----------

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

From report at bugs.python.org  Sun Aug  4 20:51:09 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sun, 04 Aug 2013 18:51:09 +0000
Subject: [issue18649] list2cmdline function in subprocess module handles \"
	sequence wrong
In-Reply-To: <1375567242.02.0.673942606159.issue18649@psf.upfronthosting.co.za>
Message-ID: <1375642269.35.0.502219727052.issue18649@psf.upfronthosting.co.za>


Piotr Dobrogost added the comment:

Sure, something like
"The purpose of this function is to construct a string which will be later interpreted by MS C runtime as denoting a sequence of arguments. Because of this the string is built in such a way as to preserve the original characters when interpreted by MS C runtime. For example a double quotation mark is preceded by the backslash so that MS C runtime would translate this back to the original double quotation mark according to its rules which are given below as a reference:"

----------

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

From report at bugs.python.org  Sun Aug  4 20:52:54 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Aug 2013 18:52:54 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <3c7WT15SJZzQr9@mail.python.org>


Roundup Robot added the comment:

New changeset f7c84ef35b00 by Alexander Belopolsky in branch 'default':
Fixes #8860: Round half-microseconds to even in the timedelta constructor.
http://hg.python.org/cpython/rev/f7c84ef35b00

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Aug  4 20:53:48 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 04 Aug 2013 18:53:48 +0000
Subject: [issue8860] Rounding in timedelta constructor is inconsistent with
	that in timedelta arithmetics
In-Reply-To: <1275323981.58.0.479401459542.issue8860@psf.upfronthosting.co.za>
Message-ID: <1375642428.38.0.950057731582.issue8860@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


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

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

From report at bugs.python.org  Sun Aug  4 21:31:04 2013
From: report at bugs.python.org (Madison May)
Date: Sun, 04 Aug 2013 19:31:04 +0000
Subject: [issue18657] Remove duplicate ACKS entries
Message-ID: <1375644664.94.0.607349544003.issue18657@psf.upfronthosting.co.za>


New submission from Madison May:

The title says it all.  I used collections.Counter to check for duplicates in ACKS and cleaned up a few double entries.

----------
assignee: docs at python
components: Documentation
messages: 194410
nosy: docs at python, madison.may
priority: normal
severity: normal
status: open
title: Remove duplicate ACKS entries
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Aug  4 21:34:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Aug 2013 19:34:22 +0000
Subject: [issue18657] Remove duplicate ACKS entries
In-Reply-To: <1375644664.94.0.607349544003.issue18657@psf.upfronthosting.co.za>
Message-ID: <1375644862.39.0.664010166967.issue18657@psf.upfronthosting.co.za>


R. David Murray added the comment:

Did you intend to attach a patch?

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

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

From report at bugs.python.org  Sun Aug  4 21:34:49 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 04 Aug 2013 19:34:49 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375644889.13.0.0630438600372.issue18647@psf.upfronthosting.co.za>


Tim Peters added the comment:

I'm afraid it's just too tricky for the code to deduce that a negative lookahead assertion can imply that a later match can't be empty.  But I don't know how smart the re compilation code already is ;-)

It occurs to me now that the doctest regexp could worm around this very easily, via replacing:

.*$\n?

with:

.+$\n?

The success of the negative lookahead assertion here doesn't _just_ imply that


.*$\n?

will match a non-empty string, it also implies that

.+$

will succeed (and so also that .+$\n? will succeed).

----------

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

From report at bugs.python.org  Sun Aug  4 21:38:43 2013
From: report at bugs.python.org (Madison May)
Date: Sun, 04 Aug 2013 19:38:43 +0000
Subject: [issue18657] Remove duplicate ACKS entries
In-Reply-To: <1375644664.94.0.607349544003.issue18657@psf.upfronthosting.co.za>
Message-ID: <1375645123.32.0.63816213465.issue18657@psf.upfronthosting.co.za>


Madison May added the comment:

Now with 100% more patch.  Thanks for the catch, David.

----------
keywords: +patch
Added file: http://bugs.python.org/file31157/ACKS_duplicates.patch

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

From report at bugs.python.org  Sun Aug  4 21:40:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Aug 2013 19:40:21 +0000
Subject: [issue18151] Idlelib: update to "with open ... except OSError" (in
	2.7, leave IOError)
In-Reply-To: <1370538152.36.0.501706446334.issue18151@psf.upfronthosting.co.za>
Message-ID: <3c7XWn1f5zz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset e450e85e2075 by Terry Jan Reedy in branch '3.3':
Issue #18151: Replace remaining Idle 'open...close' pairs with 'with open'.
http://hg.python.org/cpython/rev/e450e85e2075

New changeset 7f6661a90d02 by Terry Jan Reedy in branch '2.7':
Issue #18151: Replace remaining Idle 'open...close' pairs with 'with open'.
http://hg.python.org/cpython/rev/7f6661a90d02

----------

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

From report at bugs.python.org  Sun Aug  4 21:42:50 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Aug 2013 19:42:50 +0000
Subject: [issue18151] Idlelib: update to "with open ... except OSError" (in
	2.7, leave IOError)
In-Reply-To: <1370538152.36.0.501706446334.issue18151@psf.upfronthosting.co.za>
Message-ID: <1375645370.16.0.935292262736.issue18151@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Patch looked good, so I backported to 2.7 (attached, in case there are problems) and pushed.

----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
Added file: http://bugs.python.org/file31158/idle_with_open-27.patch

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

From report at bugs.python.org  Sun Aug  4 21:50:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Aug 2013 19:50:21 +0000
Subject: [issue18657] Remove duplicate ACKS entries
In-Reply-To: <1375644664.94.0.607349544003.issue18657@psf.upfronthosting.co.za>
Message-ID: <3c7XlJ3CgvzS7H@mail.python.org>


Roundup Robot added the comment:

New changeset 2ec323dadca2 by R David Murray in branch '3.3':
#18657: remove duplicate entries from Misc/ACKS.
http://hg.python.org/cpython/rev/2ec323dadca2

New changeset f4f81ebc3de9 by R David Murray in branch 'default':
Merge: #18657: remove duplicate entries from Misc/ACKS.
http://hg.python.org/cpython/rev/f4f81ebc3de9

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Aug  4 21:50:47 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 04 Aug 2013 19:50:47 +0000
Subject: [issue10427] 24:00 Hour in DateTime
In-Reply-To: <1289831880.43.0.381934582888.issue10427@psf.upfronthosting.co.za>
Message-ID: <1375645847.24.0.898731550616.issue10427@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
resolution:  -> rejected
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Aug  4 21:50:53 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Aug 2013 19:50:53 +0000
Subject: [issue18657] Remove duplicate ACKS entries
In-Reply-To: <1375644664.94.0.607349544003.issue18657@psf.upfronthosting.co.za>
Message-ID: <1375645853.18.0.234539329669.issue18657@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Madison.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 3.3 -Python 3.5

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

From report at bugs.python.org  Sun Aug  4 21:58:06 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 04 Aug 2013 19:58:06 +0000
Subject: [issue1764286] inspect.getsource does not work with decorated
	functions
Message-ID: <1375646286.59.0.463909604994.issue1764286@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
assignee: belopolsky -> 

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

From report at bugs.python.org  Sun Aug  4 22:05:32 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 04 Aug 2013 20:05:32 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>
Message-ID: <1375646732.92.0.0768296400094.issue10329@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Aug  4 22:14:30 2013
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 04 Aug 2013 20:14:30 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1375647270.14.0.24258950211.issue18606@psf.upfronthosting.co.za>


Daniel Stutzbach added the comment:

As the person originally trying to take the mean of timedelta objects, I'm personally fine with the workaround of:

py> m = statistics.mean([x.total_seconds() for x in data])
py> td(seconds=m)
datetime.timedelta(2, 43200)

At the time I was trying to take the mean of timedelta objects, even the total_seconds() method did not exist in the version of Python I was using.

On the flip side, wouldn't sum() work on timedelta objects if you simply removed the "isinstance(start, numbers.Number)" check?

----------
nosy: +stutzbach

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

From report at bugs.python.org  Sun Aug  4 22:44:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 20:44:48 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375649088.09.0.562915876874.issue18647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Agree. Here is a partial patch which fixes getwidth() and doctest regexp. But I don't know how to fix _simple(). Perhaps we should permanently remove the "nothing to repeat" check. It guards only against '(.*)*', but there are other methods to make regexp matching exponential (i.e. '(.?.?)*').

----------
keywords: +patch
Added file: http://bugs.python.org/file31159/issue18647.patch

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

From report at bugs.python.org  Sun Aug  4 22:50:08 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 04 Aug 2013 20:50:08 +0000
Subject: [issue18656] setting function.__name__ doesn't affect repr()
In-Reply-To: <1375635325.22.0.0227611021818.issue18656@psf.upfronthosting.co.za>
Message-ID: <1375649408.35.0.560469205439.issue18656@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Sorry. The actual problem reported was that the traceback uses the wrong name. I can still reproduce this in 3.4; attached is a repro.

----------
Added file: http://bugs.python.org/file31160/functools_wraps_oddity.py

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

From report at bugs.python.org  Sun Aug  4 22:58:43 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 Aug 2013 20:58:43 +0000
Subject: [issue18656] setting function.__name__ doesn't affect repr()
In-Reply-To: <1375635325.22.0.0227611021818.issue18656@psf.upfronthosting.co.za>
Message-ID: <1375649923.96.0.200834620091.issue18656@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

That's because argument error messages use the code's co_name rather than the functions. (This is a dupe of another bug about this that I can't find.)

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

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

From report at bugs.python.org  Sun Aug  4 23:02:27 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Aug 2013 21:02:27 +0000
Subject: [issue18656] setting function.__name__ doesn't affect repr()
In-Reply-To: <1375635325.22.0.0227611021818.issue18656@psf.upfronthosting.co.za>
Message-ID: <1375650147.22.0.984501782476.issue18656@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

http://bugs.python.org/issue4322 ?

----------

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

From report at bugs.python.org  Sun Aug  4 23:05:14 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 Aug 2013 21:05:14 +0000
Subject: [issue18656] setting function.__name__ doesn't affect repr()
In-Reply-To: <1375635325.22.0.0227611021818.issue18656@psf.upfronthosting.co.za>
Message-ID: <1375650314.57.0.705588577259.issue18656@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Exactly

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> function with modified __name__ uses original name when there's an arg error

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

From report at bugs.python.org  Sun Aug  4 23:05:51 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 04 Aug 2013 21:05:51 +0000
Subject: [issue4322] function with modified __name__ uses original name when
	there's an arg error
In-Reply-To: <1226645058.7.0.820357853432.issue4322@psf.upfronthosting.co.za>
Message-ID: <1375650351.04.0.243377842761.issue4322@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I think fixing this is a valid request.

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

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

From report at bugs.python.org  Sun Aug  4 23:08:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 21:08:03 +0000
Subject: [issue18652] Add itertools.coalesce
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375650483.17.0.00705482182738.issue18652@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Well, for many ? including me ? it would mean to have this one-line function in every other project or a PyPI dependency.

But why you want to have a separate function instead of just use two builtins?

----------

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

From report at bugs.python.org  Sun Aug  4 23:09:08 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 04 Aug 2013 21:09:08 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375650548.93.0.0911639721758.issue18647@psf.upfronthosting.co.za>


Tim Peters added the comment:

Matching an empty string an unbounded number of times isn't a case of exponential runtime, it's a case of infinite runtime, unless the regexp internals are smart enough to cut the search off (I don't know enough about re's internals to know whether it's smart enough to do so).

So it's worth catching at compile time if it can be caught.  Alas, regexps are so complicated I doubt it's possible to do so without false positives or false negatives short of major effort.

For now, at least the doctest part of the patch should be harmless ;-)

----------

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

From report at bugs.python.org  Sun Aug  4 23:15:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 21:15:42 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1375650942.56.0.714690407485.issue5845@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Do you know that the readline module first force rebind of TAB to insert-tab?

----------

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

From report at bugs.python.org  Sun Aug  4 23:25:26 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 04 Aug 2013 21:25:26 +0000
Subject: [issue18652] Add itertools.coalesce
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375651526.41.0.839819504509.issue18652@psf.upfronthosting.co.za>


Tim Peters added the comment:

FWIW, I like this.  It would be a nice addition to the itertools module. +1

The `key` argument should be renamed to `pred`, as others have said.

As to the name, I like "first_true".  Does what it says.  Plain "first" is misleading, and "coalesce" is both inscrutable and nearly impossible to spell ;-)

----------
nosy: +tim_one

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

From report at bugs.python.org  Sun Aug  4 23:26:54 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 04 Aug 2013 21:26:54 +0000
Subject: [issue18652] Add itertools.coalesce
In-Reply-To: <1375650483.17.0.00705482182738.issue18652@psf.upfronthosting.co.za>
Message-ID: <0E8EEC86-CB04-43EB-9697-E5985999C865@ox.cx>


Hynek Schlawack added the comment:

> But why you want to have a separate function instead of just use two builtins?

This question has been answered twice now, once from Nick ? please refer above.

It's a clunky and error-prone solution to a common problem. Maybe you can't emphasize because it's not a common problem to you but that doesn't make it less useful.

----------

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

From report at bugs.python.org  Sun Aug  4 23:27:16 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 04 Aug 2013 21:27:16 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1375651636.14.0.937422789581.issue11798@psf.upfronthosting.co.za>


Michael Foord added the comment:

This smells like a new feature to me (it's certainly a fairly significant change in behaviour) and isn't appropriate for backporting to 2.7.

It can however go into unittest2.

I agree with David that a destructive iteration using pop is more likely to cause backwards-compatibility issues.

----------

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

From report at bugs.python.org  Sun Aug  4 23:39:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 21:39:44 +0000
Subject: [issue18563] No unit test for yiq to rgb and rgb to yiq converting
	functions
In-Reply-To: <1374856220.88.0.555143792121.issue18563@psf.upfronthosting.co.za>
Message-ID: <1375652384.07.0.594665909204.issue18563@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is superseded by issue14323.

----------
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> Normalize math precision in RGB/YIQ conversion

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

From report at bugs.python.org  Sun Aug  4 23:44:37 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 04 Aug 2013 21:44:37 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1375652677.75.0.210814557582.issue11798@psf.upfronthosting.co.za>


Michael Foord added the comment:

The doc patch looks good, thanks Matt. I'll read it through properly before committing.

----------

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

From report at bugs.python.org  Sun Aug  4 23:52:22 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 04 Aug 2013 21:52:22 +0000
Subject: [issue4322] function with modified __name__ uses original name when
	there's an arg error
In-Reply-To: <1226645058.7.0.820357853432.issue4322@psf.upfronthosting.co.za>
Message-ID: <1375653142.85.0.503925716579.issue4322@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea
stage: committed/rejected -> needs patch

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

From report at bugs.python.org  Sun Aug  4 23:52:41 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 04 Aug 2013 21:52:41 +0000
Subject: [issue4322] function with modified __name__ uses original name when
	there's an arg error
In-Reply-To: <1226645058.7.0.820357853432.issue4322@psf.upfronthosting.co.za>
Message-ID: <1375653161.62.0.889486092852.issue4322@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
versions: +Python 3.4 -Python 3.0

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

From report at bugs.python.org  Mon Aug  5 00:23:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Aug 2013 22:23:34 +0000
Subject: [issue14323] Normalize math precision in RGB/YIQ conversion
In-Reply-To: <1331831977.5.0.174772346075.issue14323@psf.upfronthosting.co.za>
Message-ID: <1375655014.68.0.334448880497.issue14323@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which implements the FCC version of RGB/YIQ conversion.

----------
Added file: http://bugs.python.org/file31161/colorsys_yiq_fcc.patch

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

From report at bugs.python.org  Mon Aug  5 00:38:06 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 04 Aug 2013 22:38:06 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375655886.64.0.650319732849.issue18647@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

Suppose you have a repeated pattern, such as "(?:...)*" or "(?:...){0,100}".

If, after matching the subpattern, the text position hasn't changed, and none of the capture groups have changed, then there has been no progress, and the subpattern will be matched again with no more progress, unless the maximum count has been reached, at which point it'll continue with the remainder of the pattern. If there's no minimum count, then the subpattern will be matched repeatedly forever.

Therefore, what a repeat should do is not to attempt any more iterations if the text position hasn't changed and none of the capture groups have changed.

----------

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

From report at bugs.python.org  Mon Aug  5 01:01:47 2013
From: report at bugs.python.org (Ben Finney)
Date: Sun, 04 Aug 2013 23:01:47 +0000
Subject: [issue12645] test.support. import_fresh_module - incorrect doc
In-Reply-To: <1375360954.84.0.771246589439.issue12645@psf.upfronthosting.co.za>
Message-ID: <20130804230031.GB6856@benfinney.id.au>


Ben Finney added the comment:

On 01-Aug-2013, Eli Bendersky wrote:

> Ben, would you like to provide an updated patch?

Unfortunately, contributions are not accepted under the Apache Software
Foundation License (as I had thought), but also require assigning extra
privileges to the Python Software Foundation under a special agreement.

I'm not able to do this in good conscience, so it seems the Python Software
Foundation will reject my contribution.

----------

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

From report at bugs.python.org  Mon Aug  5 01:14:49 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Aug 2013 23:14:49 +0000
Subject: [issue18652] Add itertools.coalesce
In-Reply-To: <1375651526.41.0.839819504509.issue18652@psf.upfronthosting.co.za>
Message-ID: <CADiSq7f3+sJ5muchtrZBf8iemZ9PW9wm+NjSYDktLRve82dtKA@mail.gmail.com>


Nick Coghlan added the comment:

A wild timbot appears! :)

Tim Peters added the comment:
> As to the name, I like "first_true".  Does what it says.  Plain "first"
is misleading, and "coalesce" is both inscrutable and nearly impossible to
spell ;-)

A fair point, although skipping the underscore ("firsttrue" or "nexttrue")
would arguably be more consistent with other itertools names.

I guess it's over to Raymond now as module maintainer for a yes/docs
recipe/no response, and if one of the first two, the exact name used.

----------

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

From report at bugs.python.org  Mon Aug  5 01:15:01 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 04 Aug 2013 23:15:01 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375658101.08.0.84474177093.issue18647@psf.upfronthosting.co.za>


Tim Peters added the comment:

Matthew, yes, I agree that a regexp engine can be coded to be robust against unboundedly repeated matching of an empty string.  I don't know whether Python's current engine is so coded.  It's easy to trick the 2.7 engine into accepting regexps that do try to match an empty string endlessly, but across all I've tried none show "infinite loop" (or even slow) behavior.

----------

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

From report at bugs.python.org  Mon Aug  5 01:40:31 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 04 Aug 2013 23:40:31 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375659631.57.0.387013443587.issue18647@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

Python's current regex engine isn't so coded. That's the reason for the up-front check.

----------

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

From report at bugs.python.org  Mon Aug  5 01:46:34 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 04 Aug 2013 23:46:34 +0000
Subject: [issue18652] Add itertools.coalesce
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375659994.62.0.284910996846.issue18652@psf.upfronthosting.co.za>


Tim Peters added the comment:

> skipping the underscore ("firsttrue" or "nexttrue")
> would arguably be more consistent with other itertools names.

Like izip_longest and combinations_with_replacement? ;-)

I care about readability here more than consistency with the bulk of itertools names.  "first" ends with "t" and "true" begins with "t", which makes "firsttrue" an eyesore.  "first_true" strikes me as very easy to read, spell, remember and understand.

Offhand I don't know what "nexttrue" is supposed to mean (like "if that's supposed to mean the first true iterate, why didn't they say 'first' instead of 'next'?").

----------

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

From report at bugs.python.org  Mon Aug  5 01:54:31 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 04 Aug 2013 23:54:31 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375660471.42.0.388715986593.issue18647@psf.upfronthosting.co.za>


Tim Peters added the comment:

> Python's current regex engine isn't so coded. That's
> the reason for the up-front check.

It's peculiar then that nobody noticed before now that the check was so badly broken ;-)

Offhand, do you have an example that displays bad behavior in 2.7?  I'm curious because I didn't find one after half an hour of trying.

----------

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

From report at bugs.python.org  Mon Aug  5 02:04:45 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 05 Aug 2013 00:04:45 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
	iterable)
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375661085.94.0.825989015274.issue18652@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I concede Tim's point about itertools already using underscores where it improves readability of a name :)

So, the latest state of the proposal is to add the following, preferably directly to the module, but at least as a recipe in the itertools docs:

    def first_true(iterable, default=None, pred=None):
        """Returns the first true item in the iterable

        If no such item is found, returns *default*
        If *pred* is not None, returns the first item
        for which pred(item) is true.
        """
        return next(filter(pred, iterable), default)

----------
title: Add itertools.coalesce -> Add itertools.first_true (return first true item in iterable)

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

From report at bugs.python.org  Mon Aug  5 02:17:28 2013
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Mon, 05 Aug 2013 00:17:28 +0000
Subject: [issue18078] threading.Condition to allow notify on a specific waiter
In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za>
Message-ID: <1375661848.79.0.00989851660229.issue18078@psf.upfronthosting.co.za>


Jo?o Bernardo added the comment:

I've been thinking about returning a list on "wait_for_any", but that way you will not be able to implement "wait_for" using it!

"wait_for" will return False on timeouts while "wait_for_any" will return a list with some conditions(evaluates to True).

Also, "wait_for" will show the result of the predicate when there's no timeout. It may clash with the boolean value of the list in some cases.

Suggestions?

----------

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

From report at bugs.python.org  Mon Aug  5 03:48:09 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 05 Aug 2013 01:48:09 +0000
Subject: [issue18078] threading.Condition to allow notify on a specific waiter
In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za>
Message-ID: <1375667289.1.0.153864522958.issue18078@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, I don't support adding this functionality.  I don't see precedents for Condition Variables behaving this way in other languages.  Also, I don't think it is worth the added complexity, learning curve, and maintenance burden.  Condition variables are used as primitive for other mutexes and I think we ought to keep them somewhat simple.

If someone wants to notify a specific waiter, then they have other options  such as using a separate condition variable that shares the same underlying lock (much as the code in the queue module does).  That approach is easy to reason about.

----------

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

From report at bugs.python.org  Mon Aug  5 03:48:24 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 05 Aug 2013 01:48:24 +0000
Subject: [issue18658] Mercurial CPython log ticket link is broken
Message-ID: <1375667304.35.0.50370358918.issue18658@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Go to http://hg.python.org/cpython.

All ticket links (number preceded by #), such as #18567 refer to bugs in jython.

For example:
5 hours ago 	R David Murray 	Merge: #18657: remove duplicate entries from Misc/ACKS.default tip
5 hours ago 	R David Murray 	#18657: remove duplicate entries from Misc/ACKS.3.3

The "Merge" link refers to correct place. But "#18657" goes to http://bugs.jython.org/issue18657.

It happens to *all ticket links*.

----------
messages: 194444
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Mercurial CPython log ticket link is broken

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

From report at bugs.python.org  Mon Aug  5 04:08:23 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Aug 2013 02:08:23 +0000
Subject: [issue14323] Normalize math precision in RGB/YIQ conversion
In-Reply-To: <1331831977.5.0.174772346075.issue14323@psf.upfronthosting.co.za>
Message-ID: <1375668503.5.0.650552449635.issue14323@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Can you add a reference for the coefficients?

I believe

def test_main():
 test.support.run_unittest(ColorsysTest)

if __name__ == "__main__":
 test_main

has been and is being replaced in other test files with

if __name__ == "__main__":
 unittest.main

and should be here.

This should get a short What's New entry in the library section, something like

colorsys:
"The number of digits in the coefficients for the RGB -- YIQ conversions have been expanded so that they match the FCC NTSC versions. The change in results should be less than 1% and may better match results found elsewhere."

(You claim about the current rounding is not exactly correct. While .28*g rounds .277 rather than .274, the current .52*g rounds the non-FCC .523 rather than the FCC .5251. So I avoided making the claim in the suggested entry. It is not important.)

----------

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

From report at bugs.python.org  Mon Aug  5 07:12:36 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Aug 2013 05:12:36 +0000
Subject: [issue18658] Mercurial CPython log ticket link is broken
In-Reply-To: <1375667304.35.0.50370358918.issue18658@psf.upfronthosting.co.za>
Message-ID: <1375679556.26.0.323057123728.issue18658@psf.upfronthosting.co.za>


Ned Deily added the comment:

Sorry, I'm not seeing this behavior.  Is it still happening for you?

----------
nosy: +ned.deily

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

From report at bugs.python.org  Mon Aug  5 07:19:00 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 05 Aug 2013 05:19:00 +0000
Subject: [issue18651] test failures on KFreeBSD
In-Reply-To: <1375610825.98.0.456814475805.issue18651@psf.upfronthosting.co.za>
Message-ID: <1375679940.83.0.641525774891.issue18651@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I don't expect problems on OSX because of this.

However: the patch replaces support.anticipate_failure by unittest.skipIf and that seems wrong to me.

----------

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

From report at bugs.python.org  Mon Aug  5 07:26:07 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 05 Aug 2013 05:26:07 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1375680367.53.0.253377262217.issue18606@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

As noted before statistics.sum seems to have the same functionality as math.fsum. 

Statistics.add_partial, which does the majority of the work, also references the same cookbook recipe as the math.fsum documentation.

IMHO statistics.sum should be removed.

----------

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

From report at bugs.python.org  Mon Aug  5 07:33:19 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 05 Aug 2013 05:33:19 +0000
Subject: [issue18078] threading.Condition to allow notify on a specific waiter
In-Reply-To: <1375667289.1.0.153864522958.issue18078@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3OG2u00oo590xr0xYVWMy3k+oyEU9G0wbszyfM=hq==w@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> FWIW, I don't support adding this functionality.  I don't see precedents for
> Condition Variables behaving this way in other languages.  Also, I don't
> think it is worth the added complexity, learning curve, and maintenance
> burden.  Condition variables are used as primitive for other mutexes and I
> think we ought to keep them somewhat simple.
>
> If someone wants to notify a specific waiter, then they have other options
> such as using a separate condition variable that shares the same underlying
> lock (much as the code in the queue module does).  That approach is easy to
> reason about.

That's exactly what the point I was trying to make, but Raymond sums
it really nicely :-)

----------

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

From report at bugs.python.org  Mon Aug  5 08:17:49 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 05 Aug 2013 06:17:49 +0000
Subject: [issue18658] Mercurial CPython log ticket link is broken
In-Reply-To: <1375667304.35.0.50370358918.issue18658@psf.upfronthosting.co.za>
Message-ID: <1375683469.03.0.249375682567.issue18658@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Okay, it looks like it has been fixed. The format has changed as well.

Previously:
5 hours ago 	R David Murray 	Merge: #18657: remove duplicate entries from Misc/ACKS.default tip
5 hours ago 	R David Murray 	#18657: remove duplicate entries from Misc/ACKS.3.3

Now:
10 hours ago 	R David Murray 	Merge: #18657: remove duplicate entries from Misc/ACKS. [#18657] default
10 hours ago 	R David Murray 	#18657: remove duplicate entries from Misc/ACKS. [#18657] 3.3

Now we have separate link to ticket (inside the bracket) at the end of commit message, whereas previously it was inside the commit message.

I guess we can close this ticket as fixed.

----------

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

From report at bugs.python.org  Mon Aug  5 08:23:35 2013
From: report at bugs.python.org (Petr.Salinger)
Date: Mon, 05 Aug 2013 06:23:35 +0000
Subject: [issue18651] test failures on KFreeBSD
In-Reply-To: <1375610825.98.0.456814475805.issue18651@psf.upfronthosting.co.za>
Message-ID: <1375683815.87.0.631647656063.issue18651@psf.upfronthosting.co.za>


Petr.Salinger added the comment:

It is related to 

http://bugs.python.org/issue12958
http://bugs.python.org/issue17684

The second one changed support.anticipate_failure to unittest.skipIf

----------
nosy: +Petr.Salinger

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

From report at bugs.python.org  Mon Aug  5 08:54:54 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Aug 2013 06:54:54 +0000
Subject: [issue18532] hashlib.HASH objects should officially expose the hash
	name
In-Reply-To: <1374524940.42.0.582552143445.issue18532@psf.upfronthosting.co.za>
Message-ID: <3c7qV55tLCz7Llw@mail.python.org>


Roundup Robot added the comment:

New changeset 238c37e4c395 by Jason R. Coombs in branch 'default':
Issue 18532: Added tests and documentation to formally specify the .name attribute on hashlib objects.
http://hg.python.org/cpython/rev/238c37e4c395

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Aug  5 08:56:07 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 05 Aug 2013 06:56:07 +0000
Subject: [issue18532] hashlib.HASH objects should officially expose the hash
	name
In-Reply-To: <1374524940.42.0.582552143445.issue18532@psf.upfronthosting.co.za>
Message-ID: <1375685767.71.0.895129166301.issue18532@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I've confirmed the tests pass and the updated documentation renders nicely and without warnings. These changes now make the name attribute officially-supported and tested.

----------
resolution:  -> fixed

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

From report at bugs.python.org  Mon Aug  5 09:23:38 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 05 Aug 2013 07:23:38 +0000
Subject: [issue18658] Mercurial CPython log ticket link is broken
In-Reply-To: <1375667304.35.0.50370358918.issue18658@psf.upfronthosting.co.za>
Message-ID: <1375687418.28.0.300305978279.issue18658@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Wait, something weird is happening in CPython commits log website, http://hg.python.org/cpython .

These are the latest four commits.

age 	author 	description
45 hours ago 	Jason R. Coombs 	Issue 18532: Added tests and documentation to formally specify the .name attribute on hashlib objects.default tip
105 minutes ago 	Raymond Hettinger 	Silence compiler warning for unused declaration.2.7
11 hours ago 	R David Murray 	Merge: #18657: remove duplicate entries from Misc/ACKS. [#18657]
11 hours ago 	R David Murray 	#18657: remove duplicate entries from Misc/ACKS. [#18657]3.3

The "age" column is screwed up. 11 hours ago goes to 105 minutes ago then goes back to 45 hours ago.

----------

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

From report at bugs.python.org  Mon Aug  5 09:30:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Aug 2013 07:30:25 +0000
Subject: [issue18658] Mercurial CPython log ticket link is broken
In-Reply-To: <1375667304.35.0.50370358918.issue18658@psf.upfronthosting.co.za>
Message-ID: <1375687825.98.0.485006792172.issue18658@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This is a separate issue though, isn't it?
Have you tried to ctrl+f5 the page?

(Also this is probably something that should be reported to the Mercurial bug tracker, since -- unlike the issue links -- is not something we modified.)

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Mon Aug  5 09:34:21 2013
From: report at bugs.python.org (timm)
Date: Mon, 05 Aug 2013 07:34:21 +0000
Subject: [issue6057] sqlite3 error classes should be documented
In-Reply-To: <1242673346.43.0.948670169284.issue6057@psf.upfronthosting.co.za>
Message-ID: <1375688061.71.0.996753946862.issue6057@psf.upfronthosting.co.za>


timm added the comment:

I would find it useful to have the exception classes listed in the Python documentation rather than having to refer to two documents, but I don't have strong feelings on this.

Given that nobody has fixed this for 4 years, should we just close the ticket? I'd be happy to do the necessary work if this is something we want changed, but I don't want to prepare a patch for a ticket that's never going to go anywhere.

----------
nosy: +timm

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

From report at bugs.python.org  Mon Aug  5 09:38:11 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Aug 2013 07:38:11 +0000
Subject: [issue18658] Mercurial CPython log ticket link is broken
In-Reply-To: <1375667304.35.0.50370358918.issue18658@psf.upfronthosting.co.za>
Message-ID: <1375688291.03.0.767294845436.issue18658@psf.upfronthosting.co.za>


Ned Deily added the comment:

While it looks unusual, the commit list is fine.  It reflects what you see currently in a "hg log".  What happened is that someone imported an older local change set or something similar.  It's not always easy to tell from the log.

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

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

From report at bugs.python.org  Mon Aug  5 10:03:10 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 05 Aug 2013 08:03:10 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
Message-ID: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

There is test_precision in Lib/test_format.py which is not being unit tested.

Also, there is a unused variable inside test_precision.

Attached the patch to fix these problems.

----------
components: Tests
files: test_precision.patch
keywords: patch
messages: 194459
nosy: vajrasky
priority: normal
severity: normal
status: open
title: test_precision in test_format.py is not executed and has unused variable
versions: Python 3.4
Added file: http://bugs.python.org/file31162/test_precision.patch

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

From report at bugs.python.org  Mon Aug  5 10:20:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Aug 2013 08:20:13 +0000
Subject: [issue14323] Normalize math precision in RGB/YIQ conversion
In-Reply-To: <1331831977.5.0.174772346075.issue14323@psf.upfronthosting.co.za>
Message-ID: <1375690813.22.0.207825558113.issue14323@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Can you add a reference for the coefficients?

I have only link to Wikipedia which refers to Code of Federal Regulations ?73.682. This link (http://en.wikipedia.org/wiki/YIQ) already mentioned at the top of the file.

> (You claim about the current rounding is not exactly correct. While .28*g rounds .277 rather than .274, the current .52*g rounds the non-FCC .523 rather than the FCC .5251. So I avoided making the claim in the suggested entry. It is not important.)

A sum of coefficients in this line should be 0 (Q=0 for R=G=B).

Patch updated. I added a What's New entry and update to use of unittest.main(), rewrite rgb_to_yiq() in the form as in Wikipedia (it uses less multiplications) and write coefficients in yiq_to_rgb() with maximal precision (as calculated with Python).

----------
Added file: http://bugs.python.org/file31163/colorsys_yiq_fcc_2.patch

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

From report at bugs.python.org  Mon Aug  5 10:47:31 2013
From: report at bugs.python.org (Louis RIVIERE)
Date: Mon, 05 Aug 2013 08:47:31 +0000
Subject: [issue18660] os.read behavior on Linux
Message-ID: <1375692451.71.0.0379690285011.issue18660@psf.upfronthosting.co.za>


New submission from Louis RIVIERE:

A call to os.read that used to work on older Linux kernel, doesn't anymore with newer Linux kernel.
As a workaroud we can use libc.read (ctypes) instead of os.read.
But I feel like os.read should work, as it used to.

The code (and comments) can be seen here : http://code.activestate.com/recipes/576375-low-level-inotify-wrapper/

----------
components: IO
messages: 194461
nosy: dugres
priority: normal
severity: normal
status: open
title: os.read behavior on Linux
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Aug  5 11:24:53 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Aug 2013 09:24:53 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <1375694693.23.0.525123157738.issue18659@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Patch looks good to me.

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

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

From report at bugs.python.org  Mon Aug  5 11:30:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Aug 2013 09:30:41 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <3c7txs0J9Sz7LjX@mail.python.org>


Roundup Robot added the comment:

New changeset cfd875bcbe41 by Mark Dickinson in branch 'default':
Issue #18659: fix test_format test that wasn't being executed.  Thanks Vajrasky Kok for the patch.
http://hg.python.org/cpython/rev/cfd875bcbe41

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Aug  5 11:31:45 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Aug 2013 09:31:45 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <1375695105.48.0.984451405696.issue18659@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Fixed.  Thanks!

----------
assignee:  -> mark.dickinson
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Mon Aug  5 11:43:08 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 05 Aug 2013 09:43:08 +0000
Subject: [issue18661] Typo in grpmodule.c
Message-ID: <1375695788.15.0.911930238621.issue18661@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

I guess, there is a typo in Modules/grpmodule.c. See the patch below:

diff -r f4f81ebc3de9 Modules/grpmodule.c
--- a/Modules/grpmodule.c	Sun Aug 04 15:50:08 2013 -0400
+++ b/Modules/grpmodule.c	Mon Aug 05 17:40:33 2013 +0800
@@ -10,7 +10,7 @@
    {"gr_name", "group name"},
    {"gr_passwd", "password"},
    {"gr_gid", "group id"},
-   {"gr_mem", "group memebers"},
+   {"gr_mem", "group members"},
    {0}
 };

I am not sure whether the line after typo should be {0} or {0, 0}.

----------
assignee: docs at python
components: Documentation
messages: 194465
nosy: docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Typo in grpmodule.c
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug  5 11:53:44 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Aug 2013 09:53:44 +0000
Subject: [issue18661] Typo in grpmodule.c
In-Reply-To: <1375695788.15.0.911930238621.issue18661@psf.upfronthosting.co.za>
Message-ID: <1375696424.79.0.109270162138.issue18661@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

{0} is fine;  some compilers will warn about it, but I believe it's valid C.

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

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

From report at bugs.python.org  Mon Aug  5 11:57:37 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Aug 2013 09:57:37 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <1375696657.92.0.320978076187.issue18659@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Okay, that caused some buildbots to fail.  I'm going to back out the change until I have time to figure out what's going on.

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

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

From report at bugs.python.org  Mon Aug  5 12:00:08 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Aug 2013 10:00:08 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <3c7vbq65mmz7LkW@mail.python.org>


Roundup Robot added the comment:

New changeset 9bee1fd64ee6 by Mark Dickinson in branch 'default':
Issue #18659: Backed out changeset cfd875bcbe41 after buildbot failures.
http://hg.python.org/cpython/rev/9bee1fd64ee6

----------

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

From report at bugs.python.org  Mon Aug  5 12:01:42 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Aug 2013 10:01:42 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <1375696902.83.0.675838327294.issue18659@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Sample buildbot output here:

http://buildbot.python.org/all/builders/x86%20RHEL%206%203.x/builds/2485/steps/test/logs/stdio

Relevant snippet:

test_precision (test.test_format.FormatTest) ... FAIL

======================================================================
FAIL: test_precision (test.test_format.FormatTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.coghlan-redhat/build/Lib/test/test_format.py", line 338, in test_precision
    self.assertEqual(str(cm.exception), "precision too big")
AssertionError: 'Too many decimal digits in format string' != 'precision too big'
- Too many decimal digits in format string
+ precision too big


----------------------------------------------------------------------
Ran 5 tests in 0.011s

----------

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

From report at bugs.python.org  Mon Aug  5 12:35:01 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 05 Aug 2013 10:35:01 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <1375698901.01.0.0631110144547.issue18659@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Let me help you to debug this issue.

ethan at amiau:~/Documents/code/python/cpython$ cat /tmp/a.py
import sys

INT_MAX = sys.maxsize
f = 1.2
format(f, ".%sf" % (INT_MAX + 1))
ethan at amiau:~/Documents/code/python/cpython$ ./python /tmp/a.py
Traceback (most recent call last):
  File "/tmp/a.py", line 5, in <module>
    format(f, ".%sf" % (INT_MAX + 1))
ValueError: Too many decimal digits in format string
ethan at amiau:~/Documents/code/python/cpython$ cat /tmp/b.py
import sys

INT_MAX = 2147483647
f = 1.2
format(f, ".%sf" % (INT_MAX + 1))
ethan at amiau:~/Documents/code/python/cpython$ ./python /tmp/b.py
Traceback (most recent call last):
  File "/tmp/b.py", line 5, in <module>
    format(f, ".%sf" % (INT_MAX + 1))
ValueError: precision too big

My question is whether we should have different exception message for these two cases?

----------

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

From report at bugs.python.org  Mon Aug  5 12:47:12 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 05 Aug 2013 10:47:12 +0000
Subject: [issue18660] os.read behavior on Linux
In-Reply-To: <1375692451.71.0.0379690285011.issue18660@psf.upfronthosting.co.za>
Message-ID: <1375699632.55.0.249259847364.issue18660@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Mon Aug  5 12:48:30 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 05 Aug 2013 10:48:30 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <1375699710.11.0.122592826925.issue18659@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

For now, instead of hardcoding INT_MAX to 2147483647 in test, maybe we can use module:

>>> import IN
>>> IN.INT_MAX
2147483647

----------

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

From report at bugs.python.org  Mon Aug  5 14:34:48 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Aug 2013 12:34:48 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
	iterable)
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375706088.12.0.829778700774.issue18652@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

+1 on the name 'first_true'.  Does exactly what it says on the tin.

----------

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

From report at bugs.python.org  Mon Aug  5 14:48:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Aug 2013 12:48:39 +0000
Subject: [issue18515] zipfile._ZipDecryptor generates wasteful crc32 table on
	import
In-Reply-To: <1374331044.49.0.0628884037506.issue18515@psf.upfronthosting.co.za>
Message-ID: <1375706919.75.0.0292921714135.issue18515@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The objection to zipfile-no-crc32.patch is that binascii.crc32() and _crc32() have different signatures. binascii.crc32() accepts a byte object while _crc32() accepts a single integer. With packing this value into a bytes object _crc32() will be much slower.

As for zdlazy.patch, there is a proposed patch in issue10030 which speedups pure Python decryption. I'm afraid that with zdlazy.patch this path will lose a part of it's speedup.

----------

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

From report at bugs.python.org  Mon Aug  5 14:48:58 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 05 Aug 2013 12:48:58 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
	iterable)
In-Reply-To: <1375706088.12.0.829778700774.issue18652@psf.upfronthosting.co.za>
Message-ID: <D0A10576-4A32-4DDA-B513-45A8520B61BC@ox.cx>


Hynek Schlawack added the comment:

> +1 on the name 'first_true'.  Does exactly what it says on the tin.

I fully agree.

***

I assume what's missing now is a permission from Raymond to mess with his turf?

----------

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

From report at bugs.python.org  Mon Aug  5 14:54:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Aug 2013 12:54:43 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <1375707283.61.0.15197806606.issue18659@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +haypo, serhiy.storchaka

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

From report at bugs.python.org  Mon Aug  5 15:08:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Aug 2013 13:08:04 +0000
Subject: [issue13083] _sre: getstring() releases the buffer before using it
In-Reply-To: <1317433851.47.0.137164360321.issue13083@psf.upfronthosting.co.za>
Message-ID: <1375708084.73.0.696421650655.issue13083@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Segfault when using re.finditer over mmap

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

From report at bugs.python.org  Mon Aug  5 15:08:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Aug 2013 13:08:38 +0000
Subject: [issue13083] _sre: getstring() releases the buffer before using it
In-Reply-To: <1317433851.47.0.137164360321.issue13083@psf.upfronthosting.co.za>
Message-ID: <1375708118.55.0.134127289846.issue13083@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Agree.

----------

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

From report at bugs.python.org  Mon Aug  5 15:12:19 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Aug 2013 13:12:19 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <1375708339.01.0.852459609936.issue18659@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The IN module must not be used, it is hardcoded and never regenerated.

----------

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

From report at bugs.python.org  Mon Aug  5 15:16:03 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Aug 2013 13:16:03 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <1375708563.75.0.0112694018516.issue18659@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I added the test in the following commit:

changeset:   84266:ef5175d08e7e
branch:      3.3
parent:      84263:7ecca1a98220
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Sun Jun 23 14:54:30 2013 +0200
files:       Lib/test/test_format.py Misc/NEWS Python/formatter_unicode.c
description:
Issue #18137: Detect integer overflow on precision in float.__format__() and
complex.__format__().

----------

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

From report at bugs.python.org  Mon Aug  5 15:26:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Aug 2013 13:26:11 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <1375709171.21.0.676539356568.issue18659@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

We have _testcapi.INT_MAX.

I guess different exceptions raised on 64-bit platform. First parser checks that a number can be represented as Py_ssize_t (i.e. <= PY_SSIZE_T_MAX). Here "Too many decimal digits in format string" can be raised. Then precision passed to internal function which accepts int and checked to be <= INT_MAX before cast to int. Here "precision too big" can be raised.

----------

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

From report at bugs.python.org  Mon Aug  5 15:39:29 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 05 Aug 2013 13:39:29 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <1375709969.51.0.403840413799.issue18659@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

For the passers-by who want to help:

The "precision too big" exception is raised in Python/formatter_unicode.c line 1168 and 1002.

The "Too many decimal digits..." exception is raised in Python/formatter_unicode.c line 71.

So the question is whether it is beneficial to differentiate the exception message. If not, we can change the exception message or test whether the digit passes INT_MAX first before checking with sys.max_size. If yes, we need to add test case for sys.max_size and use _testcapi.INT_MAX for current unit test case.

----------

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

From report at bugs.python.org  Mon Aug  5 16:08:50 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Aug 2013 14:08:50 +0000
Subject: [issue18273] Simplify calling and discovery of json test package
In-Reply-To: <1371760220.13.0.623339240586.issue18273@psf.upfronthosting.co.za>
Message-ID: <1375711730.18.0.155931361034.issue18273@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I like the patch.
Can you make "./python Lib/test/test_json/" work too?  Currently it doesn't seem to work (it works for e.g. "./python Lib/test/test_email/").

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

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

From report at bugs.python.org  Mon Aug  5 16:15:46 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Aug 2013 14:15:46 +0000
Subject: [issue14323] Normalize math precision in RGB/YIQ conversion
In-Reply-To: <1331831977.5.0.174772346075.issue14323@psf.upfronthosting.co.za>
Message-ID: <1375712146.64.0.429621913718.issue14323@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

LGTM.

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

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

From report at bugs.python.org  Mon Aug  5 16:35:25 2013
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Mon, 05 Aug 2013 14:35:25 +0000
Subject: [issue18078] threading.Condition to allow notify on a specific waiter
In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za>
Message-ID: <1375713325.96.0.990889391693.issue18078@psf.upfronthosting.co.za>


Jo?o Bernardo added the comment:

Seems like "just because I never used I don't support". Boost C++ libraries has a wait_for_any functionality to synchronize futures. C# has a WaitAny in the WaitHandle class (like our Condition).

Another problem is: the Condition class cannot be easily subclassed because all the important bits are _protected... Can you add an interface for the "_waiters" list and "_lock" objects?? If you do that I'll be happy subclassing it.

----------

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

From report at bugs.python.org  Mon Aug  5 16:41:28 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Aug 2013 14:41:28 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za>
Message-ID: <1375713688.23.0.444982090114.issue18585@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

[...] and ASCII are fine with me.

> Perhaps there could be an argument controlling where to truncate
> (left, right or centre). A good use-case for the new Enums, perhaps? :-)

I wrote a similar function once and in addition to the width it had this feature too (defaulting on "center"), so it sounds like a reasonable addition to me.  Back then I was simply passing a "left"/"right"/"center" string -- not sure it's worth adding an enum for this (FWIW for text alignment there are 3 separate methods: ljust, center, and rjust).

----------

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

From report at bugs.python.org  Mon Aug  5 16:48:10 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Aug 2013 14:48:10 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za>
Message-ID: <1375714090.12.0.361575580728.issue18585@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Perhaps "shorten" would be a better name -- "summarize" sounds smarter than it actually is :)

----------

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

From report at bugs.python.org  Mon Aug  5 17:14:25 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 05 Aug 2013 15:14:25 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <1375715665.67.0.889852366718.issue18659@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Okay, I guess the fix for this ticket should be kept simple.

If we want to merge the exception message or touch the code base or do something smarter than fixing the test, maybe we should create a separate ticket.

So I used Serhiy Storchaka's suggestion to use _testcapi.INT_MAX for the second patch.

----------
Added file: http://bugs.python.org/file31164/test_precision_v2.patch

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

From report at bugs.python.org  Mon Aug  5 17:14:26 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Aug 2013 15:14:26 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za>
Message-ID: <1375715666.8.0.768627669498.issue18585@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looking just at the proposed functionality (taking a prefix) and ignoring the requested complexification :), the usual name for the text produced by this process is a "lead" (http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Lead_section), although formally a lead is actually written to be used as such, as opposed to just taking a prefix, so that word really has the same problem as 'summarize'.

I think 'truncate' would be a better name.  Or, if you don't mind being wordier, extract_prefix.  The fact that it is part of the textwrap module should be enough clue that the truncation happens at whitespace.  Truncate could also apply to the expanded version if you squint a little, if Antoine is interested in that.  On the other hand, the use case presented for that is not going to be served by this function anyway, since this function (being part of textwrap) breaks on whitespace...it shouldn't (IMO) elide text other than at whitespace.  If you want that functionality it belongs in some other module, I think.

The placeholder argument could alternatively be named 'ellipsis', but placeholder is certainly fine.

shorten would probably be better if you are going with the expanded version, but I like truncate.  It is probably significant that that is what the title of the issue calls it :)

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

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

From report at bugs.python.org  Mon Aug  5 17:18:33 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Aug 2013 15:18:33 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za>
Message-ID: <1375715913.19.0.944241478055.issue18472@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I'm a bit late but I still have a few comments:

+  The paren-using form also means that when the exception arguments are
+  long or include string formatting, you don't need to use line
+  continuation characters thanks to the containing parentheses.

This paragraph doesn't add much and could be removed IMHO.


+- When binding caught exceptions to a name, prefer the explicit name
+  binding syntax added in Python 2.6::
+
+      try:
+          process_data()
+      except Exception as exc:
+          raise DataProcessingFailedError(str(exc))

It took me a bit to realize that this is talking about "as".  I think it would be better to be more explicit, and simplify the example a bit so that it's not as distracting.


+  Note that in Python 3, ``unicode`` and ``basestring`` no longer exist
+  (there is only ``str``) and a bytes object is no longer a kind of
+  string (it is a sequence of integers instead)

Is there any specific reason to use "sequence of integers" instead of "sequence of bytes"?

----------

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

From report at bugs.python.org  Mon Aug  5 17:33:47 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 05 Aug 2013 15:33:47 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375500120.19.0.896650033196.issue18606@psf.upfronthosting.co.za>
Message-ID: <51FFC5D3.3040606@pearwood.info>


Steven D'Aprano added the comment:

On 03/08/13 13:22, Alexander Belopolsky wrote:
>
> Alexander Belopolsky added the comment:
>
> The implementation of median and mode families of functions as classes is clever,

So long as it is not too clever.

> but I am not sure it is a good idea to return something other than an instance of the class from __new__().

Returning foreign instances is supported behaviour for __new__. (If the object returned from __new__ is not an instance, __init__ is not called.) I believe the current implementation is reasonable and prefer to keep it. If I use the traditional implementation, there will only be one instance, with no state, only methods. That's a rather poor excuse for an instance, and a class already is a singleton object with methods and (in this case) no state, so creating an instance as well adds nothing.

I will change the implementation if the consensus among senior devs is against it, but would prefer not to.

----------

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

From report at bugs.python.org  Mon Aug  5 17:58:18 2013
From: report at bugs.python.org (Tim Golden)
Date: Mon, 05 Aug 2013 15:58:18 +0000
Subject: [issue2528] Change os.access to check ACLs under Windows
In-Reply-To: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za>
Message-ID: <1375718298.11.0.238308417756.issue2528@psf.upfronthosting.co.za>


Tim Golden added the comment:

Here's an updated patch against trunk with tests & doc changes

----------
status: languishing -> open
Added file: http://bugs.python.org/file31165/issue2528.2.patch

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

From report at bugs.python.org  Mon Aug  5 18:00:48 2013
From: report at bugs.python.org (Tim Golden)
Date: Mon, 05 Aug 2013 16:00:48 +0000
Subject: [issue2528] Change os.access to check ACLs under Windows
In-Reply-To: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za>
Message-ID: <1375718448.61.0.0235577384862.issue2528@psf.upfronthosting.co.za>


Tim Golden added the comment:

... and to answer Amaury's question in msg109871 it creates a reasonable consistency between the results of os.access and the user's actual ability to read / write a file. eg, you might have no permissions whatsoever on the file but as long as it wasn't read-only, os.access would return True for reading, writing and executing.

----------

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

From report at bugs.python.org  Mon Aug  5 18:45:28 2013
From: report at bugs.python.org (Laszlo Papp)
Date: Mon, 05 Aug 2013 16:45:28 +0000
Subject: [issue17372] provide pretty printer for xml.etree.ElementTree
In-Reply-To: <1362640725.41.0.836381435016.issue17372@psf.upfronthosting.co.za>
Message-ID: <1375721128.34.0.0120038957355.issue17372@psf.upfronthosting.co.za>


Laszlo Papp added the comment:

This has just made me switching away from xml.etree.ElementTree today, sadly.

What a pity; it would have been all kind of cool to stick to this minimal, otherwise working parser and builder.

----------
nosy: +lpapp

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

From report at bugs.python.org  Mon Aug  5 18:46:15 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Aug 2013 16:46:15 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1375721175.57.0.955691615644.issue18606@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Aug  5 18:58:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Aug 2013 16:58:15 +0000
Subject: [issue18661] Typo in grpmodule.c
In-Reply-To: <1375695788.15.0.911930238621.issue18661@psf.upfronthosting.co.za>
Message-ID: <3c84tG4696z7Ln0@mail.python.org>


Roundup Robot added the comment:

New changeset 395ac61ebe1a by Mark Dickinson in branch '2.7':
Issue #18661: typo in grp.struct_group docstring.
http://hg.python.org/cpython/rev/395ac61ebe1a

New changeset 791034a0ae1e by Mark Dickinson in branch '3.3':
Issue #18661: typo in grp.struct_group docstring.  Thanks Vajrasky Kok.
http://hg.python.org/cpython/rev/791034a0ae1e

New changeset f534960c2c02 by Mark Dickinson in branch 'default':
Issue #18661: typo in grp.struct_group docstring (fix merged from 3.3).  Thanks Vajrasky Kok.
http://hg.python.org/cpython/rev/f534960c2c02

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Aug  5 18:59:03 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Aug 2013 16:59:03 +0000
Subject: [issue18661] Typo in grpmodule.c
In-Reply-To: <1375695788.15.0.911930238621.issue18661@psf.upfronthosting.co.za>
Message-ID: <1375721943.7.0.0258047565807.issue18661@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Fixed.  Thanks for the report!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Aug  5 19:08:22 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Aug 2013 17:08:22 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1375722502.04.0.658900088022.issue18606@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I too find the use of a class that'll never be instantiated peculiar.

As you say, there's no state to be stored.  So why not simply have separate functions `median`, `median_low`, `median_high`, `median_grouped`, etc.?

----------

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

From report at bugs.python.org  Mon Aug  5 19:10:44 2013
From: report at bugs.python.org (James Laver)
Date: Mon, 05 Aug 2013 17:10:44 +0000
Subject: [issue18662] re.escape should not escape the hyphen
Message-ID: <1375722644.22.0.61356481393.issue18662@psf.upfronthosting.co.za>


New submission from James Laver:

Traceback (most recent call last):
  File "/Users/jlaver/retest.py", line 6, in test_escape
    self.assertEquals(re.escape('-'), '-')
AssertionError: '\\-' != '-'

The only place you can do bad things with hyphens is in a character class. I fail to see how you'd be in the situation of wanting to use escape()d data in a character class. Even if I could think of a reason to do that, it's decidedly not the usual case.

It's http://bugs.python.org/issue2650 all over again, just with a different character (in that case, underscore).

While we're at it, what else shouldn't it be escaping?

----------
components: Regular Expressions
files: rebugtest.py
messages: 194495
nosy: ezio.melotti, jjl, mrabarnett
priority: normal
severity: normal
status: open
title: re.escape should not escape the hyphen
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31166/rebugtest.py

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

From report at bugs.python.org  Mon Aug  5 19:19:34 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 05 Aug 2013 17:19:34 +0000
Subject: [issue18662] re.escape should not escape the hyphen
In-Reply-To: <1375722644.22.0.61356481393.issue18662@psf.upfronthosting.co.za>
Message-ID: <1375723174.54.0.996659282242.issue18662@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

The help says:

""">>> help(re.escape)
Help on function escape in module re:

escape(pattern)
    Escape all the characters in pattern except ASCII letters, numbers and '_'.
"""

The complementary approach is to escape _only_ the metacharacters.

----------

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

From report at bugs.python.org  Mon Aug  5 19:35:44 2013
From: report at bugs.python.org (James Laver)
Date: Mon, 05 Aug 2013 17:35:44 +0000
Subject: [issue18662] re.escape should not escape the hyphen
In-Reply-To: <1375722644.22.0.61356481393.issue18662@psf.upfronthosting.co.za>
Message-ID: <1375724144.3.0.671521534348.issue18662@psf.upfronthosting.co.za>


James Laver added the comment:

Quite right, it does say that in the documentation. The documentation is perfectly correct, but the behaviour is wrong in my opinion and as you suggest, we should be escaping metacharacters only.

----------

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

From report at bugs.python.org  Mon Aug  5 19:53:10 2013
From: report at bugs.python.org (py.user)
Date: Mon, 05 Aug 2013 17:53:10 +0000
Subject: [issue18663] In unittest.TestCase.assertAlmostEqual doc specify the
	delta description
Message-ID: <1375725190.79.0.442588525807.issue18663@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/library/unittest.html#unittest.TestCase.assertAlmostEqual
"If delta is supplied instead of places then the difference between first and second must be less (or more) than delta."

----------
assignee: docs at python
components: Documentation
files: issue.diff
keywords: patch
messages: 194498
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In unittest.TestCase.assertAlmostEqual doc specify the delta description
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31167/issue.diff

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

From report at bugs.python.org  Mon Aug  5 20:14:23 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 05 Aug 2013 18:14:23 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375722502.04.0.658900088022.issue18606@psf.upfronthosting.co.za>
Message-ID: <51FFEB73.7060803@pearwood.info>


Steven D'Aprano added the comment:

On 06/08/13 03:08, Mark Dickinson wrote:
>
> I too find the use of a class that'll never be instantiated peculiar.

I'll accept "unusual", but not "peculiar". It's an obvious extension to classes being first-class objects. We use classes as objects very frequently, we call methods on classes directly (e.g. int.fromhex). This is just a trivial variation where I am using a class-as-object as a function.

But if this is really going to be a sticking point, I can avoid using a class. I'll make median a plain function. Will that be acceptable?

> As you say, there's no state to be stored.  So why not simply have separate functions `median`, `median_low`, `median_high`, `median_grouped`, etc.?

Why have a pseudo-namespace median_* when we could have a real namespace median.* ?

I discussed my reasons for this here:
http://mail.python.org/pipermail/python-ideas/2013-August/022612.html

----------

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

From report at bugs.python.org  Mon Aug  5 20:32:15 2013
From: report at bugs.python.org (Tim Golden)
Date: Mon, 05 Aug 2013 18:32:15 +0000
Subject: [issue2528] Change os.access to check ACLs under Windows
In-Reply-To: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za>
Message-ID: <1375727535.32.0.504710745574.issue2528@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


Removed file: http://bugs.python.org/file9919/os_access-r62091.patch

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

From report at bugs.python.org  Mon Aug  5 20:32:43 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Aug 2013 18:32:43 +0000
Subject: [issue18273] Simplify calling and discovery of json test package
In-Reply-To: <1371760220.13.0.623339240586.issue18273@psf.upfronthosting.co.za>
Message-ID: <1375727563.84.0.52546609279.issue18273@psf.upfronthosting.co.za>


Ned Deily added the comment:

Make sure the tests still work when run from an installed Python rather than just from a build directory.  In particular, if you rename test directories, you will need to change LIBSUBDIRS in Makefile.pre.in to ensure the directories and their files are installed.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Mon Aug  5 20:36:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Aug 2013 18:36:11 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375715666.8.0.768627669498.issue18585@psf.upfronthosting.co.za>
Message-ID: <1375727763.2557.3.camel@fsol>


Antoine Pitrou added the comment:

> Looking just at the proposed functionality (taking a prefix) and
> ignoring the requested complexification :), the usual name for the
> text produced by this process is a
> "lead" (http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Lead_section), although formally a lead is actually written to be used as such, as opposed to just taking a prefix, so that word really has the same problem as 'summarize'.

Good point.

> The placeholder argument could alternatively be named 'ellipsis', but
> placeholder is certainly fine.

I would certainly like ellipsis if it didn't already mean something else
in Python.

> shorten would probably be better if you are going with the expanded
> version, but I like truncate.  It is probably significant that that is
> what the title of the issue calls it :)

I'm a bit negative towards truncate(), mostly because I've worked on the
I/O stack and truncate means something much less careful there (e.g.
StringIO.truncate()).
But really, I'm fine with either shorten() or truncate(). I agree
summarize() may try to look a bit too smart.

----------

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

From report at bugs.python.org  Mon Aug  5 20:38:31 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 05 Aug 2013 18:38:31 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <51FFEB73.7060803@pearwood.info>
Message-ID: <CAP7h-xY7EWPn0GBgpK0bs=Y304v-4=Cyovt=FpcfMJSnxAV9QQ@mail.gmail.com>


Alexander Belopolsky added the comment:

On Mon, Aug 5, 2013 at 2:14 PM, Steven D'Aprano <report at bugs.python.org>wrote:

> > As you say, there's no state to be stored.  So why not simply have
> separate functions `median`, `median_low`, `median_high`, `median_grouped`,
> etc.?
>
> Why have a pseudo-namespace median_* when we could have a real namespace
> median.* ?

I am with Steven on this one.  Note that these functions are expected to be
used interactively and with standard US keyboards "." is much easier to
type than "_".

My only objection is to having a class xyz such that isinstance(xyz(..),
xyz) is false.  While this works with CPython, it may present problems for
other implementations.

----------

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

From report at bugs.python.org  Mon Aug  5 20:57:19 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Aug 2013 18:57:19 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1375729039.68.0.696618611669.issue18606@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> My only objection is to having a class xyz such that isinstance(xyz(..),
> xyz) is false.

Yep.  Use a set of functions (median, median_low);  use an instance of a class as Alexander describes;  use a single median function that takes an optional "method" parameter;  create a statistics.median subpackage and put the various median functions in that.  Any of those options are fairly standard, unsurprising, and could reasonably be defended.

But having `median` be a class whose `__new__` returns a float really *is* nonstandard and peculiar.  There's just no need for such perversity in what should be a straightforward and uncomplicated module.  Special cases aren't special enough to break the rules and all that.

----------

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

From report at bugs.python.org  Mon Aug  5 21:06:59 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Aug 2013 19:06:59 +0000
Subject: [issue14323] Normalize math precision in RGB/YIQ conversion
In-Reply-To: <1331831977.5.0.174772346075.issue14323@psf.upfronthosting.co.za>
Message-ID: <1375729619.87.0.199642545593.issue14323@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree. Go ahead and push.

----------

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

From report at bugs.python.org  Mon Aug  5 21:16:30 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 05 Aug 2013 19:16:30 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za>
Message-ID: <1375730190.11.0.321366321552.issue18472@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Ezio 2. Explicitly say "use 'as' instead of ','". Someone who does not know that 'as' is available since 2.6 may not understand.

3. 'byte' may be interpreted as 'char', especially for someone using 2.x 'bytes'.

----------

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

From report at bugs.python.org  Mon Aug  5 21:31:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Aug 2013 19:31:51 +0000
Subject: [issue18472] Update PEP 8 to encourage modern conventions
In-Reply-To: <1373973528.84.0.159091610788.issue18472@psf.upfronthosting.co.za>
Message-ID: <1375731111.94.0.13886705282.issue18472@psf.upfronthosting.co.za>


R. David Murray added the comment:

Technically a bytes object is sequence of integers, not a sequence of bytes.  That is, if you iterate it, you get integers.  Python doesn't have a 'byte' type.

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

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

From report at bugs.python.org  Mon Aug  5 21:38:32 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Aug 2013 19:38:32 +0000
Subject: [issue14323] Normalize math precision in RGB/YIQ conversion
In-Reply-To: <1331831977.5.0.174772346075.issue14323@psf.upfronthosting.co.za>
Message-ID: <1375731512.46.0.95921102228.issue14323@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

LGTM too.

----------

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

From report at bugs.python.org  Mon Aug  5 22:35:18 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 05 Aug 2013 20:35:18 +0000
Subject: [issue18078] threading.Condition to allow notify on a specific waiter
In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za>
Message-ID: <1375734918.43.0.0307586038397.issue18078@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

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

From report at bugs.python.org  Mon Aug  5 23:14:48 2013
From: report at bugs.python.org (Alex Henderson)
Date: Mon, 05 Aug 2013 21:14:48 +0000
Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output
In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>
Message-ID: <1375737288.43.0.101654913398.issue14465@psf.upfronthosting.co.za>


Alex Henderson added the comment:

Proposed patch copied over from duplicate issue 17372.

----------
keywords: +patch
nosy: +alex.henderson
Added file: http://bugs.python.org/file31168/issue14465.patch

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

From report at bugs.python.org  Mon Aug  5 23:17:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Aug 2013 21:17:43 +0000
Subject: [issue4885] mmap enhancement request
In-Reply-To: <1231445893.72.0.162990779773.issue4885@psf.upfronthosting.co.za>
Message-ID: <3c8Bdf2yJnzSdn@mail.python.org>


Roundup Robot added the comment:

New changeset 1754b7900da1 by Antoine Pitrou in branch 'default':
Issue #4885: Add weakref support to mmap objects.  Patch by Valerie Lambert.
http://hg.python.org/cpython/rev/1754b7900da1

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Aug  5 23:18:13 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Aug 2013 21:18:13 +0000
Subject: [issue4885] mmap enhancement request
In-Reply-To: <1231445893.72.0.162990779773.issue4885@psf.upfronthosting.co.za>
Message-ID: <1375737493.68.0.696634225176.issue4885@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Your patch is now committed. Thanks for contributing!

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

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

From report at bugs.python.org  Mon Aug  5 23:28:01 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Aug 2013 21:28:01 +0000
Subject: [issue17934] Add a frame method to clear expensive details
In-Reply-To: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za>
Message-ID: <3c8BsX35Y6zS7H@mail.python.org>


Roundup Robot added the comment:

New changeset 862ab99ab570 by Antoine Pitrou in branch 'default':
Issue #17934: Add a clear() method to frame objects, to help clean up expensive details (local variables) and break reference cycles.
http://hg.python.org/cpython/rev/862ab99ab570

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Aug  5 23:32:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Aug 2013 21:32:19 +0000
Subject: [issue17934] Add a frame method to clear expensive details
In-Reply-To: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za>
Message-ID: <1375738339.19.0.279434236613.issue17934@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, I committed the RuntimeError-raising version.

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

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

From report at bugs.python.org  Mon Aug  5 23:33:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Aug 2013 21:33:42 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
	locals and globals when they are not wanted
Message-ID: <1375738422.95.0.000120505419772.issue1565525@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

frame.clear() was committed in issue17934.

----------
nosy: +pitrou

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

From report at bugs.python.org  Mon Aug  5 23:34:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Aug 2013 21:34:28 +0000
Subject: [issue9815] assertRaises as a context manager keeps tracebacks and
	frames alive
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1375738468.04.0.194373125054.issue9815@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

frame.clear() was committed in issue17934, it would allow a less brutal resolution.

----------

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

From report at bugs.python.org  Mon Aug  5 23:42:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Aug 2013 21:42:54 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
	iterable)
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375738974.41.0.96965701603.issue18652@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I would like to chime in and say that the fact that the functions exists in SQL (and possibly Lisp, Snobol and PHP) sells me on the idea!

Okay, only joking, but I do think this is a useful addition.
"first_true" should be its name, but itertools already has a tradition of nonunderscorednames, so it should be "firsttrue", which may look weird because of the doubled t.

----------
nosy: +pitrou

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

From report at bugs.python.org  Mon Aug  5 23:47:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Aug 2013 21:47:05 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
	iterable)
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1375739225.42.0.422980087575.issue18652@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(but you don't have to trust me: itertools also has izip_longest() and combinations_with_replacement())

----------

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

From report at bugs.python.org  Tue Aug  6 00:19:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Aug 2013 22:19:25 +0000
Subject: [issue18664] occasional test_threading failure
Message-ID: <1375741165.75.0.0273425053979.issue18664@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

http://buildbot.python.org/all/builders/AMD64%20Windows%20Server%202008%20%5BSB%5D%203.x/builds/1021

======================================================================
FAIL: test_finalize_with_trace (test.test_threading.ThreadTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\home\cpython\buildslave\x64\3.x.snakebite-win2k8r2sp1-amd64\build\lib\test\test_threading.py", line 323, in test_finalize_with_trace
    """)
  File "E:\home\cpython\buildslave\x64\3.x.snakebite-win2k8r2sp1-amd64\build\lib\test\script_helper.py", line 54, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "E:\home\cpython\buildslave\x64\3.x.snakebite-win2k8r2sp1-amd64\build\lib\test\script_helper.py", line 46, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 3, stderr follows:
Assertion failed: !PyErr_Occurred(), file ..\Objects\object.c, line 451
Fatal Python error: Aborted

Thread 0x00000e14:
  File "<string>", line 8 in killer
  File "E:\home\cpython\buildslave\x64\3.x.snakebite-win2k8r2sp1-amd64\build\lib\threading.py", line 599 in run
  File "E:\home\cpython\buildslave\x64\3.x.snakebite-win2k8r2sp1-amd64\build\lib\threading.py", line 642 in _bootstrap_inner
  File "E:\home\cpython\buildslave\x64\3.x.snakebite-win2k8r2sp1-amd64\build\lib\threading.py", line 619 in _bootstrap

Current thread 0x000006c4:

----------
components: Interpreter Core, Tests
messages: 194517
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: occasional test_threading failure
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug  6 00:59:51 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 05 Aug 2013 22:59:51 +0000
Subject: [issue18579] Dereference after NULL check in listobject.c merge_hi()
In-Reply-To: <1375017605.96.0.0484069196925.issue18579@psf.upfronthosting.co.za>
Message-ID: <1375743591.37.0.259196624197.issue18579@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

According to this comment, ssb.values can be null:

/* A sortslice contains a pointer to an array of keys and a pointer to
 * an array of corresponding values.  In other words, keys[i]
 * corresponds with values[i].  If values == NULL, then the keys are
 * also the values.
 *
 * Several convenience routines are provided here, so that keys and
 * values are always moved in sync.
 */ <http://hg.python.org/cpython/file/tip/Objects/listobject.c#l969>


However, is ssb.values is null, dest.values must be null as well and sortslice_copy_decr() will not dereference either of the pointers.

Looks like a false positive to me, but I wonder if a strategically placed assert will silence coverity:

Py_LOCAL_INLINE(void)
sortslice_copy_decr(sortslice *dst, sortslice *src)
{
    *dst->keys-- = *src->keys--;
    if (dst->values != NULL) {
        assert(src->values != NULL);
        *dst->values-- = *src->values--;
    }
}

----------
nosy: +belopolsky

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

From report at bugs.python.org  Tue Aug  6 02:32:11 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Aug 2013 00:32:11 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375715665.67.0.889852366718.issue18659@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYC1RbY_=CQ6w7DjrcLkTXXWtgja7+UaCnYg4eUZ8W5hw@mail.gmail.com>


STINNER Victor added the comment:

I realized that the new tests checking that precision larger with
INT_MAX fail should be marked as specific to CPython. The import of
_testcapi should be moved to a CPython specific test.

----------

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

From report at bugs.python.org  Tue Aug  6 02:36:27 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Aug 2013 00:36:27 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
	locals and globals when they are not wanted
Message-ID: <1375749387.1.0.837451280377.issue1565525@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> frame.clear() was committed in issue17934.

How should it be used to workaround this issue ("tracebacks eat up memory by holding references to locals and globals when they are not wanted")?

We need maybe an helper to clear all frames referenced by a traceback?

----------

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

From report at bugs.python.org  Tue Aug  6 02:43:28 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Aug 2013 00:43:28 +0000
Subject: [issue18664] occasional test_threading failure
In-Reply-To: <1375741165.75.0.0273425053979.issue18664@psf.upfronthosting.co.za>
Message-ID: <1375749808.68.0.147112522186.issue18664@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Assertion failed: !PyErr_Occurred(), file ..\Objects\object.c, line 451

This error means that PyObject_Repr() was called with an exception set. It would help to know which function called PyObject_Repr() and when.

----------

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

From report at bugs.python.org  Tue Aug  6 02:44:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Aug 2013 00:44:01 +0000
Subject: [issue18664] occasional test_threading failure
In-Reply-To: <1375741165.75.0.0273425053979.issue18664@psf.upfronthosting.co.za>
Message-ID: <1375749841.96.0.266230145129.issue18664@psf.upfronthosting.co.za>


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


----------
nosy: +christian.heimes, serhiy.storchaka

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

From report at bugs.python.org  Tue Aug  6 05:06:43 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 06 Aug 2013 03:06:43 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <1375758403.33.0.403365347603.issue18659@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Attached the third patch. The importing _testcapi part was moved inside the test. Added cpython support only decorator for this test.

----------
Added file: http://bugs.python.org/file31169/test_precision_v3.patch

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

From report at bugs.python.org  Tue Aug  6 06:53:20 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 06 Aug 2013 04:53:20 +0000
Subject: [issue18665] Typos in frame object related code
Message-ID: <1375764800.58.0.482122024787.issue18665@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

See the patch for details:

diff -r 438cdc97d8ee Include/frameobject.h
--- a/Include/frameobject.h	Mon Aug 05 23:35:43 2013 +0200
+++ b/Include/frameobject.h	Tue Aug 06 12:38:15 2013 +0800
@@ -36,7 +36,7 @@
            non-generator frames. See the save_exc_state and swap_exc_state
            functions in ceval.c for details of their use. */
     PyObject *f_exc_type, *f_exc_value, *f_exc_traceback;
-    /* Borrowed referenced to a generator, or NULL */
+    /* Borrowed reference to a generator, or NULL */
     PyObject *f_gen;
 
     PyThreadState *f_tstate;
diff -r 438cdc97d8ee Lib/test/test_frame.py
--- a/Lib/test/test_frame.py	Mon Aug 05 23:35:43 2013 +0200
+++ b/Lib/test/test_frame.py	Tue Aug 06 12:38:15 2013 +0800
@@ -93,7 +93,7 @@
 
     @support.cpython_only
     def test_clear_refcycles(self):
-        # .clear() doesn't leave any refcycle behin
+        # .clear() doesn't leave any refcycle behind.
         with support.disable_gc():
             class C:
                 pass


About the second comment, I am not sure to put dot or not. In that file, I saw some comments use dot, others don't.

----------
assignee: docs at python
components: Documentation
messages: 194523
nosy: docs at python, pitrou, vajrasky
priority: normal
severity: normal
status: open
title: Typos in frame object related code
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug  6 07:01:37 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 06 Aug 2013 05:01:37 +0000
Subject: [issue18666] Unused variable in test_frame.py
Message-ID: <1375765297.44.0.682936392521.issue18666@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

There is a unused variable in Lib/test/test_frame.py.

    def test_clear_executing_generator(self):
        # Attempting to clear an executing generator frame is forbidden.
        endly = False
        def g():
            nonlocal endly
            try:
                1/0
            except ZeroDivisionError as e:
                f = e.__traceback__.tb_frame
                with self.assertRaises(RuntimeError):
                    f.clear()
                with self.assertRaises(RuntimeError):
                    f.f_back.clear()
                yield f
            finally:
                endly = True
        gen = g()
        f = next(gen)
        self.assertFalse(endly)

The variable f is hanging without any purpose.

Attached the patch to give purpose to variable f.

----------
components: Tests
files: test_frame.patch
keywords: patch
messages: 194524
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: Unused variable in test_frame.py
versions: Python 3.4
Added file: http://bugs.python.org/file31170/test_frame.patch

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

From report at bugs.python.org  Tue Aug  6 07:13:02 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 06 Aug 2013 05:13:02 +0000
Subject: [issue18665] Typos in frame object related code
In-Reply-To: <1375764800.58.0.482122024787.issue18665@psf.upfronthosting.co.za>
Message-ID: <1375765982.05.0.823040455989.issue18665@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Can you attach the patch to the issue?
Full stops for one-sentence comments can be omitted.

----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Aug  6 07:52:36 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 06 Aug 2013 05:52:36 +0000
Subject: [issue18662] re.escape should not escape the hyphen
In-Reply-To: <1375722644.22.0.61356481393.issue18662@psf.upfronthosting.co.za>
Message-ID: <1375768356.67.0.159525524396.issue18662@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

In #2650 re.escape() was updated to match Perl's behavior.  I don't think there's any actual reason to change it -- it brings no benefits and it might break some code (even if admittedly it's not very likely).

----------
type: behavior -> enhancement
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.5

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

From report at bugs.python.org  Tue Aug  6 07:59:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 06 Aug 2013 05:59:29 +0000
Subject: [issue16245] Update html.entities.html5 dictionary and
	parseentities.py
In-Reply-To: <1350380511.49.0.860998010837.issue16245@psf.upfronthosting.co.za>
Message-ID: <1375768769.22.0.642534431038.issue16245@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I run Tools/scripts/parse_html5_entities.py and it says that "The current dictionary is updated.".  We should check this again, and eventually close the issue, when 3.4 is released.

----------

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

From report at bugs.python.org  Tue Aug  6 08:09:19 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 06 Aug 2013 06:09:19 +0000
Subject: [issue18665] Typos in frame object related code
In-Reply-To: <1375764800.58.0.482122024787.issue18665@psf.upfronthosting.co.za>
Message-ID: <1375769359.77.0.775522715572.issue18665@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Okay, attached the patch to fix the typo.

----------
keywords: +patch
Added file: http://bugs.python.org/file31171/fix_typo_frame_object.patch

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

From report at bugs.python.org  Tue Aug  6 08:12:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 06 Aug 2013 06:12:13 +0000
Subject: [issue18562] Regex howto: revision pass
In-Reply-To: <1374854855.56.0.787824851556.issue18562@psf.upfronthosting.co.za>
Message-ID: <1375769533.04.0.899115816134.issue18562@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Regular Expressions
nosy: +mrabarnett
type:  -> enhancement

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

From report at bugs.python.org  Tue Aug  6 08:54:47 2013
From: report at bugs.python.org (Petr.Salinger)
Date: Tue, 06 Aug 2013 06:54:47 +0000
Subject: [issue18667] missing HAVE_FCHOWNAT
Message-ID: <1375772087.0.0.361755653525.issue18667@psf.upfronthosting.co.za>


New submission from Petr.Salinger:

During test on kfreebsd:

test_chown_dir_fd (test.test_posix.PosixTester) ... skipped 'test needs dir_fd support in os.chown()'

But all *AT syscalls are supported.
It looks like posixmodule.c misses propagation of that fact.

--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -12004,6 +12004,10 @@
     "HAVE_FCHOWN",
 #endif
 
+#ifdef HAVE_FCHOWNAT
+    "HAVE_FCHOWNAT",
+#endif
+
 #ifdef HAVE_FEXECVE
     "HAVE_FEXECVE",
 #endif

----------
components: Extension Modules
messages: 194529
nosy: Petr.Salinger
priority: normal
severity: normal
status: open
title: missing HAVE_FCHOWNAT
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug  6 09:42:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 07:42:57 +0000
Subject: [issue18468] re.group() should never return a bytearray
In-Reply-To: <1373931432.85.0.594082146564.issue18468@psf.upfronthosting.co.za>
Message-ID: <1375774977.24.0.590723358398.issue18468@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch with an implementation and tests. Feel free to add a documentation changes if needed.

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

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

From report at bugs.python.org  Tue Aug  6 10:23:57 2013
From: report at bugs.python.org (salinger)
Date: Tue, 06 Aug 2013 08:23:57 +0000
Subject: [issue18667] missing HAVE_FCHOWNAT
In-Reply-To: <1375772087.0.0.361755653525.issue18667@psf.upfronthosting.co.za>
Message-ID: <1375777437.06.0.995202602908.issue18667@psf.upfronthosting.co.za>


Changes by salinger <Petr.Salinger at seznam.cz>:


----------
nosy: +doko

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

From report at bugs.python.org  Tue Aug  6 10:52:02 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Aug 2013 08:52:02 +0000
Subject: [issue14323] Normalize math precision in RGB/YIQ conversion
In-Reply-To: <1331831977.5.0.174772346075.issue14323@psf.upfronthosting.co.za>
Message-ID: <3c8V2n58BNzRFT@mail.python.org>


Roundup Robot added the comment:

New changeset 80e9cb6163b4 by Serhiy Storchaka in branch 'default':
Issue #14323: Expanded the number of digits in the coefficients for the
http://hg.python.org/cpython/rev/80e9cb6163b4

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Aug  6 10:53:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 08:53:04 +0000
Subject: [issue14323] Normalize math precision in RGB/YIQ conversion
In-Reply-To: <1331831977.5.0.174772346075.issue14323@psf.upfronthosting.co.za>
Message-ID: <1375779184.54.0.229549014033.issue14323@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


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

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

From report at bugs.python.org  Tue Aug  6 11:03:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 09:03:26 +0000
Subject: [issue18368] PyOS_StdioReadline() leaks memory when realloc() fails
In-Reply-To: <1373054563.49.0.685653845765.issue18368@psf.upfronthosting.co.za>
Message-ID: <1375779806.1.0.106585093285.issue18368@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch can be a little simplified (the "else" keyword is redundant), but in general it LGTM. Let's push.

----------

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

From report at bugs.python.org  Tue Aug  6 13:50:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 11:50:06 +0000
Subject: [issue16968] Fix test discovery for test_concurrent_futures.py
In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za>
Message-ID: <1375789806.76.0.676540869096.issue16968@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

As far as I understand threads reaping needed only when ThreadPoolExecutor is used and children reaping needed only when ProcessPoolExecutor is used. Why not use them only in tests which needs them?

class ThreadPoolMixin(ExecutorMixin):
    executor_type = futures.ThreadPoolExecutor

    def run(self, result):
        key = test.support.threading_setup()
        try:
            return super().run(result)
        finally:
            test.support.threading_cleanup(*key)


class ProcessPoolMixin(ExecutorMixin):
    executor_type = futures.ProcessPoolExecutor

    def run(self, result):
        try:
            return super().run(result)
        finally:
            test.support.reap_children()

----------

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

From report at bugs.python.org  Tue Aug  6 13:51:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 11:51:34 +0000
Subject: [issue18430] gzip, bz2,
	lzma: peek advances file position of existing file object
In-Reply-To: <1373571241.88.0.314815867736.issue18430@psf.upfronthosting.co.za>
Message-ID: <1375789894.04.0.17114502289.issue18430@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy:  -serhiy.storchaka

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

From report at bugs.python.org  Tue Aug  6 13:53:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 11:53:32 +0000
Subject: [issue18528] Possible fd leak in socketmodule
In-Reply-To: <1374496496.68.0.51305379842.issue18528@psf.upfronthosting.co.za>
Message-ID: <1375790012.56.0.917956680553.issue18528@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy:  -serhiy.storchaka

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

From report at bugs.python.org  Tue Aug  6 13:56:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 11:56:51 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1375790211.79.0.135368924992.issue15301@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Let's push.

----------

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

From report at bugs.python.org  Tue Aug  6 14:11:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 12:11:33 +0000
Subject: [issue18301] In itertools.chain.from_iterable() there is no cls
	argument
In-Reply-To: <1372186723.21.0.67533324157.issue18301@psf.upfronthosting.co.za>
Message-ID: <1375791093.74.0.585284037721.issue18301@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It should be a classmethod.

>>> import itertools
>>> class C(itertools.chain): pass
... 
>>> type(C.from_iterable(['ab', 'cd']))
<class '__main__.C'>

The patch LGTM.

----------
assignee: docs at python -> serhiy.storchaka
stage:  -> commit review

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

From report at bugs.python.org  Tue Aug  6 14:17:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 12:17:06 +0000
Subject: [issue18301] In itertools.chain.from_iterable() there is no cls
	argument
In-Reply-To: <1372186723.21.0.67533324157.issue18301@psf.upfronthosting.co.za>
Message-ID: <1375791426.57.0.60996685049.issue18301@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: serhiy.storchaka -> rhettinger

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

From report at bugs.python.org  Tue Aug  6 14:18:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 12:18:46 +0000
Subject: [issue14507] Segfault with deeply nested starmap calls
In-Reply-To: <1333628918.06.0.633986455545.issue14507@psf.upfronthosting.co.za>
Message-ID: <1375791526.77.0.0400575873522.issue14507@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


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

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

From report at bugs.python.org  Tue Aug  6 14:19:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 12:19:33 +0000
Subject: [issue11126] Wave.py does not always write proper length in header
In-Reply-To: <1296864048.5.0.627671615909.issue11126@psf.upfronthosting.co.za>
Message-ID: <1375791573.25.0.349704065678.issue11126@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


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

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

From report at bugs.python.org  Tue Aug  6 14:23:49 2013
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 06 Aug 2013 12:23:49 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375791829.11.0.689232613813.issue18264@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Hopefully the final patch.  :)

----------
Added file: http://bugs.python.org/file31172/issue18264.stoneleaf.04.patch

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

From report at bugs.python.org  Tue Aug  6 14:29:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 12:29:27 +0000
Subject: [issue18290] json encoder does not support JSONP/JavaScript safe
	escaping
In-Reply-To: <1372049179.79.0.237326954931.issue18290@psf.upfronthosting.co.za>
Message-ID: <1375792167.0.0.931522681563.issue18290@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think this is not JSON issue. If you need escaping of some domain-specific characters, do it youself. I.e.

    json.dump(...).replace('\u2028', r'\u2028').replace('\u2029', r'\u2029').replace('</', r'\u003c\u002f')

----------
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Tue Aug  6 15:02:47 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Aug 2013 13:02:47 +0000
Subject: [issue15966] concurrent.futures: Executor.submit keyword arguments
	may not be called 'fn' (or 'self')
In-Reply-To: <1347982368.75.0.56994107832.issue15966@psf.upfronthosting.co.za>
Message-ID: <1375794167.05.0.505719114696.issue15966@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Closing this.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Tue Aug  6 15:06:06 2013
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 06 Aug 2013 13:06:06 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375794366.42.0.960584568193.issue18264@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Forgot to back out core dump tests before creating previous patch.  This one even passes the tests.  :/

----------
Added file: http://bugs.python.org/file31173/issue18264.stoneleaf.05.patch

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

From report at bugs.python.org  Tue Aug  6 15:09:28 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Aug 2013 13:09:28 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1375794568.33.0.778559718235.issue10918@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

#15966 is related.  I suggest closing this issue as "won't fix", too.

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

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

From report at bugs.python.org  Tue Aug  6 15:11:31 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 06 Aug 2013 13:11:31 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375794691.86.0.296518308907.issue18264@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

LGTM now. Make sure to run the test(s) in refleak mode and let's wait for a couple of days before committing, in case someone else has comments.

----------

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

From report at bugs.python.org  Tue Aug  6 15:16:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 13:16:58 +0000
Subject: [issue1772673] Replacing char* with const char*
Message-ID: <1375795018.06.0.221837514959.issue1772673@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

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

From report at bugs.python.org  Tue Aug  6 15:20:46 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 06 Aug 2013 13:20:46 +0000
Subject: [issue18668] Properly document setting m_size in PyModuleDef
Message-ID: <1375795246.61.0.949649493069.issue18668@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

docs.python.org/dev/c-api/module.html Currently doesn't say much about m_size, except that setting it to -1 means "no memory needed".

m_size == -1 has a much more important use that is not documented: it signals the import machinery that the module should not be ever re-initialized. This has to be documented explicitly.

----------
assignee: eli.bendersky
components: Documentation, Extension Modules
messages: 194542
nosy: eli.bendersky, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Properly document setting m_size in PyModuleDef
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Aug  6 15:20:58 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 06 Aug 2013 13:20:58 +0000
Subject: [issue18668] Properly document setting m_size in PyModuleDef
In-Reply-To: <1375795246.61.0.949649493069.issue18668@psf.upfronthosting.co.za>
Message-ID: <1375795258.98.0.269625517272.issue18668@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


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

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

From report at bugs.python.org  Tue Aug  6 15:28:47 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 06 Aug 2013 13:28:47 +0000
Subject: [issue15966] concurrent.futures: Executor.submit keyword arguments
	may not be called 'fn' (or 'self')
In-Reply-To: <1347982368.75.0.56994107832.issue15966@psf.upfronthosting.co.za>
Message-ID: <1375795727.36.0.962273806034.issue15966@psf.upfronthosting.co.za>


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


----------
resolution: wont fix -> duplicate
superseder:  -> **kwargs unnecessarily restricted in concurrent.futures 'submit' API

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

From report at bugs.python.org  Tue Aug  6 15:41:14 2013
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 06 Aug 2013 13:41:14 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1375794691.86.0.296518308907.issue18264@psf.upfronthosting.co.za>
Message-ID: <5200FCF8.60005@stoneleaf.us>


Ethan Furman added the comment:

I'll plan on committing no sooner than Friday unless somebody else has comments/corrections.

Thanks, Eli.

----------

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

From report at bugs.python.org  Tue Aug  6 15:48:51 2013
From: report at bugs.python.org (James Laver)
Date: Tue, 06 Aug 2013 13:48:51 +0000
Subject: [issue18662] re.escape should not escape the hyphen
In-Reply-To: <1375722644.22.0.61356481393.issue18662@psf.upfronthosting.co.za>
Message-ID: <1375796931.79.0.704483092194.issue18662@psf.upfronthosting.co.za>


James Laver added the comment:

I looked up quotemeta with perldoc and you're right, it will quote the hyphen. Given that python's regex engine correctly deals with unnecessarily quoted characters, I suppose this is fine.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Tue Aug  6 15:52:44 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 06 Aug 2013 13:52:44 +0000
Subject: [issue18532] hashlib.HASH objects should officially expose the hash
	name
In-Reply-To: <1374524940.42.0.582552143445.issue18532@psf.upfronthosting.co.za>
Message-ID: <1375797164.08.0.200307992783.issue18532@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I added some tests in 5fbf23e947d8 and found a bug in the _sha1 module, too.

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

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

From report at bugs.python.org  Tue Aug  6 15:53:43 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Tue, 06 Aug 2013 13:53:43 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1375797223.05.0.687836175495.issue18606@psf.upfronthosting.co.za>


Changes by Oscar Benjamin <oscar.j.benjamin at gmail.com>:


----------
nosy: +oscarbenjamin

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

From report at bugs.python.org  Tue Aug  6 15:57:03 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Aug 2013 13:57:03 +0000
Subject: [issue15866] encode(...,
	'xmlcharrefreplace') produces entities for surrogate pairs
In-Reply-To: <1346871274.13.0.653364801762.issue15866@psf.upfronthosting.co.za>
Message-ID: <3c8cpk2hf1z7LlP@mail.python.org>


Roundup Robot added the comment:

New changeset 719ee60fc5e2 by Serhiy Storchaka in branch '2.7':
Issue #15866: The xmlcharrefreplace error handler no more produces two XML
http://hg.python.org/cpython/rev/719ee60fc5e2

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Aug  6 15:58:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 13:58:20 +0000
Subject: [issue15866] encode(...,
	'xmlcharrefreplace') produces entities for surrogate pairs
In-Reply-To: <1346871274.13.0.653364801762.issue15866@psf.upfronthosting.co.za>
Message-ID: <1375797500.33.0.418346960318.issue15866@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Aug  6 16:03:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Aug 2013 14:03:46 +0000
Subject: [issue18368] PyOS_StdioReadline() leaks memory when realloc() fails
In-Reply-To: <1373054563.49.0.685653845765.issue18368@psf.upfronthosting.co.za>
Message-ID: <3c8cyT6xLfz7Lm8@mail.python.org>


Roundup Robot added the comment:

New changeset 5859a3ec5b7e by Christian Heimes in branch '3.3':
Issue #18368: PyOS_StdioReadline() no longer leaks memory when realloc() fails.
http://hg.python.org/cpython/rev/5859a3ec5b7e

New changeset 6dbc4d6ff31e by Christian Heimes in branch 'default':
Issue #18368: PyOS_StdioReadline() no longer leaks memory when realloc() fails.
http://hg.python.org/cpython/rev/6dbc4d6ff31e

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Aug  6 16:06:12 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 06 Aug 2013 14:06:12 +0000
Subject: [issue18668] Properly document setting m_size in PyModuleDef
In-Reply-To: <1375795246.61.0.949649493069.issue18668@psf.upfronthosting.co.za>
Message-ID: <1375797972.79.0.437136695008.issue18668@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Here's a documentation patch generated for 3.3

----------
keywords: +patch
Added file: http://bugs.python.org/file31174/issue18668.doc.1.patch

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

From report at bugs.python.org  Tue Aug  6 16:16:12 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 06 Aug 2013 14:16:12 +0000
Subject: [issue18368] PyOS_StdioReadline() leaks memory when realloc() fails
In-Reply-To: <1373054563.49.0.685653845765.issue18368@psf.upfronthosting.co.za>
Message-ID: <1375798572.68.0.832506459831.issue18368@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Serhiy:
Thanks for the review

Kristj?n:
Yes, it's enough to check for incr > INT_MAX. The buffer size is incremented to a value of <= (2*n)+2 in each round. The start value is 100. The loop is terminated once the buffer size reaches INT_MAX-2.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending

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

From report at bugs.python.org  Tue Aug  6 16:16:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Aug 2013 14:16:48 +0000
Subject: [issue18668] Properly document setting m_size in PyModuleDef
In-Reply-To: <1375795246.61.0.949649493069.issue18668@psf.upfronthosting.co.za>
Message-ID: <1375798608.36.0.881327276282.issue18668@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Looks good to me, thanks.

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Aug  6 16:21:50 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 06 Aug 2013 14:21:50 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1375798910.29.0.173526525467.issue16038@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The patches are languishing in the bug tracker for a while...

Benjamin:
I like to apply them to 3.3 and default before the next release of 3.3. Do you want to have the fixes in 2.7, too?

----------

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

From report at bugs.python.org  Tue Aug  6 16:42:50 2013
From: report at bugs.python.org (productivememberofsociety666)
Date: Tue, 06 Aug 2013 14:42:50 +0000
Subject: [issue18669] curses.chgat() moves cursor,
	documentation says it shouldn't
Message-ID: <1375800170.73.0.20062232661.issue18669@psf.upfronthosting.co.za>


New submission from productivememberofsociety666:

According to docs.python.org/2/library/curses.html#chgat (or any other version), curses.chgat() is not supposed to move the cursor at all.

This is true if you don't give it x,y coordinates, but if you do, the cursor does in fact move to those coordinates, since it then uses C curses's mvchgat() internally and doesn't correct the position afterwards.

See included file for demonstration:

Expected output is:
one
two

Actual output is:
two

Fix the documentation or fix the code :-)

----------
assignee: docs at python
components: Documentation, Extension Modules
files: chgat-bug.py
messages: 194552
nosy: docs at python, productivememberofsociety666
priority: normal
severity: normal
status: open
title: curses.chgat() moves cursor, documentation says it shouldn't
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31175/chgat-bug.py

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

From report at bugs.python.org  Tue Aug  6 16:45:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 14:45:30 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375800330.16.0.125125679589.issue18647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Originally the catch condition was (lo == 0). It was changed in changeset 41c42b1bd582.

> Offhand, do you have an example that displays bad behavior in 2.7?  I'm curious because I didn't find one after half an hour of trying.

re.match('(?:.?.?)*y', 'x'*20)

----------

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

From report at bugs.python.org  Tue Aug  6 16:48:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 14:48:58 +0000
Subject: [issue16741] `int()`, `float()`,
	etc think python strings are null-terminated
In-Reply-To: <1356046641.74.0.314140910069.issue16741@psf.upfronthosting.co.za>
Message-ID: <1375800538.82.0.0554303593491.issue16741@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


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

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

From report at bugs.python.org  Tue Aug  6 16:50:28 2013
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 06 Aug 2013 14:50:28 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1375794691.86.0.296518308907.issue18264@psf.upfronthosting.co.za>
Message-ID: <52010D32.70206@stoneleaf.us>


Ethan Furman added the comment:

> Eli Bendersky added the comment:
>
> Make sure to run the test(s) in refleak mode . . .

How extensive should testing be?

I plan on always running the refleak mode tests (now that I know how ;) .

Should I also run non-refleak tests?

Should I run tests with a python built without --with-pydebug?

----------

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

From report at bugs.python.org  Tue Aug  6 17:16:27 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 06 Aug 2013 15:16:27 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1373400107.5.0.285657244525.issue18416@psf.upfronthosting.co.za>
Message-ID: <1375802187.73.0.654105025133.issue18416@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I actually meant FileFinder but PathFinder is a good point.

In FileFinder you need to change ``self.path = path or '.'`` to use the cwd.

----------

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

From report at bugs.python.org  Tue Aug  6 17:26:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 06 Aug 2013 15:26:13 +0000
Subject: [issue18662] re.escape should not escape the hyphen
In-Reply-To: <1375722644.22.0.61356481393.issue18662@psf.upfronthosting.co.za>
Message-ID: <1375802773.33.0.424924132347.issue18662@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> committed/rejected

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

From report at bugs.python.org  Tue Aug  6 17:31:35 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 06 Aug 2013 15:31:35 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375803095.54.0.635444918154.issue18264@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

IMHO it's very much dependent on the change. When making C code changes, I usually run the relevant tests with refleaks, and then run the whole test suite; all of this --with-pydebug. Personally I've not encountered cases where non-debug builds failed where debug suceeded for CPython, but for very significant changes I may do some extra runs in the release mode as well (or try to test it on a specific OS). It's very important to watch the bots after committing, because they run a wide variety of configurations you'll be hard pressed to reproduce on your own - so they exercise the change pretty well.

----------

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

From report at bugs.python.org  Tue Aug  6 17:31:44 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 06 Aug 2013 15:31:44 +0000
Subject: [issue18670] Using read_mime_types function from mimetypes module
	gives resource warning
Message-ID: <1375803104.23.0.740839065527.issue18670@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

[sky at localhost cpython]$ cat /tmp/a.txt
x-application/mimea mimea
application/mimeb mimeb
[sky at localhost cpython]$ cat /tmp/a.py
import warnings
warnings.simplefilter('default')
import mimetypes

mimetypes.read_mime_types('/tmp/a.txt')
[sky at localhost cpython]$ python3 /tmp/a.py
/tmp/a.py:7: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/a.txt' mode='r' encoding='UTF-8'>
  mimetypes.read_mime_types('/tmp/a.txt')



Attached the patch to fix the resource warning problem.

----------
components: Library (Lib)
files: fix_resource_warning_read_mime_types.patch
keywords: patch
messages: 194557
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Using read_mime_types function from mimetypes module gives resource warning
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file31176/fix_resource_warning_read_mime_types.patch

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

From report at bugs.python.org  Tue Aug  6 17:33:57 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 06 Aug 2013 15:33:57 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <1375803237.51.0.992222778698.issue18264@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I plan on always running the refleak mode tests (now that I know how ;) 

FWIW `make patchcheck` should remind you about that.

----------
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Tue Aug  6 17:57:49 2013
From: report at bugs.python.org (M. Dietrich)
Date: Tue, 06 Aug 2013 15:57:49 +0000
Subject: [issue18671] enhance formatting in logging package
Message-ID: <1375804669.84.0.0477385788117.issue18671@psf.upfronthosting.co.za>


New submission from M. Dietrich:

in logging/__init__.py line 328 there is a simple line:

     msg = msg % self.args

if that line fails this failure will be logged, not the line itself. i suggest to change the line to something like:

    try: msg = msg % self.args
    except TypeError: msg = 'logging formatting error with "%s" %% %s' % (
        msg, self.args, )

to be able to pinpoint the actual wrong formatting string (the stack trace doesnt help here).

----------
components: Extension Modules
messages: 194559
nosy: mdt
priority: normal
severity: normal
status: open
title: enhance formatting in logging package
type: enhancement

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

From report at bugs.python.org  Tue Aug  6 18:07:46 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 06 Aug 2013 16:07:46 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1373400107.5.0.285657244525.issue18416@psf.upfronthosting.co.za>
Message-ID: <1375805266.28.0.128618982976.issue18416@psf.upfronthosting.co.za>


Madison May added the comment:

A few days ago I tried the change: ``self.path = path or _os.cwd()``, but the problem didn't seem to resolve itself.  

``./python -c "import blah; print(blah.__file__)`` still returned a relative path on my system. The tie between FileFinder and the __file__ attribute isn't yet obvious to me.  

I'm traveling for the next few days but I'll probably give it a second look when I get some free time.

----------

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

From report at bugs.python.org  Tue Aug  6 18:11:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 16:11:58 +0000
Subject: [issue18672] Fix format specifiers for debug output in _sre.c
Message-ID: <1375805518.91.0.887667887132.issue18672@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When the VERBOSE macro name is defined in _sre.c the TRACE macro prints regex processing trace. It use the %d format specifier for Py_ssize_t values. This can crash on 64-bit. Proposed patch fixes format strings.

----------
components: Regular Expressions
files: re_trace_format.patch
keywords: patch
messages: 194561
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix format specifiers for debug output in _sre.c
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31177/re_trace_format.patch

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

From report at bugs.python.org  Tue Aug  6 18:13:42 2013
From: report at bugs.python.org (Igor Skochinsky)
Date: Tue, 06 Aug 2013 16:13:42 +0000
Subject: [issue17213] ctypes loads wrong version of C runtime,
	leading to error message box from system
In-Reply-To: <1360992800.86.0.617349310494.issue17213@psf.upfronthosting.co.za>
Message-ID: <1375805622.66.0.310299802378.issue17213@psf.upfronthosting.co.za>


Igor Skochinsky added the comment:

Just had this issue when using networkx (which imports uuid). One keyword that would help visibility is R6034 (the runtime error number). A couple of reports related to this:

https://projects.blender.org/tracker/index.php?func=detail&aid=27666
http://forums.boxee.tv/showthread.php?t=15425

The proper solution is to fix ctypes, but in the meantime we can at least fix uuid. The error seems to be triggered by this snippet:

    # The uuid_generate_* routines are provided by libuuid on at least
    # Linux and FreeBSD, and provided by libc on Mac OS X.
    for libname in ['uuid', 'c']:
        try:
            lib = ctypes.CDLL(ctypes.util.find_library(libname))
        except:
            continue
        if hasattr(lib, 'uuid_generate_random'):
            _uuid_generate_random = lib.uuid_generate_random
        if hasattr(lib, 'uuid_generate_time'):
            _uuid_generate_time = lib.uuid_generate_time

Since this code is useless on Windows, protecting it in "if os.name not in ['nt', 'ce']" does the trick.

BTW, instead of going all way with activation context etc., a simpler solution would be to add to ctypes something like this in CDLL.__init__:

if os.name in ['nt', 'ce'] and name == util.find_msvcrt():  # TODO: handle the extension
  self._handle = windll.kernel32.GetModuleHandleA(self._name)

i.e. use the already present runtime DLL instead of trying to load it again.

----------
nosy: +Igor.Skochinsky

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

From report at bugs.python.org  Tue Aug  6 18:18:29 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 06 Aug 2013 16:18:29 +0000
Subject: [issue18662] re.escape should not escape the hyphen
In-Reply-To: <1375722644.22.0.61356481393.issue18662@psf.upfronthosting.co.za>
Message-ID: <1375805908.99.0.825687908285.issue18662@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

I can think of a real disadvantage with the current behaviour: it messes up Unicode graphemes.

For example:

>>> print('??????')
??????
>>> print(re.escape('??????'))
\?\?\?\?\?\?

Of course, that's only a problem if you need to print it out or write it to a file.

----------

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

From report at bugs.python.org  Tue Aug  6 18:25:45 2013
From: report at bugs.python.org (productivememberofsociety666)
Date: Tue, 06 Aug 2013 16:25:45 +0000
Subject: [issue18669] curses.chgat() moves cursor,
	documentation says it shouldn't
In-Reply-To: <1375800170.73.0.20062232661.issue18669@psf.upfronthosting.co.za>
Message-ID: <1375806345.41.0.430600505498.issue18669@psf.upfronthosting.co.za>


Changes by productivememberofsociety666 <productivememberofsociety666 at sol.fr.am>:


Removed file: http://bugs.python.org/file31175/chgat-bug.py

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

From report at bugs.python.org  Tue Aug  6 18:26:45 2013
From: report at bugs.python.org (productivememberofsociety666)
Date: Tue, 06 Aug 2013 16:26:45 +0000
Subject: [issue18669] curses.chgat() moves cursor,
	documentation says it shouldn't
In-Reply-To: <1375800170.73.0.20062232661.issue18669@psf.upfronthosting.co.za>
Message-ID: <1375806405.68.0.415112252943.issue18669@psf.upfronthosting.co.za>


Changes by productivememberofsociety666 <productivememberofsociety666 at sol.fr.am>:


Added file: http://bugs.python.org/file31178/chgat-bug.py

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

From report at bugs.python.org  Tue Aug  6 18:43:32 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 06 Aug 2013 16:43:32 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1375807412.04.0.47920246774.issue13153@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

0xed is the start byte of a 3 bytes sequence (i.e. a BMP char), and it should be followed by two continuation bytes.

For some reason the traceback you pasted is missing the last part, that might provide some insight.  It could be one of these:
>>> b'\xed'.decode('utf-8') # not enough continuation bytes
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 0: unexpected end of data
>>> b'\xed\x7f'.decode('utf-8') # not a valid continuation byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 0: invalid continuation byte

----------

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

From report at bugs.python.org  Tue Aug  6 18:52:37 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Aug 2013 16:52:37 +0000
Subject: [issue18443] Misc/Readme still documents TextMate
In-Reply-To: <1373775366.01.0.177392157148.issue18443@psf.upfronthosting.co.za>
Message-ID: <3c8hjJ1fjSz7Lm0@mail.python.org>


Roundup Robot added the comment:

New changeset 5c74755e8f04 by Ezio Melotti in branch 'default':
#18443: remove the TextMate entry now that the bundle has been removed and fix ordering.  Patch by F?vry Thibault.
http://hg.python.org/cpython/rev/5c74755e8f04

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Aug  6 18:53:04 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 06 Aug 2013 16:53:04 +0000
Subject: [issue18443] Misc/Readme still documents TextMate
In-Reply-To: <1373775366.01.0.177392157148.issue18443@psf.upfronthosting.co.za>
Message-ID: <1375807984.44.0.67982372644.issue18443@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Aug  6 18:55:14 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Aug 2013 16:55:14 +0000
Subject: [issue18671] enhance formatting in logging package
In-Reply-To: <1375804669.84.0.0477385788117.issue18671@psf.upfronthosting.co.za>
Message-ID: <1375808114.41.0.965181812723.issue18671@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Tue Aug  6 18:58:35 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 06 Aug 2013 16:58:35 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
	with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1375808315.73.0.73503694237.issue18383@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

LGTM

----------

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

From report at bugs.python.org  Tue Aug  6 19:04:52 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 06 Aug 2013 17:04:52 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1375808692.73.0.232469988316.issue18647@psf.upfronthosting.co.za>


Tim Peters added the comment:

Serhiy, yup, that regexp is slow, but it does finish - so the engine is doing something to avoid _unbounded_ repetitive matching of an empty string.

Change it to

(?:.?.+)*y

and the group can no longer match an empty string, but it's still slow (although about 3x faster, it's still exponential in the length of the string it fails to match).

----------

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

From report at bugs.python.org  Tue Aug  6 21:43:40 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 06 Aug 2013 19:43:40 +0000
Subject: [issue18673] Add and use O_TMPFILE for Linux 3.11
Message-ID: <1375818220.16.0.883591943761.issue18673@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Linux 3.11 gets a new flag for open():

Quote from http://lwn.net/Articles/557314/
---
The new O_TMPFILE option to the open() and openat() system calls allows filesystems to optimize the creation of temporary files ? files which need not be visible in the filesystem. When O_TMPFILE is present, the provided pathname is only used to locate the containing directory (and thus the filesystem where the temporary file should be). So, among other things, programs using O_TMPFILE should have fewer concerns about vulnerabilities resulting from symbolic link attacks.
---

Tasks:

- add O_TEMPFILE to posixmodule.c
- use O_TEMPFILE in tempfile module when it's supported by the current kernel

----------
components: Extension Modules, Library (Lib)
messages: 194569
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: Add and use O_TMPFILE for Linux 3.11
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug  6 22:29:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Aug 2013 20:29:39 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za>
Message-ID: <1375820979.0.0.328962266779.issue15651@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a simplified patch tackling only the PEP 3121 compliance. Eli, I think this would be good to go.

----------
Added file: http://bugs.python.org/file31179/etree_3121.patch

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

From report at bugs.python.org  Tue Aug  6 22:38:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Aug 2013 20:38:51 +0000
Subject: [issue18674] Store weak references in modules_by_index
Message-ID: <1375821531.36.0.318072139637.issue18674@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

modules_by_index is a near-eternal store for extension modules. It is only collected at the end of interpreter shutdown, which is much too late for regular garbage collection. This patch proposes instead to store weak references in modules_by_index, so that extension modules can be collected in a normal way when they are removed from sys.modules.

The only gotcha is that PyState_FindModule returns a borrowed reference. With this change, it becomes really important to incref the returned reference as soon as possible.

----------
components: Interpreter Core
files: wr_module_state.patch
keywords: patch
messages: 194571
nosy: brett.cannon, eric.snow, loewis, ncoghlan, pitrou, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: Store weak references in modules_by_index
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file31180/wr_module_state.patch

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

From report at bugs.python.org  Tue Aug  6 22:57:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Aug 2013 20:57:38 +0000
Subject: [issue18621] site.py keeps too much stuff alive when it patches
	builtins
In-Reply-To: <1375390196.76.0.0867903823381.issue18621@psf.upfronthosting.co.za>
Message-ID: <3c8p813xg8z7Lld@mail.python.org>


Roundup Robot added the comment:

New changeset 8584f63e570e by Antoine Pitrou in branch 'default':
Issue #18621: Prevent the site module's patched builtins from keeping too many references alive for too long.
http://hg.python.org/cpython/rev/8584f63e570e

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Aug  6 22:59:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Aug 2013 20:59:05 +0000
Subject: [issue18621] site.py keeps too much stuff alive when it patches
	builtins
In-Reply-To: <1375390196.76.0.0867903823381.issue18621@psf.upfronthosting.co.za>
Message-ID: <1375822745.83.0.227381226171.issue18621@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I went ahead and committed this, so that the effect of other improvements in the area stand out better.

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

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

From report at bugs.python.org  Tue Aug  6 23:05:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Aug 2013 21:05:31 +0000
Subject: [issue18666] Unused variable in test_frame.py
In-Reply-To: <1375765297.44.0.682936392521.issue18666@psf.upfronthosting.co.za>
Message-ID: <3c8pK650YNz7LkN@mail.python.org>


Roundup Robot added the comment:

New changeset 34e1ecb8edd2 by Antoine Pitrou in branch 'default':
Issue #18666: improve test_frame a bit. Patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/34e1ecb8edd2

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Aug  6 23:05:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Aug 2013 21:05:51 +0000
Subject: [issue18666] Unused variable in test_frame.py
In-Reply-To: <1375765297.44.0.682936392521.issue18666@psf.upfronthosting.co.za>
Message-ID: <1375823151.59.0.977158471021.issue18666@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Good idea, thank you!

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

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

From report at bugs.python.org  Tue Aug  6 23:07:08 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Aug 2013 21:07:08 +0000
Subject: [issue18665] Typos in frame object related code
In-Reply-To: <1375764800.58.0.482122024787.issue18665@psf.upfronthosting.co.za>
Message-ID: <3c8pLz4dJjz7LkN@mail.python.org>


Roundup Robot added the comment:

New changeset 89ce323357db by Antoine Pitrou in branch 'default':
Issue #18665: fix typos.  Patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/89ce323357db

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Aug  6 23:07:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Aug 2013 21:07:33 +0000
Subject: [issue18665] Typos in frame object related code
In-Reply-To: <1375764800.58.0.482122024787.issue18665@psf.upfronthosting.co.za>
Message-ID: <1375823253.21.0.0137643855807.issue18665@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thank you :)

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

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

From report at bugs.python.org  Tue Aug  6 23:09:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Aug 2013 21:09:04 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1375823344.05.0.153253356884.issue8713@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file31181/d9fe9757ba0c.diff

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

From report at bugs.python.org  Tue Aug  6 23:09:51 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 06 Aug 2013 21:09:51 +0000
Subject: [issue18671] enhance formatting in logging package
In-Reply-To: <1375804669.84.0.0477385788117.issue18671@psf.upfronthosting.co.za>
Message-ID: <1375823391.98.0.540489527162.issue18671@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

In recent versions of Python, information *is* printed which allows pinpointing the source of the formatting error. Consider the following script, logex.py:

import logging

logger = logging.getLogger(__name__)

def test():
    logger.debug('The result is ', 'abc')

def main():
    test()

if __name__ == '__main__':
    logging.basicConfig(level=logging.DEBUG)
    main()

When this is run with Python 2.7:

$ python logex.py
Traceback (most recent call last):
  File "/usr/lib/python2.7/logging/__init__.py", line 842, in emit
    msg = self.format(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 719, in format
    return fmt.format(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 464, in format
    record.message = record.getMessage()
  File "/usr/lib/python2.7/logging/__init__.py", line 328, in getMessage
    msg = msg % self.args
TypeError: not all arguments converted during string formatting
Logged from file logex.py, line 6

With Python 3.2:

$ python3.2 logex.py
Traceback (most recent call last):
  File "/usr/lib/python3.2/logging/__init__.py", line 937, in emit
    msg = self.format(record)
  File "/usr/lib/python3.2/logging/__init__.py", line 812, in format
    return fmt.format(record)
  File "/usr/lib/python3.2/logging/__init__.py", line 551, in format
    record.message = record.getMessage()
  File "/usr/lib/python3.2/logging/__init__.py", line 319, in getMessage
    msg = msg % self.args
TypeError: not all arguments converted during string formatting
Logged from file logex.py, line 6

As you can see, the filename and line number are identified, so you can see precisely where the formatting error is.

----------
components: +Library (Lib) -Extension Modules
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Tue Aug  6 23:11:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Aug 2013 21:11:19 +0000
Subject: [issue18528] Possible fd leak in socketmodule
In-Reply-To: <1374496496.68.0.51305379842.issue18528@psf.upfronthosting.co.za>
Message-ID: <1375823479.77.0.716141730662.issue18528@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> I don't understand why we would call accept() more than once.

Because of EINTR?

----------

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

From report at bugs.python.org  Tue Aug  6 23:14:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Aug 2013 21:14:50 +0000
Subject: [issue18673] Add and use O_TMPFILE for Linux 3.11
In-Reply-To: <1375818220.16.0.883591943761.issue18673@psf.upfronthosting.co.za>
Message-ID: <1375823690.43.0.581466218305.issue18673@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> - use O_TEMPFILE in tempfile module when it's supported by the current 
> kernel

I assume this would only be done in TemporaryFile()?

----------
components:  -Extension Modules
keywords: +easy
nosy: +pitrou

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

From report at bugs.python.org  Tue Aug  6 23:25:49 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Aug 2013 21:25:49 +0000
Subject: [issue18290] json encoder does not support JSONP/JavaScript safe
	escaping
In-Reply-To: <1372049179.79.0.237326954931.issue18290@psf.upfronthosting.co.za>
Message-ID: <1375824349.62.0.711607520812.issue18290@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

On the one hand, supporting JSONP is a valid request for the json module. On the other hand, according to Wikipedia, "There have been some criticisms raised about JSONP. Cross-origin resource sharing (CORS) is a more recent method of getting data from a server in a different domain, which addresses some of those criticisms". Therefore, supporting JSONP might not really be worth it.

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

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

From report at bugs.python.org  Tue Aug  6 23:26:01 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 06 Aug 2013 21:26:01 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za>
Message-ID: <1375824361.17.0.485098008305.issue15651@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Bless you Antoine, I've been just planning to do this myself to tackle the re-importing troubles I was having in tests the other day :-)

I'll take a look at this soon, promise!

----------

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

From report at bugs.python.org  Tue Aug  6 23:28:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Aug 2013 21:28:00 +0000
Subject: [issue18659] test_precision in test_format.py is not executed and has
	unused variable
In-Reply-To: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>
Message-ID: <1375824480.26.0.152812348268.issue18659@psf.upfronthosting.co.za>


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


----------
nosy: +eric.smith

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

From report at bugs.python.org  Tue Aug  6 23:29:20 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 06 Aug 2013 21:29:20 +0000
Subject: [issue18674] Store weak references in modules_by_index
In-Reply-To: <1375821531.36.0.318072139637.issue18674@psf.upfronthosting.co.za>
Message-ID: <1375824560.89.0.883299221181.issue18674@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Won't that change to PyState_FindModule() break code? And is it part of the stable ABI?

----------

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

From report at bugs.python.org  Tue Aug  6 23:37:44 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Aug 2013 21:37:44 +0000
Subject: [issue18674] Store weak references in modules_by_index
In-Reply-To: <1375821531.36.0.318072139637.issue18674@psf.upfronthosting.co.za>
Message-ID: <1375825064.19.0.13296104467.issue18674@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Theoretically, people *should* already incref the result from PyState_FindModule. On the other hand, the object currently wouldn't be lost unless something else calls PyState_RemoveModule(), which is hardly every used AFAICT.

The only saving grace is that PyState_FindModule() is py3-specific, and only used for extension modules which have a positive m_size (probably not many of them yet).

(I think this issue teaches us that borrowed ref-returning APIs are a bad idea)

Unfortunately, without this change, we also make it difficult or impossible to reclaim extension modules using the GC. At least I cannot think of another way.

----------

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

From report at bugs.python.org  Tue Aug  6 23:39:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Aug 2013 21:39:35 +0000
Subject: [issue18667] missing HAVE_FCHOWNAT
In-Reply-To: <1375772087.0.0.361755653525.issue18667@psf.upfronthosting.co.za>
Message-ID: <1375825175.18.0.531357913407.issue18667@psf.upfronthosting.co.za>


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


----------
nosy: +larry

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

From report at bugs.python.org  Tue Aug  6 23:51:05 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 06 Aug 2013 21:51:05 +0000
Subject: [issue18667] missing HAVE_FCHOWNAT
In-Reply-To: <1375772087.0.0.361755653525.issue18667@psf.upfronthosting.co.za>
Message-ID: <1375825865.26.0.650988208843.issue18667@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Yup, that's a bug.  My fault too.  I think it should go in to the next 3.3 as well.

I worry that this may be a similar situation to fchmodat--see the comment in Lib/os.py--but for now let's be brave and add HAVE_FCHOWNAT to have_functions as salinger suggests.

----------
versions: +Python 3.3

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

From report at bugs.python.org  Tue Aug  6 23:53:58 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 06 Aug 2013 21:53:58 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1375826038.87.0.733196014777.issue13153@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Byte 0, not byte 1, is the start byte, and it should be F0, as in output below. However, I now see "invalid continuation byte'.
In 2.7.5,
# -*- coding: utf-8 -*-
s = b'?'  # output same if uncomment following lines
#s = u'?'.encode('utf-8')  # '?' pasted in from 1st post
#s = u'\U000104a2'.encode('utf-8')  
print(len(s))
for c in s: print(ord(c), hex(ord(c)))
>>> 
4
(240, '0xf0')
(144, '0x90')
(146, '0x92')
(162, '0xa2')

I have no idea how the second pasted byte becomes ED in 3.x.

Attempting to open the file in 3.x results in a broken* 'Untitled' edit window and the following error message in the console.
_tkinter.TclError: character U+104a2 is above the range (U+0000-U+FFFF) allowed by Tcl

* Attempting to close the window either immediately or after entering text results in
AttributeError: 'PyShellEditorWindow' object has no attribute 'extensions'
I have to close the initial python process to get rid of it.

----------

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

From report at bugs.python.org  Wed Aug  7 00:04:17 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 06 Aug 2013 22:04:17 +0000
Subject: [issue18674] Store weak references in modules_by_index
In-Reply-To: <1375821531.36.0.318072139637.issue18674@psf.upfronthosting.co.za>
Message-ID: <1375826657.4.0.964445766175.issue18674@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Sounds like it needs to be changed with a notice in What's New.

----------

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

From report at bugs.python.org  Wed Aug  7 00:17:31 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 06 Aug 2013 22:17:31 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1375805266.28.0.128618982976.issue18416@psf.upfronthosting.co.za>
Message-ID: <CADiSq7e9+k1d_haG53XLz=SJySH89LVSXg0SBB9bOoiqK85vTQ@mail.gmail.com>


Nick Coghlan added the comment:

Make sure to run "make" to rebuild the frozen module - editing
importlib._bootstrap.py involves a C style "edit, build, test" cycle rather
than the typical Python "edit, test" cycle.

----------

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

From report at bugs.python.org  Wed Aug  7 01:00:48 2013
From: report at bugs.python.org (M. Dietrich)
Date: Tue, 06 Aug 2013 23:00:48 +0000
Subject: [issue18671] enhance formatting in logging package
In-Reply-To: <1375804669.84.0.0477385788117.issue18671@psf.upfronthosting.co.za>
Message-ID: <1375830048.97.0.470234725831.issue18671@psf.upfronthosting.co.za>


M. Dietrich added the comment:

yes, seeing the erranous line where the wrong formatstring comes from is nice but sometimes (for myself: often) i need to know what actually was tried to be logged. this information is lost in both cases.

this is especially sad if you have long-running processes that encounter an error after a long time and that error is logged but the logging itself fails due to formatting issues. i suggest to log whatever is avaiable in the suggested way to at least see this valuable information. the additional information where it comes from for further fixing is apreaciated as well. btw: the stackstrace of the logging internals could be left out in my oppinion, it just pollutes the output with no means to the programer.

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

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

From report at bugs.python.org  Wed Aug  7 01:01:41 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Aug 2013 23:01:41 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1375830101.38.0.941243598386.issue16853@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Yeah, the timeouts are a bad idea anyway.  I've filed http://code.google.com/p/tulip/issues/detail?id=49 to remind us to do something about this.

I'll review your tulip patch next.

----------

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

From report at bugs.python.org  Wed Aug  7 01:16:21 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 06 Aug 2013 23:16:21 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1373400107.5.0.285657244525.issue18416@psf.upfronthosting.co.za>
Message-ID: <1375830981.93.0.472397887688.issue18416@psf.upfronthosting.co.za>


Madison May added the comment:

Thanks for the heads up, Nick.  I've worked with _bootstrap.py before, so I'm familiar with the cycle.

----------

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

From report at bugs.python.org  Wed Aug  7 01:33:16 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Aug 2013 23:33:16 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1375831996.78.0.842152197232.issue16853@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Actually there is a misunderstanding underlying you Tulip patch.  Tulip needs to support Python 3.3 as well as Python 3.4, so it needs to do a little dance trying to import BaseSelector (or some other key class) from select and if that fails fall back to its own selectors.py.

Since you aren't changing the BaseSelector API at all this is trivial and I can take care of it.

----------

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

From report at bugs.python.org  Wed Aug  7 01:55:39 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 06 Aug 2013 23:55:39 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1375456613.31.0.987002581332.issue16853@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+XOepU-wuJw5ii2jxKQpFM1tK-Ljj2-LT=gFk0e1hO3w@mail.gmail.com>


Guido van Rossum added the comment:

Sorry, replying to some direct questions in the bug:

> I also made the following changes:
> - BaseSelector is an abstract base class (so one could imagine user code
> implementing its own selector on top of it)

Fine (though I had to work around this for some tulip tests).

> - SelectorKey is a named tuple: I think that's better than a class,
> because SelectorKeys can be returned to the user (register(), get_info(),
> etc), and we don't want him to mess with them. Also, we get a nice repr()
> for free

Fine.

> - since SelectorKey is immutable, I added a get_keys() method, which
> returns all the keys registered. Since it's a dict values, the user can't
> mess with it

Fine. (I missed this in the code review.)

> This get_keys() method superseedes the registered_count() method, which
> can be simply replaced with len(selector.get_keys()). We could probably
> remove it? It also sort of superseedes the get_info() method: I don't
> remember, why was it needed?

registered_count() is only used internally so you can kill it.

get_info() is important for Tulip, please keep it.

> Would it be possible to get it into 3.4?

I think so, if Antoine agrees. The next alpha would be at your service.

----------

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

From report at bugs.python.org  Wed Aug  7 02:01:36 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 07 Aug 2013 00:01:36 +0000
Subject: [issue18671] enhance formatting in logging package
In-Reply-To: <1375804669.84.0.0477385788117.issue18671@psf.upfronthosting.co.za>
Message-ID: <1375833696.81.0.20864048556.issue18671@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

The location of the error isn't lost - that's the important thing. If it's that important that you never lose the parameters of a logging call, then you could just double check the formatting for errors, or use a specialised message object, as described in the documentation, which allows you control over the formatting:

http://docs.python.org/2/howto/logging.html#using-arbitrary-objects-as-messages

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

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

From report at bugs.python.org  Wed Aug  7 03:49:56 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Aug 2013 01:49:56 +0000
Subject: [issue18674] Store weak references in modules_by_index
In-Reply-To: <1375821531.36.0.318072139637.issue18674@psf.upfronthosting.co.za>
Message-ID: <1375840196.98.0.117433808484.issue18674@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

It seems to me that the more appropriate change here would be to redefine PyState_FindModule as return a *new* ref rather than a borrowed ref and have it do the Py_INCREF before returning.

Code using it would then need to add an appropriate Py_DECREF. A reference leak is generally a less dangerous bug than an early free.

----------

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

From report at bugs.python.org  Wed Aug  7 06:58:41 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Aug 2013 04:58:41 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1375830981.93.0.472397887688.issue18416@psf.upfronthosting.co.za>
Message-ID: <CADiSq7c=a_a=cfzHTZfkvdFsX6NP4WXwjO=sDY4dQ-bvBip=wQ@mail.gmail.com>


Nick Coghlan added the comment:

Figured it was worth mentioning, since I've been caught by forgetting
that myself :)

I suspect you're right that it's just a case of '.' passing the truth
test, even though it still results in a relative path.

----------

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

From report at bugs.python.org  Wed Aug  7 09:45:33 2013
From: report at bugs.python.org (Thomas Guettler)
Date: Wed, 07 Aug 2013 07:45:33 +0000
Subject: [issue1596321] KeyError at exit after 'import threading' in other
	thread
Message-ID: <1375861533.43.0.108147005605.issue1596321@psf.upfronthosting.co.za>


Thomas Guettler added the comment:

Only few people seem to use daemon threads. We do and see this problem often with Python 2.7.

How difficult is it to get this fixed for 2.7?

Is there a way to work around this problem?

----------
nosy: +guettli

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

From report at bugs.python.org  Wed Aug  7 10:02:30 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Aug 2013 08:02:30 +0000
Subject: [issue18674] Store weak references in modules_by_index
In-Reply-To: <1375840196.98.0.117433808484.issue18674@psf.upfronthosting.co.za>
Message-ID: <1301002546.47906547.1375862544095.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> It seems to me that the more appropriate change here would be to
> redefine PyState_FindModule as return a *new* ref rather than a
> borrowed ref and have it do the Py_INCREF before returning.
> 
> Code using it would then need to add an appropriate Py_DECREF. A
> reference leak is generally a less dangerous bug than an early free.

I hadn't thought about that. Code must add Py_DECREF only on 3.4+, then.

----------

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

From report at bugs.python.org  Wed Aug  7 11:05:59 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 07 Aug 2013 09:05:59 +0000
Subject: [issue15787] PEP 3121 Refactoring
In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za>
Message-ID: <1375866359.53.0.345964230462.issue15787@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
dependencies: +PEP 3121 Refactoring applied to _csv module

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

From report at bugs.python.org  Wed Aug  7 11:07:47 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 07 Aug 2013 09:07:47 +0000
Subject: [issue15787] PEP 3121 Refactoring
In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za>
Message-ID: <1375866467.15.0.33153472509.issue15787@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
dependencies: +PEP 3121, 384 refactoring applied to curses_panel module

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

From report at bugs.python.org  Wed Aug  7 11:10:29 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 07 Aug 2013 09:10:29 +0000
Subject: [issue15787] PEP 3121, 384 Refactoring
In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za>
Message-ID: <1375866629.79.0.219476976872.issue15787@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
dependencies: +PEP 384 Refactoring applied to _csv module
title: PEP 3121 Refactoring -> PEP 3121, 384 Refactoring

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

From report at bugs.python.org  Wed Aug  7 11:13:37 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 07 Aug 2013 09:13:37 +0000
Subject: [issue15787] PEP 3121, 384 Refactoring
In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za>
Message-ID: <1375866817.75.0.994341809252.issue15787@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
dependencies: +PEP 384 inconsistent with implementation

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

From report at bugs.python.org  Wed Aug  7 11:21:03 2013
From: report at bugs.python.org (Thomas Guettler)
Date: Wed, 07 Aug 2013 09:21:03 +0000
Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads
	running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <1375867263.71.0.814492313411.issue1856@psf.upfronthosting.co.za>


Thomas Guettler added the comment:

There are some examples to work around this for Python2: http://stackoverflow.com/questions/18098475/detect-interpreter-shut-down-in-daemon-thread

----------
nosy: +guettli

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

From report at bugs.python.org  Wed Aug  7 11:21:46 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 07 Aug 2013 09:21:46 +0000
Subject: [issue15787] PEP 3121, 384 Refactoring
In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za>
Message-ID: <1375867306.55.0.91837715789.issue15787@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

"""
Regarding the suggestion of separating PEP3121 and PEP384. It might be true that datetime and other modules do not benefit directly from PEP 384, however it is still a fact that the stdlib modules should be seen as a set of reference modules, that are all implemented in a way that complies with the implementation fo the xxmodules.
I have talked with Martin von L?wis about this, and as far as I understood him correctly he also sees the PEP384 refactoring applied to the whole stdlib as a necessary "signal" to other developers to refactor their modules accordingly.
""" (Robin Schreiber, #15390, msg177274)

MvL have recently confirmed this on python-dev: "Choice of supporting PEP 384 was deliberate. It will change all types into heap types, which is useful for multiple-interpreter support and GC."

Accordingly, I've changed the title of this issue and added a few PEP 384 only dependencies.

----------

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

From report at bugs.python.org  Wed Aug  7 11:23:16 2013
From: report at bugs.python.org (Thomas Guettler)
Date: Wed, 07 Aug 2013 09:23:16 +0000
Subject: [issue18675] Daemon Threads can seg fault
Message-ID: <1375867396.76.0.697227657582.issue18675@psf.upfronthosting.co.za>


New submission from Thomas Guettler:

This is a documentation bug: Since #1856  is not solved for Python2, it needs to be documented.

Daemon Threads on Python2 can seg fault.

Work arounds: http://stackoverflow.com/questions/18098475/detect-interpreter-shut-down-in-daemon-thread

----------
assignee: docs at python
components: Documentation
messages: 194601
nosy: docs at python, guettli
priority: normal
severity: normal
status: open
title: Daemon Threads can seg fault
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Aug  7 11:23:36 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 07 Aug 2013 09:23:36 +0000
Subject: [issue15787] PEP 3121, 384 Refactoring
In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za>
Message-ID: <1375867416.48.0.219914104404.issue15787@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy: +pitrou

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

From report at bugs.python.org  Wed Aug  7 11:34:13 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 07 Aug 2013 09:34:13 +0000
Subject: [issue15787] PEP 3121, 384 Refactoring
In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za>
Message-ID: <1375868053.43.0.99191595519.issue15787@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

With respect to PEP 384 refactoring, I would like to see Tools/scripts/abitype.py used for most of the conversions.  The PEP itself can probably be amended to advertise this tool more prominently.

----------

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

From report at bugs.python.org  Wed Aug  7 12:01:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Aug 2013 10:01:05 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1375869665.56.0.425122885877.issue13153@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

u'\U000104a2' == u'\ud801\udca2' on narrow build.

u'\ud801'.encode('utf-8', 'surrogatepass') == b'\xed\xa0\x81'
u'\udca2'.encode('utf-8', 'surrogatepass') == b'\xed\xb2\xa2'

Hope it will help.

----------

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

From report at bugs.python.org  Wed Aug  7 13:23:04 2013
From: report at bugs.python.org (M. Dietrich)
Date: Wed, 07 Aug 2013 11:23:04 +0000
Subject: [issue18671] enhance formatting in logging package
In-Reply-To: <1375804669.84.0.0477385788117.issue18671@psf.upfronthosting.co.za>
Message-ID: <1375874584.95.0.381166066073.issue18671@psf.upfronthosting.co.za>


M. Dietrich added the comment:

for a logging library the important thing would be to not loose the information that was meant to log. as i said i do alot of long-running huge-data-processing scripts in py using the library. if the logging breaks but doesnt log what was intended to log i judge this a major problem. and furthermore: it is so simple to add both information: the data that was to be logged plus the state that an error occured while formatting and where the log-call was made.

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

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

From report at bugs.python.org  Wed Aug  7 14:54:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Aug 2013 12:54:57 +0000
Subject: [issue18668] Properly document setting m_size in PyModuleDef
In-Reply-To: <1375795246.61.0.949649493069.issue18668@psf.upfronthosting.co.za>
Message-ID: <3c9CNc6Qf2z7Lm6@mail.python.org>


Roundup Robot added the comment:

New changeset 698fd628b001 by Eli Bendersky in branch '3.3':
Issue #18668: Properly document setting m_size in PyModuleDef
http://hg.python.org/cpython/rev/698fd628b001

New changeset 9877c25d9556 by Eli Bendersky in branch 'default':
Closing #18668: Properly document setting m_size in PyModuleDef
http://hg.python.org/cpython/rev/9877c25d9556

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Aug  7 14:55:25 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 07 Aug 2013 12:55:25 +0000
Subject: [issue18668] Properly document setting m_size in PyModuleDef
In-Reply-To: <1375795246.61.0.949649493069.issue18668@psf.upfronthosting.co.za>
Message-ID: <1375880125.87.0.432442027172.issue18668@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Thanks for the review!

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

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

From report at bugs.python.org  Wed Aug  7 14:55:54 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 07 Aug 2013 12:55:54 +0000
Subject: [issue18668] Properly document setting m_size in PyModuleDef
In-Reply-To: <1375795246.61.0.949649493069.issue18668@psf.upfronthosting.co.za>
Message-ID: <1375880154.4.0.271359421302.issue18668@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


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

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

From report at bugs.python.org  Wed Aug  7 15:11:17 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 07 Aug 2013 13:11:17 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za>
Message-ID: <1375881077.68.0.595566651837.issue15651@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Antoine, some questions about the patch:

First, I think it omits expat_capi from the state. Is that intentional?

Second, I'm not sure if this approach is fully aligned with PEP 3121. A global, shared state is still used. Instead of actually having a different module state per subinterpreter, this patch will have shared state. Another problem seems to be using PyModule_FindModule without using PyModule_AddModule first. 

These problems could be shared to all of Robin's original patches. Of course, there's also the possibility that I don't fully understand PEP 3121 yet :)

----------

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

From report at bugs.python.org  Wed Aug  7 15:28:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Aug 2013 13:28:36 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1375881077.68.0.595566651837.issue15651@psf.upfronthosting.co.za>
Message-ID: <1404971900.48608507.1375882110112.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> First, I think it omits expat_capi from the state. Is that
> intentional?

What would it do in the state? There's nothing to release.

> Second, I'm not sure if this approach is fully aligned with PEP 3121.
> A global, shared state is still used. Instead of actually having a
> different module state per subinterpreter, this patch will have
> shared state.

I don't understand what you are talking about. Perhaps you haven't looked
what PyState_FindModule() does?

----------

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

From report at bugs.python.org  Wed Aug  7 15:32:30 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Aug 2013 13:32:30 +0000
Subject: [issue18668] Properly document setting m_size in PyModuleDef
In-Reply-To: <1375880154.43.0.901535903334.issue18668@psf.upfronthosting.co.za>
Message-ID: <CADiSq7exfE1EzpXvYw7jPRQER_v-j7QqF+OmhBOiuRmG393BVw@mail.gmail.com>


Nick Coghlan added the comment:

I thought setting m_size to zero was for "No per module state, but
reinitialization is fine"? Does that not work? (I haven't actually tried it)

----------

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

From report at bugs.python.org  Wed Aug  7 15:47:16 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 07 Aug 2013 13:47:16 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1404971900.48608507.1375882110112.JavaMail.root@zimbra10-e2.priv.proxad.net>
Message-ID: <CAF-Rda9PFepvu4VY1Ux_xZnbyhzevoMAoqoGfv-LSU_jQphq2g@mail.gmail.com>


Eli Bendersky added the comment:

On Wed, Aug 7, 2013 at 6:28 AM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou added the comment:
>
> > First, I think it omits expat_capi from the state. Is that
> > intentional?
>
> What would it do in the state? There's nothing to release.
>

That's true, but I thought one of the goals of PEP 3121 is to separate
states between sub-interpreters. So that one can't corrupt another. I'm not
sure how much it matters in practice in this case of the pyexpat capsule;
need to look into it more.

> > Second, I'm not sure if this approach is fully aligned with PEP 3121.
> > A global, shared state is still used. Instead of actually having a
> > different module state per subinterpreter, this patch will have
> > shared state.
>
> I don't understand what you are talking about. Perhaps you haven't looked
> what PyState_FindModule() does?
>

I did not look at the implementation yet. But the documentation says:

"""Returns the module object that was created from *def* for the current
interpreter. This method requires that the module object has been attached
to the interpreter state with
PyState_AddModule()<http://docs.python.org/dev/c-api/module.html?highlight=pymoduledef_base#PyState_AddModule>beforehand.
In case the corresponding module object is not found or has not
been attached to the interpreter state yet, it returns NULL."""

I don't see a call to PyState_AddModule. What am I missing?

----------

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

From report at bugs.python.org  Wed Aug  7 15:52:08 2013
From: report at bugs.python.org (Zhongyue Luo)
Date: Wed, 07 Aug 2013 13:52:08 +0000
Subject: [issue18676] Queue: zero should not be accepted as timeout value
Message-ID: <1375883528.55.0.275850242187.issue18676@psf.upfronthosting.co.za>


New submission from Zhongyue Luo:

The docstring of methods put() and get() in Queue.py states

get(): If 'timeout' is a positive number, it blocks at most 'timeout' seconds and raises the Full exception if no free slot was available within that time.

put(): If 'timeout' is a positive number, it blocks at most 'timeout' seconds and raises the Empty exception if no item was available within that time.

Additionally the ValueError both methods raise is

 raise ValueError("'timeout' must be a positive number")

However the logic checks if 'timeout' is non-negative.

 elif timeout < 0:
     raise ValueError("'timeout' must be a positive number")

The logic should change as

 elif timeout <= 0:
     raise ValueError("'timeout' must be a positive number")

----------
components: Library (Lib)
messages: 194611
nosy: zyluo
priority: normal
severity: normal
status: open
title: Queue: zero should not be accepted as timeout value
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug  7 16:00:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Aug 2013 14:00:07 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <CAF-Rda9PFepvu4VY1Ux_xZnbyhzevoMAoqoGfv-LSU_jQphq2g@mail.gmail.com>
Message-ID: <1399729306.48655520.1375884001005.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> That's true, but I thought one of the goals of PEP 3121 is to
> separate
> states between sub-interpreters. So that one can't corrupt another.
> I'm not
> sure how much it matters in practice in this case of the pyexpat
> capsule;
> need to look into it more.

pyexpat's "capi" object is a static struct inside pyexpat.c, so that
wouldn't change anything.
Separating states between sub-interpreters only matters when said state
is mutable, which it isn't here.

> I don't see a call to PyState_AddModule. What am I missing?

It is called implicitly when an extension module is imported.

----------

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

From report at bugs.python.org  Wed Aug  7 16:11:40 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Aug 2013 14:11:40 +0000
Subject: [issue18676] Queue: document that zero is accepted as timeout value
In-Reply-To: <1375883528.55.0.275850242187.issue18676@psf.upfronthosting.co.za>
Message-ID: <1375884700.35.0.298090985729.issue18676@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is more of a documentation issue than a code issue.  To be mathematically precise, the text and error message should read "a non-negative value".  Alternatively the text and error could be changed to report that timeout may not be negative, which would probably be clearer.  (Note that timeout is a float value, and thus the proposed code change would only break code, it would not change the functionality in any significant way.)

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray
title: Queue: zero should not be accepted as timeout value -> Queue: document that zero is accepted as timeout value
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Aug  7 16:15:20 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 07 Aug 2013 14:15:20 +0000
Subject: [issue18671] enhance formatting in logging package
In-Reply-To: <1375804669.84.0.0477385788117.issue18671@psf.upfronthosting.co.za>
Message-ID: <1375884920.64.0.433087813368.issue18671@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

>From the line number you mentioned, it looks like you're talking about Python 2.7. However, Python 2.7 is closed to new features: generally speaking, only bug fixes are supposed to be committed to this branch.

I can consider expanding the "Logged from ..." error message for 3.4.

----------
resolution: invalid -> 
status: open -> pending
versions: +Python 3.4

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

From report at bugs.python.org  Wed Aug  7 16:22:07 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 07 Aug 2013 14:22:07 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
Message-ID: <1375885327.18.0.790620363467.issue18677@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

A proposed patch adds two features to context managers:

1)It has always irked me that it was impossible to assemble nested context managers in the python language. See issue #5251.
The main problem, that exceptions in __enter__ cannot be properly handled, is fixed by introducing a new core exception, ContextManagerExit.  When raised by __enter__(), the body that the context manager protects is skipped.  This exception is in the spirit of other semi-internal exceptions such as GeneratorExit and StopIteration.  Using this exception, contextlib.nested can properly handle the case where the body isn't run because of an internal __enter__ exception which is handled by an outer __exit__.

2) The mechanism used in implementing ContextManagerExit above is easily extended to allowing a special context manager: None.  This is useful for having _optional_ context managers.  E.g. code like this:
    with performance_timer():
        do_work()

    def performance_timer():
        if profiling:
            return accumulator
        return None

None becomes the trivial context manager and its __enter__ and __exit__ calls are skipped, along with their overhead.

This patch implements both features.
In addition, it:
1) reintroduces contextlib.nested, which is based on nested_delayed
2) introduces contextlib.nested_delayed, which solves the other problem with previous versions of nested, that an inner context manager expression shouldn't be evaluated early.  contextlib.nested evaluates callables returning context managers, rather than managers directly.
3) Allows contextlib.contextmanager decorated functions to not yield, which amounts to skipping the protected body (implicitly raising ContextManagerExit)
4) unittests for the whole thing.

I'll introduce this stuff on python-ideas as well.

----------
components: Interpreter Core
files: contextmanagerexit.patch
keywords: patch
messages: 194615
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Enhanced context managers with ContextManagerExit and None
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31182/contextmanagerexit.patch

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

From report at bugs.python.org  Wed Aug  7 16:29:53 2013
From: report at bugs.python.org (Steven Velez)
Date: Wed, 07 Aug 2013 14:29:53 +0000
Subject: [issue11619] On Windows,
	don't encode filenames in the import machinery
In-Reply-To: <1300665531.85.0.426527059221.issue11619@psf.upfronthosting.co.za>
Message-ID: <1375885793.55.0.619946041492.issue11619@psf.upfronthosting.co.za>


Steven Velez added the comment:

This may be a small use case, but a use case none-the less.  In my situation, I am distributing a frozen python package and it runs under the users home directory.   If the user's name has international characters, this will fail.

I expect we will have similar problems when dealing with our application which embeds python and is also running from within the user directory...

----------
nosy: +Steven.Velez

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

From report at bugs.python.org  Wed Aug  7 16:44:39 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Aug 2013 14:44:39 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
In-Reply-To: <1375885327.18.0.790620363467.issue18677@psf.upfronthosting.co.za>
Message-ID: <1375886679.42.0.377205129998.issue18677@psf.upfronthosting.co.za>


R. David Murray added the comment:

Your use cases are either already addressed by contextlib.ExitStack, or should be addressed in the context of its existence.  It is the replacement for contextlib.nested.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18677>
_______________________________________

From report at bugs.python.org  Wed Aug  7 16:50:00 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 07 Aug 2013 14:50:00 +0000
Subject: [issue18678] Wrong struct members name for spwd module
Message-ID: <1375887000.77.0.620898445025.issue18678@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Both python2 and python3 have this behaviour.

>>> import os; os.getuid()
0
>>> 'I am root'
'I am root'
>>> import spwd
>>> spwd.getspnam('bin')
spwd.struct_spwd(sp_nam='bin', sp_pwd='*', sp_lstchg=15558, sp_min=0, sp_max=99999, sp_warn=7, sp_inact=-1, sp_expire=-1, sp_flag=-1)
>>> spwd.getspnam.__doc__
'getspnam(name) -> (sp_namp, sp_pwdp, sp_lstchg, sp_min, sp_max,\n                    sp_warn, sp_inact, sp_expire, sp_flag)\nReturn the shadow password database entry for the given user name.\nSee spwd.__doc__ for more on shadow password database entries.'

The documentation tells the function getspnam will give struct which has member sp_namp and sp_pwdp. But as you can see, the function getspnam gives me a tuple with has member sp_nam (without p) and sp_pwd (without p).

If you "man spwd", you can see the documentation is correct:
Structure
       The shadow password structure is defined in <shadow.h> as follows:

           struct spwd {
               char *sp_namp;     /* Login name */
               char *sp_pwdp;     /* Encrypted password */
               long  sp_lstchg;   /* Date of last change (measured
                                     in days since 1970-01-01 00:00:00 +0000 (UTC)) */
               long  sp_min;      /* Min # of days between changes */
               long  sp_max;      /* Max # of days between changes */
               long  sp_warn;     /* # of days before password expires
                                     to warn user to change it */
               long  sp_inact;    /* # of days after password expires
                                     until account is disabled */
               long  sp_expire;   /* Date when account expires (measured
                                     in days since 1970-01-01 00:00:00 +0000 (UTC)) */
               unsigned long sp_flag;  /* Reserved */
           };

For curious souls who do not have unix box:
http://linux.die.net/man/3/getspnam

I have contemplated about whether this behaviour is intended as it is, but I guess this is just a bug. Typo.

Attached the patch to fix this inconsistency. I also fixed some documentation about sp_inact and sp_expire.

I only marked this as Python 3.4 fix because I am not sure whether we should backport it to previous python versions. Some programs that expect sp_nam and sp_pwd names could break.

----------
components: Extension Modules
files: spwd_struct_members_name_fix.patch
keywords: patch
messages: 194618
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Wrong struct members name for spwd module
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31183/spwd_struct_members_name_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18678>
_______________________________________

From report at bugs.python.org  Wed Aug  7 16:58:29 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Aug 2013 14:58:29 +0000
Subject: [issue18678] Wrong struct members name for spwd module
In-Reply-To: <1375887000.77.0.620898445025.issue18678@psf.upfronthosting.co.za>
Message-ID: <1375887509.47.0.0976413745634.issue18678@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ideally, for backward compatibility reasons we really ought to support access by the old (incorrect) name even in 3.4 (with a deprecation warning, even more ideally).  I'm not sure if that's practical?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18678>
_______________________________________

From report at bugs.python.org  Wed Aug  7 16:59:58 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 07 Aug 2013 14:59:58 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
In-Reply-To: <1375885327.18.0.790620363467.issue18677@psf.upfronthosting.co.za>
Message-ID: <1375887598.35.0.27585960555.issue18677@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

IMHO, exitstack is not a very nice construct.  It's implementation is far longer than contextlib.nested.

And the chief problem still remains, which has not been addressed until this patch (as far as I know):
In Python, it is impossible to combine existing context managers into a nested one.  ExitStack may address a use case of nested context managers, but it doesn't address the basic problem.

ContextManagerExit comes with its own nice little features, too.  Now you can write:

@contextlib.contextmanager:
def if_ctxt(condition):
    if condition:
        yield

#hey look! an if statement as a with statement!
with if_ctxt(condition):
    do_work

This can easily be extended, where a context manager can both manage context, _and_ provide optional execution of its block.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18677>
_______________________________________

From report at bugs.python.org  Wed Aug  7 17:04:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Aug 2013 15:04:51 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
In-Reply-To: <1375885327.18.0.790620363467.issue18677@psf.upfronthosting.co.za>
Message-ID: <1375887891.87.0.521138189849.issue18677@psf.upfronthosting.co.za>


R. David Murray added the comment:

Raising it on python-ideas sounds like a good idea, then.

I must admit that I don't understand what you mean by "combining existing context managers into a nested one" that isn't addressed by ExitStack.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18677>
_______________________________________

From report at bugs.python.org  Wed Aug  7 17:14:25 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 07 Aug 2013 15:14:25 +0000
Subject: [issue11619] On Windows,
	don't encode filenames in the import machinery
In-Reply-To: <1300665531.85.0.426527059221.issue11619@psf.upfronthosting.co.za>
Message-ID: <1375888465.16.0.345538827607.issue11619@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11619>
_______________________________________

From report at bugs.python.org  Wed Aug  7 18:29:21 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 07 Aug 2013 16:29:21 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
In-Reply-To: <1375885327.18.0.790620363467.issue18677@psf.upfronthosting.co.za>
Message-ID: <1375892961.09.0.359583243118.issue18677@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Simply put, there is no way in the language to nest two context managers, even though we have full access to their implementation model, i.e. can call __enter__ and __exit__ manually.  This reflects badly (pun intended) on Python's reflection and introspection capabilities.

If context managers are to be first class entities in the language, then you ought to be able to write absract code using them, and
assemble complex ones out of simple ones.  Hypothetical code here:

def nest(a, b):
    # currently not possible
    return c

def run_with_context(ctxt, callable):
    # abstract executor
    with ctxt:
        return callable()

run_with_context(nested(a,b), callable)

ExitStack address one use case that contextlib.nested was supposed to solve, namely the cleanup of a dynamic sequence of context managers.  But it does this no by creating a new manager, but by providing a programming pattern to follow.  In that sensse, the multiple context manager syntax (with (a, b, c): ) is also a hack because it provides language magic to perform what you ought to be able to do dynamically...

Does this makes sense?

Anyway, by providing the ContextManagerExit exception, then sufficient flexibility is added to the context manager mechanism that at least the use case of nested() becomes possible.

Context managers are really interesting things.  I was inspired by Raymond Hettinger's talk last pycon to explore their capabilities and this is one of the things I came up with :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18677>
_______________________________________

From report at bugs.python.org  Wed Aug  7 19:47:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Aug 2013 17:47:38 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1375897658.96.0.957123107415.issue13153@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Seems as Tk stores pasted "\U000104a2" as surrogate pair "\ud801\udca2". Then it encoded in UTF-8 as "\xed\xa0\x81\xed\xb2\xa2" end passed to Python. Python converts char* to Unicode object with PyUnicode_FromString() which forbids invalid UTF-8 including encoded surrogates.

Please test proposed patch on Windows.

----------
Added file: http://bugs.python.org/file31184/tkinter_string_conv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Wed Aug  7 20:10:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Aug 2013 18:10:34 +0000
Subject: [issue18674] Store weak references in modules_by_index
In-Reply-To: <1375821531.36.0.318072139637.issue18674@psf.upfronthosting.co.za>
Message-ID: <1375899034.11.0.843897991988.issue18674@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(and of course, with module states not being PyObjects, we have the same lifetimes issues as with Py_buffers not being PyObjects....)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18674>
_______________________________________

From report at bugs.python.org  Wed Aug  7 21:47:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Aug 2013 19:47:00 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1375904820.74.0.886959806383.issue13153@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file31184/tkinter_string_conv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Wed Aug  7 21:48:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Aug 2013 19:48:49 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1375904929.77.0.173582140422.issue13153@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file31185/tkinter_string_conv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Wed Aug  7 23:22:45 2013
From: report at bugs.python.org (Derek Wilson)
Date: Wed, 07 Aug 2013 21:22:45 +0000
Subject: [issue18679] include a codec to handle escaping only control
	characters but not any others
Message-ID: <1375910565.85.0.834240880509.issue18679@psf.upfronthosting.co.za>


New submission from Derek Wilson:

Escaping strings for serialization or display is a common problem. Currently, in python3, in order to escape a sting, you need to do this:

'my\tstring'.encode('unicode_escape').decode('ascii')

This would give you a string that was represented like this:

'my\\tstring'

But this does not present a suitable representation when the string contains unicode characters. Consider this example:

s = '?\t?'

There is no method to write this string this with only the control character escaped.

Even python itself recognizes this as a problem and implemented a "solution" for it.

>>> s = '?\t?'
>>> print(s)
?	?
>>> print(repr(s))
'?\t?'
>>> print(s.encode('unicode_escape').decode('ascii'))
\u0391\t\u03a9

What I want is public exposure of the functionality to represent control characters with their common \ escape sequences (or \x## for control characters where necessary - for instance unit and record separators).

I have numerous use cases for this and python's own str.__repr__ implementation shows that the functionality is valuable. I would bet that the majority of cases where people use unicode_escape something like a control_escape is more along the lines of what is desired.

And while we're at it, it would be great if this were a unicode->unicode codec like the rot_13 codec. My desired soluiton would look like this:

>>> import codecs
>>> s = '?\t?'
>>> e = codecs.encode(s, 'control_escape'))
>>> print(e)
?\t?
>>> print(codecs.decode(e, 'control_escape'))
?	?

If this is something that could be included in python 3.4, that would be awesome. I am willing to work on this if so.

----------
components: Library (Lib)
messages: 194625
nosy: underrun
priority: normal
severity: normal
status: open
title: include a codec to handle escaping only control characters but not any others
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18679>
_______________________________________

From report at bugs.python.org  Wed Aug  7 23:47:28 2013
From: report at bugs.python.org (Zhongyue Luo)
Date: Wed, 07 Aug 2013 21:47:28 +0000
Subject: [issue18676] Queue: document that zero is accepted as timeout value
In-Reply-To: <1375883528.55.0.275850242187.issue18676@psf.upfronthosting.co.za>
Message-ID: <1375912048.13.0.872004246723.issue18676@psf.upfronthosting.co.za>


Zhongyue Luo added the comment:

David,

How about like below?

  elif timeout < sys.float_info.epsilon:
     raise ValueError("'timeout' must be a positive number")

The docstring has been there for quite a while and IMHO it just doesn't make sense passing 0.0 as a timeout value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18676>
_______________________________________

From report at bugs.python.org  Wed Aug  7 23:49:16 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 07 Aug 2013 21:49:16 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1375912156.21.0.457962094734.issue8713@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


Added file: http://bugs.python.org/file31186/b3620777f54c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Wed Aug  7 23:57:37 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 07 Aug 2013 21:57:37 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1375912657.07.0.20879988651.issue8713@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

I have done quite a bit of refactoring and added some extra tests.

When I try using the forkserver start method on the OSX Tiger buildbot (the only OSX one available) I get errors.  I have disabled the tests for OSX, but it seemed to be working before.  Maybe that was with a different buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Thu Aug  8 00:06:31 2013
From: report at bugs.python.org (Corey Farwell)
Date: Wed, 07 Aug 2013 22:06:31 +0000
Subject: [issue18680] JSONDecoder should document that it raises a ValueError
	for malformed data
Message-ID: <1375913191.45.0.0174536581066.issue18680@psf.upfronthosting.co.za>


New submission from Corey Farwell:

Before someone comes in and tries to correct me, I know Python documentation is different than Javadocs. It is common to test if the JSON is malformed using a try...catch. What if I want to catch something more specific than Exception? The only way a user would know what to catch is to `python -c "import json; json.loads('FAIL')"`. Many other Python modules document which exception is raised on invalid input/parameters.

----------
assignee: docs at python
components: Documentation
messages: 194628
nosy: corey, docs at python
priority: normal
severity: normal
status: open
title: JSONDecoder should document that it raises a ValueError for malformed data
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18680>
_______________________________________

From report at bugs.python.org  Thu Aug  8 00:13:09 2013
From: report at bugs.python.org (Corey Farwell)
Date: Wed, 07 Aug 2013 22:13:09 +0000
Subject: [issue18680] JSONDecoder should document that it raises a ValueError
	for malformed data
In-Reply-To: <1375913191.45.0.0174536581066.issue18680@psf.upfronthosting.co.za>
Message-ID: <1375913589.04.0.736260704416.issue18680@psf.upfronthosting.co.za>


Corey Farwell added the comment:

Ideally, this would also be decoumented in json.loads/json.load

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18680>
_______________________________________

From report at bugs.python.org  Thu Aug  8 00:13:41 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 07 Aug 2013 22:13:41 +0000
Subject: [issue18676] Queue: document that zero is accepted as timeout value
In-Reply-To: <1375883528.55.0.275850242187.issue18676@psf.upfronthosting.co.za>
Message-ID: <1375913621.79.0.342753932092.issue18676@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> IMHO it just doesn't make sense passing 0.0 as a timeout value.

I have written lots of code that looks like

    timeout = max(deadline - time.time(), 0)
    some_function(..., timeout=timeout)

This makes perfect sense.  Working code should not be broken -- it is the docsting that should be changed.

I can't think of *any* function taking a timeout which rejects a zero timeout.  See select(), poll(), Condition.wait(), Lock.acquire(), Thread.join().  In each case a zero timeout causes a non-blocking call.

Also, note that the implementation does not contradict the docstring or documentation: they say nothing about what happens it timeout is zero (or negative).

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18676>
_______________________________________

From report at bugs.python.org  Thu Aug  8 00:15:33 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Aug 2013 22:15:33 +0000
Subject: [issue18676] Queue: document that zero is accepted as timeout value
In-Reply-To: <1375883528.55.0.275850242187.issue18676@psf.upfronthosting.co.za>
Message-ID: <1375913733.6.0.703561629116.issue18676@psf.upfronthosting.co.za>


R. David Murray added the comment:

Exactly.  0 means "Don't wait, just raise an error immediately if the queue is empty/full".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18676>
_______________________________________

From report at bugs.python.org  Thu Aug  8 00:18:32 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Aug 2013 22:18:32 +0000
Subject: [issue18679] include a codec to handle escaping only control
	characters but not any others
In-Reply-To: <1375910565.85.0.834240880509.issue18679@psf.upfronthosting.co.za>
Message-ID: <1375913912.08.0.0922584482564.issue18679@psf.upfronthosting.co.za>


R. David Murray added the comment:

In what way does repr(x)[1:-1] not serve your use case?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18679>
_______________________________________

From report at bugs.python.org  Thu Aug  8 01:04:13 2013
From: report at bugs.python.org (M. Dietrich)
Date: Wed, 07 Aug 2013 23:04:13 +0000
Subject: [issue18671] enhance formatting in logging package
In-Reply-To: <1375804669.84.0.0477385788117.issue18671@psf.upfronthosting.co.za>
Message-ID: <1375916653.17.0.528311517427.issue18671@psf.upfronthosting.co.za>


M. Dietrich added the comment:

thanks, it will be really helpful for me to have this fixed.

as i consider this a "bug" it would be possible to "fix" this for 2.7 and yes you are right, i talked about 2.7 as we are still using this version in production.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18671>
_______________________________________

From report at bugs.python.org  Thu Aug  8 01:18:51 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 07 Aug 2013 23:18:51 +0000
Subject: [issue18671] enhance formatting in logging package
In-Reply-To: <1375804669.84.0.0477385788117.issue18671@psf.upfronthosting.co.za>
Message-ID: <1375917531.26.0.586546124677.issue18671@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Sorry, not for 2.7 - it's not a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18671>
_______________________________________

From report at bugs.python.org  Thu Aug  8 01:36:54 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Aug 2013 23:36:54 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
In-Reply-To: <1375892961.09.0.359583243118.issue18677@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eBjrgUJPgvkp9NuuxW3oFdJxZKxDxZrMrZndy3437W6A@mail.gmail.com>


Nick Coghlan added the comment:

I pitched the idea of making it possible to skip the with statement body
quite some time ago, and Guido convinced me it was a bad idea for much the
same reason he chose PEP 343 over his original PEP 340 design: allowing
suppression of exceptions from __enter__ hides local control flow by
blurring the boundaries between with and if statements.

Regarding nested, we killed that because it was a bug magnet for context
managers that acquire the resource in __init__ (like file objects), not
because it didn't work.
It's trivial to recreate that API on top of ExitStack if you like it,
though. The only thing that doesn't work (relative to actual nested with
statements) is suppressing exceptions raised inside __enter__ methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18677>
_______________________________________

From report at bugs.python.org  Thu Aug  8 02:09:59 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 08 Aug 2013 00:09:59 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
In-Reply-To: <1375885327.18.0.790620363467.issue18677@psf.upfronthosting.co.za>
Message-ID: <1375920599.21.0.7751913241.issue18677@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Hi there.
"allowing
suppression of exceptions from __enter__ hides local control flow by
blurring the boundaries between with and if statements.
"
I'm not sure what this means.  To me, it is a serious language design flaw that you can write a context manager, and it has a well known interface that you can invoke manually, but that you cannot take two existing context managers and assemble them into a nested one, correctly, however much you wiggle.
In my mind, allowing context managers to skip the managed body breaks new ground.  Both, by allowing this "combination" to be possible.  And also by opening up new and exciting applications for context managers.  If you saw Raymond's talk last Pycon, you should feel inspired to do new and exciting things with them.

the bug-magnet you speak of I already addressed in my patch with nested-delayed, more as a measure of completeness (address both the problems that old "nested" had.  The more serious bug (IMHO) is the suppression of __enter__ exceptions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18677>
_______________________________________

From report at bugs.python.org  Thu Aug  8 03:16:49 2013
From: report at bugs.python.org (Madison May)
Date: Thu, 08 Aug 2013 01:16:49 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1373400107.5.0.285657244525.issue18416@psf.upfronthosting.co.za>
Message-ID: <1375924609.56.0.898504712178.issue18416@psf.upfronthosting.co.za>


Madison May added the comment:

Nick, it was definitely a good thing to mention.  I had to learn the "edit, build, test" cycle the hard way my first time.  It took me a good 15-20 minutes to figure out why none of my edits seemed to change anything :)


Anyhow, here's how I see the issue. It seems like we have three main options:

In option one, we only modify PathFinder._path_importer_cache().

         if path == '':
-            path = '.'
+            path = _os.getcwd()

This associates the cwd with FileFinder(cwd) in sys.path_importer_cache

In option two, we only modify FileFinder.__init__().

-        self.path = path or '.'
+        if not path or path == '.':
+            path = _os.getcwd()
+        self.path = path

This associates '.' with FileFinder(cwd) in sys.path_importer_cache.

In option three, we modify both PathFinder and FileFinder.  In PathFinder._path_importer_cache() we remove the line that reassigns path to '.' if path is the empty string.

-        if path == '':
-            path = '.'

In FileFinder.__init__(), we set path to _os.getcwd() if path is false.

-        self.path = path or '.'
+        self.path = path or _os.getcwd() 

This associates the empty string with FileFinder(cwd) in sys.path_importer_cache.

What are your thoughts? Which solution would you all support?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18416>
_______________________________________

From report at bugs.python.org  Thu Aug  8 03:22:25 2013
From: report at bugs.python.org (Zhongyue Luo)
Date: Thu, 08 Aug 2013 01:22:25 +0000
Subject: [issue18676] Queue: document that zero is accepted as timeout value
In-Reply-To: <1375883528.55.0.275850242187.issue18676@psf.upfronthosting.co.za>
Message-ID: <1375924945.34.0.626694555382.issue18676@psf.upfronthosting.co.za>


Changes by Zhongyue Luo <zhongyue.luo at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31187/queue_timeout_docstring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18676>
_______________________________________

From report at bugs.python.org  Thu Aug  8 03:45:01 2013
From: report at bugs.python.org (Zhongyue Luo)
Date: Thu, 08 Aug 2013 01:45:01 +0000
Subject: [issue18676] Queue: document that zero is accepted as timeout value
In-Reply-To: <1375883528.55.0.275850242187.issue18676@psf.upfronthosting.co.za>
Message-ID: <1375926301.16.0.0875765880637.issue18676@psf.upfronthosting.co.za>


Changes by Zhongyue Luo <zhongyue.luo at gmail.com>:


Added file: http://bugs.python.org/file31188/queue_timeout_docstring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18676>
_______________________________________

From report at bugs.python.org  Thu Aug  8 03:48:21 2013
From: report at bugs.python.org (Zhongyue Luo)
Date: Thu, 08 Aug 2013 01:48:21 +0000
Subject: [issue18676] Queue: document that zero is accepted as timeout value
In-Reply-To: <1375883528.55.0.275850242187.issue18676@psf.upfronthosting.co.za>
Message-ID: <1375926501.16.0.776444156489.issue18676@psf.upfronthosting.co.za>


Changes by Zhongyue Luo <zhongyue.luo at gmail.com>:


Added file: http://bugs.python.org/file31189/queue_timeout_docstring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18676>
_______________________________________

From report at bugs.python.org  Thu Aug  8 04:14:36 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 08 Aug 2013 02:14:36 +0000
Subject: [issue18526] Add resource management/guarding to unittest
In-Reply-To: <1374470490.47.0.980625465837.issue18526@psf.upfronthosting.co.za>
Message-ID: <1375928076.45.0.919599109598.issue18526@psf.upfronthosting.co.za>


Zachary Ware added the comment:

(Apologies for the delay in replies, my available time evaporated without notice...)

Antoine Pitrou wrote:
> Does registerResource() mutate some kind of global per-process state? This
> doesn't sound like a good idea.

It's not the greatest of ideas, no; but I hadn't come up with a better one
yet :).  Robert's review has given me a couple ideas to try to avoid this,
though.

> (and even less so the "default resources", IMO: these are stdlib test
> suite-specific)

That is true, though I attempted to pick out some of the ones used by our test
suite that are most likely to be applicable elsewhere.  I had a couple misses,
though, and I'm not against removing the defaults entirely.

---

Michael Foord wrote:
> My question is, is this generally useful enough for test suites beyond the
> Python standard library. Essentially it provides a command line interface to
> specialized test skipping.

To be honest, I'm not sure.  Theoretically, I can think of several situations
where it would be useful, but I have no concrete examples aside from the Pytohn
test suite.

> I *still* feel that a generalized mechanism for adding command line options to
> the standard test runner would allow for this and a myriad of other slightly
> specialized use cases. It's hard to see how to do that cleanly without full
> blown extension machinery (which I'm in favour of and have prototyped but it
> is a *much* bigger change set)

Is your prototype available anywhere for me to get a better idea what you mean?
That could indeed be a much better approach if it is what I think it is.

---

Robert Collins wrote:
> I'll do a full review shortly, but at the conceptual level, I don't see any
> benefit in making a new SkipTest base class, other than instantly breaking
> other runners when an unknown exception is raised. SkipTest is part of the
> API. Making a new exception part of the API requires a strong reason - not
> just 'we want to show it differently' but 'we want the runner to behave
> differently.

Actually, the real reason I created the new _BaseSkip exception was to avoid an
import loop between resources.py and case.py.  I think I was trying to keep
SkipTest defined in case.py, but in retrospect it is much saner to just move
it to util.py and import from there in both other modules, and directly subclass
SkipTest for the new Resource exceptions.  I'll respond to your review on 
Rietveld and with a new patch, as time allows (hopefully before the next alpha).

---

Thanks to all three of you for your comments :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18526>
_______________________________________

From report at bugs.python.org  Thu Aug  8 04:46:24 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 08 Aug 2013 02:46:24 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1375929984.23.0.318212695424.issue16248@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Antoine Pitrou wrote:
> I've committed a fix to 2.7 (I hope it's really a fix, since I don't know how to test it).
> I'll let Benjamin and Barry decide whether to backport to 2.6 and 3.2.
> As for 3.1, it's pretty much dead.

That fix does work, but it should probably get a NEWS entry since it fixes a regression from 2.7.3 to 2.7.5.

Also, I think the same fix should be backported to all three of 2.6, 3.1, and 3.2.  The same regression as in 2.7.5 exists in 3.2.5, and would be introduced by the next (last?) releases of 2.6 and 3.1.

Sorry to have broken every possible version of Python :S

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Thu Aug  8 05:03:33 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 08 Aug 2013 03:03:33 +0000
Subject: [issue18273] Simplify calling and discovery of json test package
In-Reply-To: <1371760220.13.0.623339240586.issue18273@psf.upfronthosting.co.za>
Message-ID: <1375931013.55.0.729393018561.issue18273@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's a new patch; test_json.__main__ now uses an absolute import rather than trying to use a relative one.  Also, Makefile.pre.in is fixed (thank you, Ned!).

----------
Added file: http://bugs.python.org/file31190/test_json_discovery.v2-3.3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18273>
_______________________________________

From report at bugs.python.org  Thu Aug  8 05:22:22 2013
From: report at bugs.python.org (Weizhao Li)
Date: Thu, 08 Aug 2013 03:22:22 +0000
Subject: [issue18681] typo in imp.reload
Message-ID: <1375932142.75.0.662721125733.issue18681@psf.upfronthosting.co.za>


New submission from Weizhao Li:

just a typo:

270c270
<             raise ImportError(msg.format(parentname), name=parent_name)
---
>             raise ImportError(msg.format(parent_name), name=parent_name)

----------
components: Library (Lib)
messages: 194641
nosy: felloak
priority: normal
severity: normal
status: open
title: typo in imp.reload
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18681>
_______________________________________

From report at bugs.python.org  Thu Aug  8 05:25:30 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 08 Aug 2013 03:25:30 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
In-Reply-To: <1375885327.18.0.790620363467.issue18677@psf.upfronthosting.co.za>
Message-ID: <1375932330.73.0.407804741125.issue18677@psf.upfronthosting.co.za>


Eric Snow added the comment:

Nick was probably talking about what is further elaborated in PEP 343.  I'd recommend taking a particular look at the "Motivation and Summary" section regarding flow control macros.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18677>
_______________________________________

From report at bugs.python.org  Thu Aug  8 05:29:39 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 08 Aug 2013 03:29:39 +0000
Subject: [issue16968] Fix test discovery for test_concurrent_futures.py
In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za>
Message-ID: <1375932578.99.0.990760989027.issue16968@psf.upfronthosting.co.za>


Zachary Ware added the comment:

That's a much better solution, thank you, Serhiy.  Here's a new patch.  test.support is no longer changed at all, but regrtest.py still is; the extra reference to the tests still causes issues, so it is removed.

----------
Added file: http://bugs.python.org/file31191/test_concurrent_futures_discovery.v5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16968>
_______________________________________

From report at bugs.python.org  Thu Aug  8 07:12:14 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 08 Aug 2013 05:12:14 +0000
Subject: [issue18583] Idle: enhance FormatParagraph
In-Reply-To: <1375065577.4.0.851490009653.issue18583@psf.upfronthosting.co.za>
Message-ID: <1375938734.82.0.202718835846.issue18583@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
dependencies: +IDLE Unit test for FormatParagrah.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18583>
_______________________________________

From report at bugs.python.org  Thu Aug  8 07:18:35 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 08 Aug 2013 05:18:35 +0000
Subject: [issue18226] IDLE Unit test for FormatParagrah.py
In-Reply-To: <1371335636.99.0.534048602964.issue18226@psf.upfronthosting.co.za>
Message-ID: <1375939115.66.0.886480425325.issue18226@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Added tests to get 100% coverage (not counting in __name__ block).
More test cleanups. Some of the extra newlines come from getting to 'end' instead of 'insert'. Others are avoided by adding newline to end of test strings, which is more realistic anyway. I commented out tests that I think test bad behavior that should be changed.

----------
Added file: http://bugs.python.org/file31192/18226FormatPara8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18226>
_______________________________________

From report at bugs.python.org  Thu Aug  8 08:44:55 2013
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 08 Aug 2013 06:44:55 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1375944295.35.0.514371908239.issue15301@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Benjamin, do you want my elaborate fix in for 2.7?  It means adding two new converters, one for pid and one for gid, and switching everything that takes pid/gid arguments to use those.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Thu Aug  8 09:23:02 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Aug 2013 07:23:02 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <3c9gz96bMFz7M49@mail.python.org>


Roundup Robot added the comment:

New changeset f871f8662509 by Larry Hastings in branch 'default':
Issue #15301: Parsing fd, uid, and gid parameters for builtins
http://hg.python.org/cpython/rev/f871f8662509

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Thu Aug  8 09:23:59 2013
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 08 Aug 2013 07:23:59 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1375946639.49.0.721500345543.issue15301@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Now fixed in trunk.  I am waiting to hear from Georg and the only-recently-pinged Benjamin to see if they want these fixes in 3.3 or 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Thu Aug  8 09:27:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Aug 2013 07:27:16 +0000
Subject: [issue18290] json encoder does not support JSONP/JavaScript safe
	escaping
In-Reply-To: <1372049179.79.0.237326954931.issue18290@psf.upfronthosting.co.za>
Message-ID: <1375946836.55.0.638466333527.issue18290@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Embedding JSON inside <script> tag doesn't differ from embedding any string in some format (i.e. JSON in Python string, Python sources in HTML, or XML in a shell script). We just escape characters which have special meaning.

I propose close this issue because embedding JSON (as any other generated code) in inline JavaScript can be done very easily with a sequence of string replaces. This has no relations to the json module.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18290>
_______________________________________

From report at bugs.python.org  Thu Aug  8 09:32:29 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 08 Aug 2013 07:32:29 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1375947149.76.0.810801110732.issue15301@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I think we should leave 2.7 at rest for the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Thu Aug  8 09:35:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Aug 2013 07:35:03 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1375947303.75.0.398588605744.issue15301@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The original issue was fixed in issue4591. Larry's patch only adds support of PyNumber_Index() and refactors already existing uid/gid converters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Thu Aug  8 09:58:42 2013
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Aug 2013 07:58:42 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1375948722.86.0.204906917562.issue8713@psf.upfronthosting.co.za>


Ned Deily added the comment:

Richard, can you say what failed on the OS X 10.4 (Tiger) buildbot?  FWIW, I tested b3620777f54c.diff (and commented out the darwin skip of test_multiprocessing_forkserver) on OS X 10.4, 10.5, and 10.8.  There were no failures on any of them. The only vaguely suspicious message when running with -v was:

./python -m test -v test_multiprocessing_forkserver
[...]
test_semaphore_tracker (test.test_multiprocessing_forkserver.TestSemaphoreTracker) ... [semaphore_tracker] '/mp18203-0': [Errno 22] Invalid argument
[semaphore_tracker] '/mp18203-1': successfully unlinked
ok
[...]
----------------------------------------------------------------------
Ran 233 tests in 97.162s

OK (skipped=5)  # on 32-bit 'largest assignable fd number is too small'
OK (skipped=4)  # on 64-bit

1 test OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Thu Aug  8 10:29:26 2013
From: report at bugs.python.org (Michal Vyskocil)
Date: Thu, 08 Aug 2013 08:29:26 +0000
Subject: [issue18682] [PATCH] remove bogus codepath from pprint._safe_repr
Message-ID: <1375950566.41.0.226660086473.issue18682@psf.upfronthosting.co.za>


New submission from Michal Vyskocil:

pprint._safe_repr for type str uses much slower codepath by default, which does not makes a sense in Python3 context. Instead of simply using repr, it check the existence of 'locale' in sys.modules and if found, it goes one-by-one-char call str.isalpha() on each and apply the quoting for non-alpha chars. This is extremely slow, but as locale is usually in sys.modules, it's used by default.

The point of such code was because in python2, str.isalpha() depends on locale, so for locale-aware Python builds, there was a different path needed. But this does not apply for Python3, where all strings are unicode, so .isaplha() is not locale sensitive anymore.

----------
components: Library (Lib)
files: pprint-remove-bogus-code.patch
keywords: patch
messages: 194652
nosy: mvyskocil
priority: normal
severity: normal
status: open
title: [PATCH] remove bogus codepath from pprint._safe_repr
type: performance
Added file: http://bugs.python.org/file31193/pprint-remove-bogus-code.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18682>
_______________________________________

From report at bugs.python.org  Thu Aug  8 10:31:58 2013
From: report at bugs.python.org (Michal Vyskocil)
Date: Thu, 08 Aug 2013 08:31:58 +0000
Subject: [issue18682] [PATCH] remove bogus codepath from pprint._safe_repr
In-Reply-To: <1375950566.41.0.226660086473.issue18682@psf.upfronthosting.co.za>
Message-ID: <1375950718.55.0.107329876266.issue18682@psf.upfronthosting.co.za>


Michal Vyskocil added the comment:

This is simple code checks if .isalnum is or is not locale sensitive and a small measurement of how much is the repr faster, compared to old codepath.

BTW: python3 test_pprint.py on patched version have succeeded

OK (expected failures=1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18682>
_______________________________________

From report at bugs.python.org  Thu Aug  8 10:32:53 2013
From: report at bugs.python.org (Michal Vyskocil)
Date: Thu, 08 Aug 2013 08:32:53 +0000
Subject: [issue18682] [PATCH] remove bogus codepath from pprint._safe_repr
In-Reply-To: <1375950566.41.0.226660086473.issue18682@psf.upfronthosting.co.za>
Message-ID: <1375950773.44.0.0174780459151.issue18682@psf.upfronthosting.co.za>


Changes by Michal Vyskocil <mvyskocil at suse.cz>:


Added file: http://bugs.python.org/file31194/check.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18682>
_______________________________________

From report at bugs.python.org  Thu Aug  8 10:39:59 2013
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 08 Aug 2013 08:39:59 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1375951199.54.0.260094142017.issue15301@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Looks like an unnecessary change for the maintenance releases then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Thu Aug  8 11:34:00 2013
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 08 Aug 2013 09:34:00 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1375954440.77.0.38730982167.issue15301@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Okay then, closing.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Thu Aug  8 11:44:19 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 08 Aug 2013 09:44:19 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1375948722.86.0.204906917562.issue8713@psf.upfronthosting.co.za>
Message-ID: <5203686C.30708@gmail.com>


Richard Oudkerk added the comment:

> Richard, can you say what failed on the OS X 10.4 (Tiger) buildbot?

There seems to be a problem which depends on the order in which you run 
the test, and it happens on Linux also.  For example if I do

   ./python -m test -v \
       test_multiprocessing_fork \
       test_multiprocessing_forkserver

Then I get lots of failures when forkserver runs.  I have tracked down 
the changeset which caused the problem, but I have not had time to look 
in to it.

 > The only vaguely suspicious message when running with -v was:
 > [...]
 > [semaphore_tracker] '/mp18203-0': [Errno 22] Invalid argument
 > [semaphore_tracker] '/mp18203-1': successfully unlinked
 > [...]

That is expected and it shows the semaphore tracker is working as 
expected.  Maybe I should print a note to stderr to expect this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Thu Aug  8 12:24:37 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 08 Aug 2013 10:24:37 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
In-Reply-To: <1375885327.18.0.790620363467.issue18677@psf.upfronthosting.co.za>
Message-ID: <1375957477.84.0.220814154739.issue18677@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

I've modified the patch.  The problem that nested_delayed was trying to solve are "hybrid" context managers, ones that allocate resources during __init__ and release them at exit.  A proper context manager should allocate resources during __enter__, and thus a number of them can be created upfront with impunity.

Added contextlib.proper to turn a hybrid context manager into a proper one by instantiating the hybrid in a delayed fashion.
added contextlib.opened() as a special case that does open() properly.

With this change, and the ability to nest error handling of exceptions stemming from __enter__(), nested now works as intended.

----------
Added file: http://bugs.python.org/file31195/contextmanagerexit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18677>
_______________________________________

From report at bugs.python.org  Thu Aug  8 12:39:42 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 08 Aug 2013 10:39:42 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
In-Reply-To: <1375885327.18.0.790620363467.issue18677@psf.upfronthosting.co.za>
Message-ID: <1375958382.54.0.851050075272.issue18677@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Thanks, Eric.
I read that bit and I can't say that I disagree.
And I'm not necessarily advocating that "skipping the body" become a standard feature of context managers.  But it is a necessary functionality if you want to be able to dynamically nest one or more context managers, something I think Python should be able to do, for completeness, if not only for aesthetic beauty.

Having said that, optionally skipping the body is a far cry from the more esoteric constructs achievable with pep 340.

And python _already_ silently skips the body of managed code, if you nest two managers:

@contextmanager errordude:
    1 // 0
    yield
@contextmanager handler:
    try:
        yield
    except ZeroDivisionError:
        pass

with handler, errordude:
    do_stuff()

These context managers will skip the execution of f.  It will be Python's internal decision to do so, of course.  But the "with" statement already has the potential to have the body silently skipped.

What I'm adding here, the ContextManagerExit, is the ability for the context manager itself to make the decision, so that the two context managers above can be coalesced into one:

    with nested(handler, errordude):
        do_stuff()

The fact that do_stuff can be silently skipped in the first case, where we explicitly have two nested calls, invalidates IMHO the argument that context managers should not affect control flow.  why shouldn't it also be skippable in the case of a single context manager?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18677>
_______________________________________

From report at bugs.python.org  Thu Aug  8 12:43:07 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 08 Aug 2013 10:43:07 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
In-Reply-To: <1375885327.18.0.790620363467.issue18677@psf.upfronthosting.co.za>
Message-ID: <1375958587.67.0.887335458452.issue18677@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Using my latest patch, the ExitStack inline example can be rewritten:

with ExitStack() as stack:
            files = [stack.enter_context(open(fname)) for fname in filenames]
            # All opened files will automatically be closed at the end of
            # the with statement, even if attempts to open files later
            # in the list raise an exception

becomes:
with nested(opened(fname) for fname in filenames) as files:
    do_stuff_with_files(files)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18677>
_______________________________________

From report at bugs.python.org  Thu Aug  8 13:41:21 2013
From: report at bugs.python.org (Marc Schlaich)
Date: Thu, 08 Aug 2013 11:41:21 +0000
Subject: [issue18683] Core dumps on CentOS
Message-ID: <1375962081.45.0.433865344111.issue18683@psf.upfronthosting.co.za>


New submission from Marc Schlaich:

I'm running unittests on a CentOS 6.4 Virtual Box slave via Jenkins on a 
Windows host. Randomly I get core dumps for no obvious reason. I don't
use any C extension in my code and don't use ctypes. The (proprietary)
software is plain Python with a multi-threaded architecture.

There might be a threading race condition in the code but according
to http://stackoverflow.com/a/13654489/851737 this shouldn't result
in a segfault. So it might be a bug in Python.

I appended one log (I have various others if you wish to see them) with 
faulthandler enabled by https://pypi.python.org/pypi/nose-faulthandler.

----------
files: crash.log
messages: 194660
nosy: schlamar
priority: normal
severity: normal
status: open
title: Core dumps on CentOS
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file31196/crash.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18683>
_______________________________________

From report at bugs.python.org  Thu Aug  8 13:56:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Aug 2013 11:56:24 +0000
Subject: [issue18684] Pointers point out of array bound in _sre.c
Message-ID: <1375962984.07.0.918202360038.issue18684@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In _sre.c pointers can point out of boundaries of array. This is an undefined behavior and is one of causes of a bug in issue17998 (end-ptr can be negative). The proposed patch change code to check if pointers will point out of boundaries before their changing.

----------
components: Regular Expressions
files: sre_ptr_out_of_bounds.patch
keywords: patch
messages: 194661
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Pointers point out of array bound in _sre.c
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31197/sre_ptr_out_of_bounds.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18684>
_______________________________________

From report at bugs.python.org  Thu Aug  8 14:01:07 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Aug 2013 12:01:07 +0000
Subject: [issue18683] Core dumps on CentOS
In-Reply-To: <1375962081.45.0.433865344111.issue18683@psf.upfronthosting.co.za>
Message-ID: <1375963267.48.0.500011586029.issue18683@psf.upfronthosting.co.za>


R. David Murray added the comment:

Can you reproduce this using 2.7?  2.6 only gets security fixes.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18683>
_______________________________________

From report at bugs.python.org  Thu Aug  8 14:24:46 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 08 Aug 2013 12:24:46 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1373400107.5.0.285657244525.issue18416@psf.upfronthosting.co.za>
Message-ID: <1375964686.56.0.0690359326605.issue18416@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So this is bringing up a sticky situation that I ran across when initially implementing all of this: what should sys.path_importer_cache use as a key? '' would be what happens with Madison's option 3, and with option 1 it would be os.getcwd(). Now if you iterate through sys.path you won't find what '' connects to. Then again, it won't be accurate if you change the directory either.

So the question becomes should sys.path_importer_cache reflect exactly what is in sys.path or what should be cached for a finder based on what import should do (i.e. the full path and change based on the cwd)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18416>
_______________________________________

From report at bugs.python.org  Thu Aug  8 14:31:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Aug 2013 12:31:47 +0000
Subject: [issue18273] Simplify calling and discovery of json test package
In-Reply-To: <1371760220.13.0.623339240586.issue18273@psf.upfronthosting.co.za>
Message-ID: <3c9pqQ4qpnz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 95cf8640b271 by Ezio Melotti in branch '3.3':
#18273: move the tests in Lib/test/json_tests to Lib/test/test_json and make them discoverable by unittest.  Patch by Zachary Ware.
http://hg.python.org/cpython/rev/95cf8640b271

New changeset f7ed301e7199 by Ezio Melotti in branch 'default':
#18273: merge with 3.3.
http://hg.python.org/cpython/rev/f7ed301e7199

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18273>
_______________________________________

From report at bugs.python.org  Thu Aug  8 14:35:23 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 12:35:23 +0000
Subject: [issue18273] Simplify calling and discovery of json test package
In-Reply-To: <1371760220.13.0.623339240586.issue18273@psf.upfronthosting.co.za>
Message-ID: <1375965323.78.0.924453751496.issue18273@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!
(Thanks Ned too!)

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18273>
_______________________________________

From report at bugs.python.org  Thu Aug  8 14:46:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Aug 2013 12:46:27 +0000
Subject: [issue18267] xmlrpc.client documentation multicall example
	missleading for division behaviour of python3
In-Reply-To: <1371675805.26.0.18697522409.issue18267@psf.upfronthosting.co.za>
Message-ID: <3c9q8L2yJyz7Ljh@mail.python.org>


Roundup Robot added the comment:

New changeset 38d341ef28b3 by Ezio Melotti in branch '3.3':
#18267: make whitespace consistent and fix an operator.
http://hg.python.org/cpython/rev/38d341ef28b3

New changeset 9875410ed390 by Ezio Melotti in branch 'default':
#18267: merge with 3.3.
http://hg.python.org/cpython/rev/9875410ed390

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18267>
_______________________________________

From report at bugs.python.org  Thu Aug  8 14:47:03 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 12:47:03 +0000
Subject: [issue18267] xmlrpc.client documentation multicall example
	missleading for division behaviour of python3
In-Reply-To: <1371675805.26.0.18697522409.issue18267@psf.upfronthosting.co.za>
Message-ID: <1375966023.18.0.890951179179.issue18267@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
status: open -> closed
type:  -> enhancement
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18267>
_______________________________________

From report at bugs.python.org  Thu Aug  8 14:56:24 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 12:56:24 +0000
Subject: [issue18301] In itertools.chain.from_iterable() there is no cls
	argument
In-Reply-To: <1372186723.21.0.67533324157.issue18301@psf.upfronthosting.co.za>
Message-ID: <1375966584.76.0.441778186849.issue18301@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I would just remove the decorator.

+1

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18301>
_______________________________________

From report at bugs.python.org  Thu Aug  8 15:10:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Aug 2013 13:10:19 +0000
Subject: [issue18685] Restore re performance to pre-PEP393 level
Message-ID: <1375967417.95.0.0303828296889.issue18685@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Before PEP 393 the regex functions scanned an array of char or Py_UNICODE and character testing was cheap. After PEP 393 they checks a kind of an unicode string for every tested character and processing of unicode strings becomes slower. _sre.c already generates two sets of functions from one source -- for byte and unicode strings. The proposed patch uses same technique to generate three sets of functions -- for byte/UCS1, UCS2 and UCS4 strings. This simplifies the code (now it more similar to pre-PEP393 version) and makes characters testing faster.

Benchmark example:

Python 3.2:
$ python3.2 -m timeit -s "import re; f = re.compile(b'abc').search; x = b'x'*100000"  "f(x)"
1000 loops, best of 3: 613 usec per loop
$ python3.2 -m timeit -s "import re; f = re.compile('abc').search; x = 'x'*100000"  "f(x)"
1000 loops, best of 3: 232 usec per loop
$ python3.2 -m timeit -s "import re; f = re.compile('abc').search; x = '\u20ac'*100000"  "f(x)"
1000 loops, best of 3: 217 usec per loop

Python 3.4.0a1+ unpatched:
$ ./python -m timeit -s "import re; f = re.compile(b'abc').search; x = b'x'*100000"  "f(x)"
1000 loops, best of 3: 485 usec per loop
$ ./python -m timeit -s "import re; f = re.compile('abc').search; x = 'x'*100000"  "f(x)"
1000 loops, best of 3: 790 usec per loop
$ ./python -m timeit -s "import re; f = re.compile('abc').search; x = '\u20ac'*100000"  "f(x)"
1000 loops, best of 3: 1.09 msec per loop

Python 3.4.0a1+ patched:
$ ./python -m timeit -s "import re; f = re.compile(b'abc').search; x = b'x'*100000"  "f(x)"
1000 loops, best of 3: 250 usec per loop
$ ./python -m timeit -s "import re; f = re.compile('abc').search; x = 'x'*100000"  "f(x)"
1000 loops, best of 3: 250 usec per loop
$ ./python -m timeit -s "import re; f = re.compile('abc').search; x = '\u20ac'*100000"  "f(x)"
1000 loops, best of 3: 256 usec per loop

I also propose for simplicity extract a template part of _sre.c to separated file (i.e. srelib.h) and get rid of recursion.

----------
assignee: serhiy.storchaka
components: Regular Expressions, Unicode
files: sre_optimize.patch
keywords: patch
messages: 194669
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Restore re performance to pre-PEP393 level
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file31198/sre_optimize.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18685>
_______________________________________

From report at bugs.python.org  Thu Aug  8 15:10:24 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 13:10:24 +0000
Subject: [issue18313] In itertools recipes repeatfunc() defines a non-keyword
	argument as keyword
In-Reply-To: <1372309261.95.0.7034101172.issue18313@psf.upfronthosting.co.za>
Message-ID: <1375967424.09.0.324102241428.issue18313@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> it should be: "def repeatfunc(func, times, *args):"
> and None for times described in the docstring

This would require you to provide at least two elements, whereas now it's possible to pass just the function (e.g. repeatfunc(random.random)).

The problem with the current signature is that you are "forced" to specify the "times" (positionally) whenever you want to pass args to the function -- even if you want an endless repetition (i.e. times=None).

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18313>
_______________________________________

From report at bugs.python.org  Thu Aug  8 15:34:14 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 13:34:14 +0000
Subject: [issue18572] Remove redundant note about surrogates in string escape
	doc
In-Reply-To: <1374941533.84.0.352957238503.issue18572@psf.upfronthosting.co.za>
Message-ID: <1375968854.04.0.285720951993.issue18572@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think it's OK to remove the sentence.

Converting a surrogate pair to a non-BMP char is something that works only while decoding a UTF-16 byte sequence.  Surrogates are invalid in UTF-8/32, and while dealing with Unicode strings, surrogates have no special meaning and are no different from any other codepoint, whether they are lone or paired.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18572>
_______________________________________

From report at bugs.python.org  Thu Aug  8 15:36:45 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 08 Aug 2013 13:36:45 +0000
Subject: [issue18668] Properly document setting m_size in PyModuleDef
In-Reply-To: <1375795246.61.0.949649493069.issue18668@psf.upfronthosting.co.za>
Message-ID: <1375969005.15.0.57863685265.issue18668@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Nick, you're right - m_size=0 is a valid value. How about the attached patch?

----------
Added file: http://bugs.python.org/file31199/issue18668.msize-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18668>
_______________________________________

From report at bugs.python.org  Thu Aug  8 15:37:21 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 13:37:21 +0000
Subject: [issue18576] Rename and document test.script_helper as
	test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1375969041.59.0.749435565492.issue18576@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________

From report at bugs.python.org  Thu Aug  8 15:52:51 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 13:52:51 +0000
Subject: [issue18588] timeit examples should be consistent
In-Reply-To: <1375118438.6.0.867422483387.issue18588@psf.upfronthosting.co.za>
Message-ID: <1375969971.49.0.488270764041.issue18588@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

IIRC those were the actual values I got.  I think I investigated why they were different, but right now I don't remember if I found out why.

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18588>
_______________________________________

From report at bugs.python.org  Thu Aug  8 15:56:34 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 08 Aug 2013 13:56:34 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za>
Message-ID: <1375970194.83.0.231209418764.issue15651@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Thanks Antoine. I think I understand the patch better now. Just a couple small questions and otherwise LGTM

This code in the beginning in PyInit__elementtree:

    m = PyState_FindModule(&elementtreemodule);
    if (m) {
        Py_INCREF(m);
        return m;
    }

Can you explain what use case it tries to cover? I couldn't find similar code in other modules we have that implement PEP 3121 (_csv, readline, io, etc.)

This code has at least one adverse effect, for testing. The problem with re-importing _elementtree I raised in http://mail.python.org/pipermail/python-dev/2013-August/127766.html is solved by moving to PEP 3121, but this piece of code above ruins it. This is because I want to set sys.modules['pyexpat'] = None and re-import _elementtree (this is what support.import_fresh_module does). But with this code in place, if _elementtree was imported any time in the past (say, in a previous test), I'll just get the instance back without attempting to do the full module initialization.


>> I don't see a call to PyState_AddModule. What am I missing?
>It is called implicitly when an extension module is imported.

Do you think this should be documented in the C API docs? The way they read now, it seems that calling PyState_AddModule is needed manually by extension writers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Thu Aug  8 15:57:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 13:57:18 +0000
Subject: [issue18592] IDLE: Unit test for SearchDialogBase.py
In-Reply-To: <1375146770.41.0.774627283078.issue18592@psf.upfronthosting.co.za>
Message-ID: <1375970238.98.0.774406214589.issue18592@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18592>
_______________________________________

From report at bugs.python.org  Thu Aug  8 15:58:13 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 08 Aug 2013 13:58:13 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za>
Message-ID: <1375970293.57.0.611279526463.issue15651@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

> Can you explain what use case it tries to cover?

What I'm trying to say is that although I think I understand its effect (if the same sub-interpreter re-imports _elementtree bypassing the Python module cache, this is an additional level of caching), I'm not sure what *real* use cases it aims for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Thu Aug  8 15:59:48 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 13:59:48 +0000
Subject: [issue18602] "_io" module names itself "io"
In-Reply-To: <1375214267.87.0.837503153982.issue18602@psf.upfronthosting.co.za>
Message-ID: <1375970388.79.0.667255264762.issue18602@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Have you tried to change it and run the test suite?  Maybe it breaks pickling or something similar?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18602>
_______________________________________

From report at bugs.python.org  Thu Aug  8 16:00:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Aug 2013 14:00:10 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1375970194.83.0.231209418764.issue15651@psf.upfronthosting.co.za>
Message-ID: <1510306418.50638959.1375970404276.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> This code in the beginning in PyInit__elementtree:
> 
>     m = PyState_FindModule(&elementtreemodule);
>     if (m) {
>         Py_INCREF(m);
>         return m;
>     }
> 
> Can you explain what use case it tries to cover? I couldn't find
> similar code in other modules we have that implement PEP 3121 (_csv,
> readline, io, etc.)

I don't know :-) I just re-used Robin's original patch.

> >> I don't see a call to PyState_AddModule. What am I missing?
> >It is called implicitly when an extension module is imported.
> 
> Do you think this should be documented in the C API docs? The way
> they read now, it seems that calling PyState_AddModule is needed
> manually by extension writers.

Well, how to deal with module state should probably be better
documented. Not sure how, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Thu Aug  8 16:00:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 14:00:25 +0000
Subject: [issue18604] Consolidate gui available checks in test.support
In-Reply-To: <1375229615.82.0.560303267268.issue18604@psf.upfronthosting.co.za>
Message-ID: <1375970425.79.0.701780598867.issue18604@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18604>
_______________________________________

From report at bugs.python.org  Thu Aug  8 16:00:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Aug 2013 14:00:55 +0000
Subject: [issue18602] "_io" module names itself "io"
In-Reply-To: <1375970388.79.0.667255264762.issue18602@psf.upfronthosting.co.za>
Message-ID: <255816188.50640514.1375970449292.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Have you tried to change it and run the test suite?  Maybe it breaks
> pickling or something similar?

Yeah, it came to me that it may break pickle. The test suite may not
pick it, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18602>
_______________________________________

From report at bugs.python.org  Thu Aug  8 16:02:21 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 08 Aug 2013 14:02:21 +0000
Subject: [issue18673] Add and use O_TMPFILE for Linux 3.11
In-Reply-To: <1375818220.16.0.883591943761.issue18673@psf.upfronthosting.co.za>
Message-ID: <1375970541.14.0.541842122851.issue18673@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18673>
_______________________________________

From report at bugs.python.org  Thu Aug  8 16:08:32 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 08 Aug 2013 14:08:32 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1510306418.50638959.1375970404276.JavaMail.root@zimbra10-e2.priv.proxad.net>
Message-ID: <CAF-Rda971vhE6Pa2qP5ReoPD_XRXPY_q47_FwUS3=RRs0kwG4Q@mail.gmail.com>


Eli Bendersky added the comment:

On Thu, Aug 8, 2013 at 7:00 AM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou added the comment:
>
> > This code in the beginning in PyInit__elementtree:
> >
> >     m = PyState_FindModule(&elementtreemodule);
> >     if (m) {
> >         Py_INCREF(m);
> >         return m;
> >     }
> >
> > Can you explain what use case it tries to cover? I couldn't find
> > similar code in other modules we have that implement PEP 3121 (_csv,
> > readline, io, etc.)
>
> I don't know :-) I just re-used Robin's original patch.
>

Would you mind removing it from the patch, due to the case described above?
ISTM that in real scenarios the sys.modules cache kicks in anyway. It
should not be really bypassed for any given sub-interpreter in sane code.

>
> > >> I don't see a call to PyState_AddModule. What am I missing?
> > >It is called implicitly when an extension module is imported.
> >
> > Do you think this should be documented in the C API docs? The way
> > they read now, it seems that calling PyState_AddModule is needed
> > manually by extension writers.
>
> Well, how to deal with module state should probably be better
> documented. Not sure how, though.
>

I'll think about it some more and will try to propose a documentation
patch. This can be done incrementally; we don't have to go to perfect docs
on the first try ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Thu Aug  8 16:14:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Aug 2013 14:14:32 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <CAF-Rda971vhE6Pa2qP5ReoPD_XRXPY_q47_FwUS3=RRs0kwG4Q@mail.gmail.com>
Message-ID: <296734553.50663270.1375971265469.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Would you mind removing it from the patch, due to the case described
> above?
> ISTM that in real scenarios the sys.modules cache kicks in anyway. It
> should not be really bypassed for any given sub-interpreter in sane
> code.

Yeah, I think you're right. I'll submit an updated patch or, if it's
the only issue with it, perhaps you can simply remove the 3 offending
lines?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Thu Aug  8 16:47:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Aug 2013 14:47:49 +0000
Subject: [issue18588] timeit examples should be consistent
In-Reply-To: <1375118438.6.0.867422483387.issue18588@psf.upfronthosting.co.za>
Message-ID: <1375973269.39.0.666247779095.issue18588@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In command-line invocation the gc is disabled. And timit.repeat() is used instead of timit.timit().

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18588>
_______________________________________

From report at bugs.python.org  Thu Aug  8 16:55:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Aug 2013 14:55:57 +0000
Subject: [issue17974] Migrate unittest to argparse
In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za>
Message-ID: <1375973757.75.0.173670915595.issue17974@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Is the patch good?

----------
assignee:  -> serhiy.storchaka
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17974>
_______________________________________

From report at bugs.python.org  Thu Aug  8 17:05:54 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 08 Aug 2013 15:05:54 +0000
Subject: [issue18685] Restore re performance to pre-PEP393 level
In-Reply-To: <1375967417.95.0.0303828296889.issue18685@psf.upfronthosting.co.za>
Message-ID: <1375974354.06.0.518590129246.issue18685@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

It appears that in your tests Python 3.2 is faster with Unicode than bytestrings and that unpatched Python 3.4 is a lot slower.

I get somewhat different results (Windows XP Pro, 32-bit):

C:\Python32\python.exe -m timeit -s "import re; f = re.compile(b'abc').search; x = b'x'*100000" "f(x)"
1000 loops, best of 3: 449 usec per loop

C:\Python32\python.exe -m timeit -s "import re; f = re.compile('abc').search; x = 'x'*100000" "f(x)"
1000 loops, best of 3: 506 usec per loop

C:\Python32\python.exe -m timeit -s "import re; f = re.compile('abc').search; x = '\u20ac'*100000" "f(x)"
1000 loops, best of 3: 506 usec per loop


C:\Python34\python.exe -m timeit -s "import re; f = re.compile(b'abc').search; x = b'x'*100000" "f(x)"
1000 loops, best of 3: 227 usec per loop

C:\Python34\python.exe -m timeit -s "import re; f = re.compile('abc').search; x = 'x'*100000" "f(x)"
1000 loops, best of 3: 339 usec per loop

C:\Python34\python.exe -m timeit -s "import re; f = re.compile('abc').search; x = '\u20ac'*100000" "f(x)"
1000 loops, best of 3: 504 usec per loop

For comparison, in the regex module I don't duplicate whole sections of code, but instead have a pointer to one of 3 functions (for UCS1, UCS2 and UCS4) that gets the codepoint, except for some tight loops. Doing that might be too much of a change for re.

However, the speed appears to be a lot more consistent:

C:\Python32\python.exe -m timeit -s "import regex; f = regex.compile(b'abc').search; x = b'x'*100000" "f(x)"
10000 loops, best of 3: 113 usec per loop

C:\Python32\python.exe -m timeit -s "import regex; f = regex.compile('abc').search; x = 'x'*100000" "f(x)"
10000 loops, best of 3: 113 usec per loop

C:\Python32\python.exe -m timeit -s "import regex; f = regex.compile('abc').search; x = '\u20ac'*100000" "f(x)"
10000 loops, best of 3: 113 usec per loop


C:\Python34\python.exe -m timeit -s "import regex; f = regex.compile(b'abc').search; x = b'x'*100000" "f(x)"
10000 loops, best of 3: 113 usec per loop

C:\Python34\python.exe -m timeit -s "import regex; f = regex.compile('abc').search; x = 'x'*100000" "f(x)"
10000 loops, best of 3: 113 usec per loop

C:\Python34\python.exe -m timeit -s "import regex; f = regex.compile('abc').search; x = '\u20ac'*100000" "f(x)"
10000 loops, best of 3: 113 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18685>
_______________________________________

From report at bugs.python.org  Thu Aug  8 17:16:39 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 08 Aug 2013 15:16:39 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <296734553.50663270.1375971265469.JavaMail.root@zimbra10-e2.priv.proxad.net>
Message-ID: <CAF-Rda_5KaBqTjGp40ipYaDSRU=OeerCiY67mkZrVz7z6_XcEQ@mail.gmail.com>


Eli Bendersky added the comment:

On Thu, Aug 8, 2013 at 7:14 AM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou added the comment:
>
> > Would you mind removing it from the patch, due to the case described
> > above?
> > ISTM that in real scenarios the sys.modules cache kicks in anyway. It
> > should not be really bypassed for any given sub-interpreter in sane
> > code.
>
> Yeah, I think you're right. I'll submit an updated patch or, if it's
> the only issue with it, perhaps you can simply remove the 3 offending
> lines?
>

Sure, I'll do that. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Thu Aug  8 17:23:09 2013
From: report at bugs.python.org (Derek Wilson)
Date: Thu, 08 Aug 2013 15:23:09 +0000
Subject: [issue18679] include a codec to handle escaping only control
	characters but not any others
In-Reply-To: <1375910565.85.0.834240880509.issue18679@psf.upfronthosting.co.za>
Message-ID: <1375975389.52.0.486981334706.issue18679@psf.upfronthosting.co.za>


Derek Wilson added the comment:

using repr(x)[1:-1] is not safe for my use case as i need this for encoding and decoding data. the "deserialization" of repr would be eval, and aside from the security issues with that, if I strip the quotes off I can't reliably eval the result and get back the original. On top of that, quote escape handling makes this non-portable to other languages/tools that do understand control character escapes. Consider:

>>> s = """?""\t'''?"""
>>> print(s)
?""	'''?
>>> e = repr(s)[1:-1]
>>> print(e)
?""\t\'\'\'?

how do i know what to quote e with before I eval it to get back the value? I can't even try all the quoting options and stop when i don't get a syntax error because more than one could work and give me a bad result:

>>> d = eval('"{}"'.format(e))
>>> d == s
False
>>> print(d)
?	'''?

Aside from python not being able to handle the repr(x)[1:-1] case itself, the goal is to use output generated in common tools from cut to hadoop where tab is a field separator (aside: wouldn't adoption of ascii 0x1f as a common unit separator be great). Sometimes it is useful to separate newlines in data from a literal new line in formats (again like hadoop or unix utilities) that treat lines as records (and here again ascii 0x1e would have been a nice solution).

But we have to work with what we've got and there are many tools that care about tab separated fields and per line records. In these cases, the right tool for the interoperability job is a codec that simply backslash escapes control characters and nothing else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18679>
_______________________________________

From report at bugs.python.org  Thu Aug  8 17:33:28 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 08 Aug 2013 15:33:28 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
In-Reply-To: <1375958587.67.0.887335458452.issue18677@psf.upfronthosting.co.za>
Message-ID: <CADiSq7cjpOoBk_hkHT6bOGO9b6HdHcom4vgZpn18w1XfhOiX+g@mail.gmail.com>


Nick Coghlan added the comment:

Allowing a context manager to skip the statement body isn't a new proposal,
and I previously argued your side. However, with multiple context managers,
there is no invisible flow control. Two context managers are locally
visible, which means the outer one completely encloses the inner one and
can suppress exceptions it throws. Guido explicitly made the decision to
require two managers at the point of use to achieve that behaviour when I
proposed making the change - he doesn't care about allowing a single
context manager to provide that functionality.

For the other question, how does your version of nested keep people from
doing "nested(open(fname) for name in names)"? That was the core problem
with that style of API: it made it far too easy to introduce a latent
defect when combined with file like objects that eagerly acquire their
resource. It wasn't that it couldn't be used correctly, but that the
natural and obvious way of combining it with open() is silently wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18677>
_______________________________________

From report at bugs.python.org  Thu Aug  8 17:38:11 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 08 Aug 2013 15:38:11 +0000
Subject: [issue18668] Properly document setting m_size in PyModuleDef
In-Reply-To: <1375969005.15.0.57863685265.issue18668@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fYqr_C1TZ0y3WXk7ivEfcqTgX8VZRYYVvyRPTUWxeR3Q@mail.gmail.com>


Nick Coghlan added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18668>
_______________________________________

From report at bugs.python.org  Thu Aug  8 17:41:39 2013
From: report at bugs.python.org (Clay McClure)
Date: Thu, 08 Aug 2013 15:41:39 +0000
Subject: [issue18588] timeit examples should be consistent
In-Reply-To: <1375118438.6.0.867422483387.issue18588@psf.upfronthosting.co.za>
Message-ID: <1375976499.16.0.522822007683.issue18588@psf.upfronthosting.co.za>


Clay McClure added the comment:

There's a 68% difference in running time between the command-line and programmatic invocations shown in the current documentation, and a 1% difference between the runtimes shown in the patch. I can't speak for why that is the case, but I did find it somewhat confusing when trying to interpret the timeit documentation.

Being a somewhat pedantic and trivial patch, I'm fine if you want to close it wontfix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18588>
_______________________________________

From report at bugs.python.org  Thu Aug  8 17:45:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Aug 2013 15:45:07 +0000
Subject: [issue18679] include a codec to handle escaping only control
	characters but not any others
In-Reply-To: <1375910565.85.0.834240880509.issue18679@psf.upfronthosting.co.za>
Message-ID: <1375976707.68.0.422436551021.issue18679@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

ast.literal_eval("'%s'" % e)
e.encode().decode('unicode-escape').encode('latin1').decode()
e.encode('latin1', 'backslashescape').decode('unicode-escape')

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18679>
_______________________________________

From report at bugs.python.org  Thu Aug  8 18:23:03 2013
From: report at bugs.python.org (Derek Wilson)
Date: Thu, 08 Aug 2013 16:23:03 +0000
Subject: [issue18679] include a codec to handle escaping only control
	characters but not any others
In-Reply-To: <1375910565.85.0.834240880509.issue18679@psf.upfronthosting.co.za>
Message-ID: <1375978983.12.0.496269878875.issue18679@psf.upfronthosting.co.za>


Derek Wilson added the comment:

> ast.literal_eval("'%s'" % e)

this doesn't work if you use the wrong quote. without introspecting the data in e you can't reliably choose whether to use "'%s'" '"%s"' '"""%s"""' or "'''%s'''". which ones break (and break siliently) depend on the data.


> e.encode().decode('unicode-escape').encode('latin1').decode()

so ... encode the repr()[1:-1] string in utf-8 bytes, decode backslash escape sequences and individual bytes as if they are latin1, encode as latin1 (which is just byte for byte serialization), then decode the byte representation as if it is utf-8 encoded to recombine the characters that were broken with the 'unicode-escape' decode earlier? 

this may work for my example, but this looks and feels very hacky for something that should be simple and straight forward. and again tools other than python will run into escaped quotes in the data which may cause problems.

> e.encode('latin1', 'backslashescape').decode('unicode-escape')

when i execute this i get a traceback

LookupError: unknown error handler name 'backslashescape'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18679>
_______________________________________

From report at bugs.python.org  Thu Aug  8 18:40:17 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Aug 2013 16:40:17 +0000
Subject: [issue18581] Duplicate test and missing class test in test_abc.py
In-Reply-To: <1375024185.25.0.955191764132.issue18581@psf.upfronthosting.co.za>
Message-ID: <3c9wL85yBvzQRq@mail.python.org>


Roundup Robot added the comment:

New changeset e8f8f81c5af6 by Ezio Melotti in branch '3.3':
#18581: remove duplicate test and run a test class that was skipped.  Initial patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/e8f8f81c5af6

New changeset 328b1a29102c by Ezio Melotti in branch 'default':
#18581: merge with 3.3.
http://hg.python.org/cpython/rev/328b1a29102c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18581>
_______________________________________

From report at bugs.python.org  Thu Aug  8 18:41:09 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 16:41:09 +0000
Subject: [issue18581] Duplicate test and missing class test in test_abc.py
In-Reply-To: <1375024185.25.0.955191764132.issue18581@psf.upfronthosting.co.za>
Message-ID: <1375980069.37.0.911247412052.issue18581@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18581>
_______________________________________

From report at bugs.python.org  Thu Aug  8 18:44:14 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 16:44:14 +0000
Subject: [issue18626] Make "python -m inspect <name>" dump the source of a
	module
In-Reply-To: <1375413160.45.0.218073630788.issue18626@psf.upfronthosting.co.za>
Message-ID: <1375980254.36.0.529717866294.issue18626@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18626>
_______________________________________

From report at bugs.python.org  Thu Aug  8 18:45:37 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 16:45:37 +0000
Subject: [issue18628] Better index entry for encoding declarations
In-Reply-To: <1375418984.87.0.318628832877.issue18628@psf.upfronthosting.co.za>
Message-ID: <1375980337.56.0.0577060888277.issue18628@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18628>
_______________________________________

From report at bugs.python.org  Thu Aug  8 18:55:42 2013
From: report at bugs.python.org (Jeffrey Goeders)
Date: Thu, 08 Aug 2013 16:55:42 +0000
Subject: [issue18686] Tkinter focus_get on menu causes crash
Message-ID: <1375980942.46.0.944431245569.issue18686@psf.upfronthosting.co.za>


New submission from Jeffrey Goeders:

I am experiencing a crash when calling focus_get() when a Tk Menu has focus.  Here is sample code, just click the menu and it will crash.


import Tkinter as tk

class App(tk.Tk):
    def __init__(self, *args, **kw):
        tk.Tk.__init__(self, *args, **kw)
        
        self.entry = tk.Entry(self)
        self.entry.grid(padx=20, pady=20)
        self.entry.focus_set()
        self.entry.bind("<FocusOut>", self.entry_focus_lost)
        
        self.menubar = tk.Menu(self)
        self["menu"] = self.menubar
        
        self.menufile = tk.Menu(self.menubar, tearoff=False)
        self.menubar.add_cascade(menu=self.menufile, label="File")

    def entry_focus_lost(self, event):
        widget_with_focus = self.focus_get()


app = App()
app.mainloop()


Here is the error stack:
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib64/python2.7/lib-tk/Tkinter.py", line 1410, in __call__
    return self.func(*args)
  File "/home/jgoeders/workspace/tester/test_menu_focus.py", line 19, in entry_focus_lost
    widget_with_focus = self.focus_get()
  File "/usr/lib64/python2.7/lib-tk/Tkinter.py", line 446, in focus_get
    return self._nametowidget(name)
  File "/usr/lib64/python2.7/lib-tk/Tkinter.py", line 1079, in nametowidget
    w = w.children[n]
KeyError: '#140030874747536'

----------
components: Tkinter
messages: 194693
nosy: jgoeders
priority: normal
severity: normal
status: open
title: Tkinter focus_get on menu causes crash
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18686>
_______________________________________

From report at bugs.python.org  Thu Aug  8 18:56:48 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 16:56:48 +0000
Subject: [issue18326] Mention 'keyword only' for list.sort, improve  glossary.
In-Reply-To: <1372511136.61.0.278425078947.issue18326@psf.upfronthosting.co.za>
Message-ID: <1375981008.21.0.544011152713.issue18326@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

"keyword-only" is a well-established term, and I think it's better to use it and possibly make it a link to the "parameter" entry of the glossary.

----------
nosy: +ezio.melotti
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18326>
_______________________________________

From report at bugs.python.org  Thu Aug  8 18:59:09 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 16:59:09 +0000
Subject: [issue18335] Add textwrap.dedent, .indent, as str methods.
In-Reply-To: <1372656829.33.0.351971247179.issue18335@psf.upfronthosting.co.za>
Message-ID: <1375981149.26.0.57361111091.issue18335@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18335>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:13:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Aug 2013 17:13:12 +0000
Subject: [issue18357] add tests for dictview set difference operations
In-Reply-To: <1372937608.11.0.328710498036.issue18357@psf.upfronthosting.co.za>
Message-ID: <3c9x4742Hhz7Ll4@mail.python.org>


Roundup Robot added the comment:

New changeset 0152152b09d0 by Ezio Melotti in branch '2.7':
#18357: add tests for dictview set difference.  Patch by Fraser Tweedale.
http://hg.python.org/cpython/rev/0152152b09d0

New changeset 8b557ef46d7c by Ezio Melotti in branch '3.3':
#18357: add tests for dictview set difference.  Patch by Fraser Tweedale.
http://hg.python.org/cpython/rev/8b557ef46d7c

New changeset 4db3d3d5815c by Ezio Melotti in branch 'default':
#18357: merge with 3.3.
http://hg.python.org/cpython/rev/4db3d3d5815c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18357>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:14:30 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 17:14:30 +0000
Subject: [issue18357] add tests for dictview set difference operations
In-Reply-To: <1372937608.11.0.328710498036.issue18357@psf.upfronthosting.co.za>
Message-ID: <1375982070.8.0.0546731997885.issue18357@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18357>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:17:33 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 17:17:33 +0000
Subject: [issue18375] python -m test --randseed 1234 does not randomize tests
In-Reply-To: <1373105386.95.0.445511556966.issue18375@psf.upfronthosting.co.za>
Message-ID: <1375982253.28.0.554666669148.issue18375@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18375>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:18:00 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 17:18:00 +0000
Subject: [issue18381] unittest warnings counter
In-Reply-To: <1373114259.86.0.274298241842.issue18381@psf.upfronthosting.co.za>
Message-ID: <1375982280.95.0.611141479375.issue18381@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18381>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:19:55 2013
From: report at bugs.python.org (py.user)
Date: Thu, 08 Aug 2013 17:19:55 +0000
Subject: [issue18313] In itertools recipes repeatfunc() defines a non-keyword
	argument as keyword
In-Reply-To: <1372309261.95.0.7034101172.issue18313@psf.upfronthosting.co.za>
Message-ID: <1375982395.16.0.456474414957.issue18313@psf.upfronthosting.co.za>


py.user added the comment:

> This would require you to provide at least two elements
I see
how about "def repeatfunc(func, *args, times=None):" ?


>>> from itertools import starmap, repeat
>>> 
>>> def repeatfunc(func, *args, times=None):
...     """Repeat calls to func with specified arguments.
... 
...     Example:  repeatfunc(random.random)
...     """
...     if times is None:
...         return starmap(func, repeat(args))
...     return starmap(func, repeat(args, times))
... 
>>> def f(*args):
...     print(args)
... 
>>> r = repeatfunc(f, 1, 2)
>>> next(r)
(1, 2)
>>> next(r)
(1, 2)
>>> next(r)
(1, 2)
>>> r = repeatfunc(f, 1, 2, times=1)
>>> next(r)
(1, 2)
>>> next(r)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18313>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:23:39 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 17:23:39 +0000
Subject: [issue18409] IDLE Improvements: Unit test for AutoComplete.py
In-Reply-To: <1373337231.6.0.320085332655.issue18409@psf.upfronthosting.co.za>
Message-ID: <1375982619.73.0.595811662667.issue18409@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18409>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:23:48 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 17:23:48 +0000
Subject: [issue18410] IDLE Improvements: Unit test for SearchDialog.py
In-Reply-To: <1373338807.5.0.870375456877.issue18410@psf.upfronthosting.co.za>
Message-ID: <1375982628.63.0.560101520079.issue18410@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18410>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:25:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 17:25:25 +0000
Subject: [issue18423] Document limitations on -m
In-Reply-To: <1373461112.24.0.280779659137.issue18423@psf.upfronthosting.co.za>
Message-ID: <1375982725.81.0.251391098832.issue18423@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
type:  -> enhancement
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18423>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:29:05 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Aug 2013 17:29:05 +0000
Subject: [issue18671] enhance formatting in logging package
In-Reply-To: <1375804669.84.0.0477385788117.issue18671@psf.upfronthosting.co.za>
Message-ID: <3c9xQS5xbpz7Lmh@mail.python.org>


Roundup Robot added the comment:

New changeset a206f952668e by Vinay Sajip in branch 'default':
Closes #18671: Output more information when logging exceptions occur.
http://hg.python.org/cpython/rev/a206f952668e

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18671>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:29:22 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 17:29:22 +0000
Subject: [issue18425] IDLE Unit test for IdleHistory.py
In-Reply-To: <1373493838.59.0.876568806243.issue18425@psf.upfronthosting.co.za>
Message-ID: <1375982962.98.0.260930122604.issue18425@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18425>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:30:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Aug 2013 17:30:52 +0000
Subject: [issue18626] Make "python -m inspect <name>" dump the source of a
	module
In-Reply-To: <1375413160.45.0.218073630788.issue18626@psf.upfronthosting.co.za>
Message-ID: <1375983052.11.0.53750205301.issue18626@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I agree that it will be better to output a formalized report about a module and it's contents using inspect.getmoduleinfo() and inspect.getmembers().

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18626>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:31:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Aug 2013 17:31:07 +0000
Subject: [issue18679] include a codec to handle escaping only control
	characters but not any others
In-Reply-To: <1375910565.85.0.834240880509.issue18679@psf.upfronthosting.co.za>
Message-ID: <1375983067.05.0.514891322657.issue18679@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> this doesn't work if you use the wrong quote. without introspecting the data in e you can't reliably choose whether to use "'%s'" '"%s"' '"""%s"""' or "'''%s'''".

Indeed.

> and again tools other than python will run into escaped quotes in the data which may cause problems.

Then use s.translate() or re.sub() for encoding.

> when i execute this i get a traceback

Sorry, it should be

e.encode('latin1', 'backslashreplace').decode('unicode-escape').

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18679>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:40:32 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 17:40:32 +0000
Subject: [issue18436] Add mapping of symbol to function to operator module
In-Reply-To: <1373662006.12.0.760343850871.issue18436@psf.upfronthosting.co.za>
Message-ID: <1375983632.66.0.517316755036.issue18436@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18436>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:44:31 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 17:44:31 +0000
Subject: [issue18445] Tools/Script/Readme is outdated
In-Reply-To: <1373782620.19.0.347266346086.issue18445@psf.upfronthosting.co.za>
Message-ID: <1375983871.25.0.780642697196.issue18445@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18445>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:45:26 2013
From: report at bugs.python.org (py.user)
Date: Thu, 08 Aug 2013 17:45:26 +0000
Subject: [issue18301] In itertools.chain.from_iterable() there is no cls
	argument
In-Reply-To: <1372186723.21.0.67533324157.issue18301@psf.upfronthosting.co.za>
Message-ID: <1375983926.78.0.0867551089755.issue18301@psf.upfronthosting.co.za>


py.user added the comment:

>>> import itertools
>>> 
>>> class A(itertools.chain):
...     def from_iter(arg):
...         return A(iter(arg))
... 
>>> class B(A):
...     pass
... 
>>> B('a', 'b')
<__main__.B object at 0x7f40116d7730>
>>> B.from_iter(['a', 'b'])
<__main__.A object at 0x7f40116d7780>
>>>

it should be B

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18301>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:47:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 08 Aug 2013 17:47:56 +0000
Subject: [issue18680] JSONDecoder should document that it raises a ValueError
	for malformed data
In-Reply-To: <1375913191.45.0.0174536581066.issue18680@psf.upfronthosting.co.za>
Message-ID: <1375984076.76.0.799357616967.issue18680@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +easy
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18680>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:49:02 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Aug 2013 17:49:02 +0000
Subject: [issue18456] Documentation for PyDict_Update is incorrect
In-Reply-To: <1373854272.6.0.0142348360978.issue18456@psf.upfronthosting.co.za>
Message-ID: <1375984142.97.0.164199685831.issue18456@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18456>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:58:38 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Aug 2013 17:58:38 +0000
Subject: [issue18686] Tkinter focus_get on menu causes crash
In-Reply-To: <1375980942.46.0.944431245569.issue18686@psf.upfronthosting.co.za>
Message-ID: <1375984718.28.0.334414937274.issue18686@psf.upfronthosting.co.za>


R. David Murray added the comment:

We use the 'crash' type for interpreter crashes (segfaults).  So goes under the 'behavior' type.

----------
nosy: +r.david.murray
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18686>
_______________________________________

From report at bugs.python.org  Thu Aug  8 19:59:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Aug 2013 17:59:22 +0000
Subject: [issue18686] Tkinter focus_get on menu results in KeyError
In-Reply-To: <1375980942.46.0.944431245569.issue18686@psf.upfronthosting.co.za>
Message-ID: <1375984762.96.0.405704335992.issue18686@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: Tkinter focus_get on menu causes crash -> Tkinter focus_get on menu results in KeyError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18686>
_______________________________________

From report at bugs.python.org  Thu Aug  8 20:05:16 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Thu, 08 Aug 2013 18:05:16 +0000
Subject: [issue18687] Lib/test/leakers/test_ctypes.py still mentions the need
	to update Misc/build.sh
Message-ID: <1375985116.56.0.149122259336.issue18687@psf.upfronthosting.co.za>


New submission from F?vry Thibault:

"# When this leak is fixed, remember to remove from Misc/build.sh LEAKY_TESTS." -> Misc/build.sh got removed 19 months ago, this should be updated.

----------
assignee: docs at python
components: Documentation
files: patch.diff
keywords: patch
messages: 194703
nosy: docs at python, iwontbecreative
priority: normal
severity: normal
status: open
title: Lib/test/leakers/test_ctypes.py still mentions the need to update Misc/build.sh
versions: Python 3.4
Added file: http://bugs.python.org/file31200/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18687>
_______________________________________

From report at bugs.python.org  Thu Aug  8 20:51:47 2013
From: report at bugs.python.org (Lukas Wunner)
Date: Thu, 08 Aug 2013 18:51:47 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1375987907.83.0.285597281071.issue1424152@psf.upfronthosting.co.za>


Lukas Wunner added the comment:

Unfortunately this bug was only fixed in urllib2.py but never in urllib.py. This keeps biting people in the butt to this very day. Example: https://chromiumcodereview.appspot.com/10825107/

The attached patch remedies that and also fixes some more issues:

(1) proxy_bypass handling:
URLopener.open() will route the request to one of the open_*() methods based on the type of the *request* url. However, if a proxy is defined, it instead routes the request based on the type of the *proxy* url. So far so good. But: In open_http(), the code checks if proxy_bypass(realhost) is true and if so it modifies the Host header of the outgoing request. This code only works properly if the request url is by chance of type "http". If the request url type is e.g. "ftp" and the proxy url type is "http" and there's a proxy_bypass defined for realhost, things will go awry since the program will try to speak HTTP with realhost while it should really speak FTP. (In other words, open_ftp() should be used instead of open_http(), the program is stuck in the wrong codepath.) Also, proxy_bypass handling is currently only implemented for the proxy url type "http" (and not, for instance, "https"). The patch solves this by moving the proxy_bypass check to URLopener.open(): If a proxy_bypass is defined for realhost, the request is routed based on the request url type and not based on the proxy url type.

(2) addinfourl construction:
Upon successful retrieval of the URL, open_http() and open_https() will construct an addinfourl object and return that to the caller. The object is constructed with hard coded url type "http" / "https". So if for instance the request url type is "ftp" and the proxy url type is "http", the addinfourl object will contain a url whose type will have magically changed from "ftp" to "http".

(3) Superfluous code:
At the beginning of open_http() and open_https(), the program sets "user_passwd = None". Directly below is an if-else statement. At the beginning of the else block the program again sets "user_passwd = None".

The patch also works with Python 2.6 save for set_tunnel() in httplib.py, which was called _set_tunnel() in 2.6.

----------
nosy: +l
Added file: http://bugs.python.org/file31201/issue1424152-py27-urllib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Thu Aug  8 21:12:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Aug 2013 19:12:46 +0000
Subject: [issue18688] Document undocumented Unicode object API
Message-ID: <1375989166.23.0.200448183394.issue18688@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Include/unicodeobject.h contains followed names which are declared as public but are not documented in Doc/c-api/unicode.rst.

PyUnicodeIter_Type
Py_UNICODE_REPLACEMENT_CHARACTER
PyUnicode_Resize
PyUnicode_InternImmortal
PyUnicode_CHECK_INTERNED
PyUnicode_FromOrdinal
PyUnicode_GetDefaultEncoding
PyUnicode_AsDecodedObject
PyUnicode_AsDecodedUnicode
PyUnicode_AsEncodedObject
PyUnicode_AsEncodedUnicode
PyUnicode_BuildEncodingMap
PyUnicode_DecodeCodePageStateful
PyUnicode_Append
PyUnicode_AppendAndDel
PyUnicode_Partition
PyUnicode_RPartition
PyUnicode_RSplit
PyUnicode_IsIdentifier
_PyUnicode_FromId
_PyUnicode_ClearStaticStrings

They should be either documented or declared as private.

PyUnicode_AsEncodedObject only mentioned in Doc/whatsnew/3.3.rst as recomended replacement of PyUnicode_Encode.

----------
assignee: docs at python
components: Documentation, Unicode
messages: 194705
nosy: docs at python, ezio.melotti, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Document undocumented Unicode object API
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18688>
_______________________________________

From report at bugs.python.org  Thu Aug  8 22:15:37 2013
From: report at bugs.python.org (Derek Wilson)
Date: Thu, 08 Aug 2013 20:15:37 +0000
Subject: [issue18689] add argument for formatter to logging.Handler and
	subclasses in logging module
Message-ID: <1375992937.35.0.58426954587.issue18689@psf.upfronthosting.co.za>


New submission from Derek Wilson:

It is common when setting up a logger to create both a handler and a formatter. Nice format strings make logging better. Like this:

>>> fmt_string = "%(asctime)s [%(levelname)-9s] %(name)s: %(message)s"

We would use it like so: 

>>> from logging import getLogger, StreamHandler, Formatter
>>> logger = getLogger('mypackage.mymodule')
>>> handler = StreamHandler()
>>> formatter = Formatter(fmt_string)
>>> handler.setFormatter(formatter)
>>> logger.addHandler(handler)
>>> logger.warning('she called out a warning...')

But its nice to separate adding handlers from using loggers. so in mymodule I might do:

>>> logger = getLogger('mypackage.mymodule')
>>> logger.warning('do not pass go...')

and in whatever entry point cares about logging from mypackage (like a cli or another module importing my package that wants log data) I would do:

>>> base_logger = getLogger('mypackage')
>>> handler = StreamHandler()
>>> formatter = Formatter(fmt_string)
>>> handler.setFormatter(formatter)
>>> base_logger.addHandler(handler)

but usually, at this point, i don't care about this base_logger at all and i've got a bunch of refs to things i don't need anymore - the only purpose of all this code is to handle any logging that may be done elsewhere in the package.

If handlers allowed passing in a formatter into __init__, then we could reduce the above to something like this:

>>> getLogger('mypackage').addHandler(StreamHandler(
        fmt=Formatter(fmt_string)))

Using a kwarg would make it so we don't need to worry about existing argument order so that should be completely backward compatible.

It'd be extra friendly if Handler could introspect fmt and see if it is an instance str and if so create a Formatter in itself ... that way we could do:

>>> getLogger('mypackage').addHandler(StreamHandler(fmt=fmt_string))

This would reduce the barrier to entry to customizing logging functionality and might go a long way toward increasing effective use of the same.

----------
components: Library (Lib)
messages: 194706
nosy: underrun
priority: normal
severity: normal
status: open
title: add argument for formatter to logging.Handler and subclasses in logging module
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18689>
_______________________________________

From report at bugs.python.org  Thu Aug  8 22:38:26 2013
From: report at bugs.python.org (Simon Feltman)
Date: Thu, 08 Aug 2013 20:38:26 +0000
Subject: [issue18690] memoryview not considered a sequence
Message-ID: <1375994306.09.0.288774044914.issue18690@psf.upfronthosting.co.za>


New submission from Simon Feltman:

This was a bit unexpected as memoryviews support all the methods of the Sequence abstract base class:

>>> import collections
>>> b = bytearray(b'asdf')
>>> isinstance(b, collections.Sequence)
True
>>> m = memoryview(b)
>>> isinstance(m, collections.Sequence)
False

It would be nice if memoryview was registered with the Sequence ABC and MutableSequence for writeable memoryviews.

----------
components: Library (Lib)
messages: 194707
nosy: sfeltman
priority: normal
severity: normal
status: open
title: memoryview not considered a sequence
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18690>
_______________________________________

From report at bugs.python.org  Thu Aug  8 22:47:28 2013
From: report at bugs.python.org (Derek Wilson)
Date: Thu, 08 Aug 2013 20:47:28 +0000
Subject: [issue18679] include a codec to handle escaping only control
	characters but not any others
In-Reply-To: <1375910565.85.0.834240880509.issue18679@psf.upfronthosting.co.za>
Message-ID: <1375994848.89.0.804264522586.issue18679@psf.upfronthosting.co.za>


Derek Wilson added the comment:

> e.encode('latin1', 'backslashreplace').decode('unicode-escape')

this works, but still the quotes are backslash escaped. 

translate will do what i need for my use case, but it doesn't support streaming for larger chunks of data.

it is nice that there is a workaround but i do still think this is a valuable enough feature that there should be a builtin codec for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18679>
_______________________________________

From report at bugs.python.org  Fri Aug  9 00:15:21 2013
From: report at bugs.python.org (Francisco Freire)
Date: Thu, 08 Aug 2013 22:15:21 +0000
Subject: [issue14019] Unify tests for str.format and string.Formatter
In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za>
Message-ID: <1376000121.26.0.592781808024.issue14019@psf.upfronthosting.co.za>


Francisco Freire added the comment:

I increased the coverage of formatter module to 40%. I added a new file "test_formatter.py" including some unit tests.

----------
keywords: +patch
nosy: +francisco.freire
Added file: http://bugs.python.org/file31202/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14019>
_______________________________________

From report at bugs.python.org  Fri Aug  9 00:22:52 2013
From: report at bugs.python.org (Andrew Myers)
Date: Thu, 08 Aug 2013 22:22:52 +0000
Subject: [issue18691] sqlite3.Cursor.execute expects sequence as second
	argument.
Message-ID: <1376000572.11.0.481266307811.issue18691@psf.upfronthosting.co.za>


New submission from Andrew Myers:

Sorry if this isn't the place for this, it is my first python bug report.

In PEP 249 Python database API specifiction 2.0 the Cursor execute method[1] is described as taking a variable number of arguments for substitution of '?' in the SQL string.  In the documentation of the sqlite3 module the Cursor execute method is also described this way[2].

However, the actual method requires a sequence, in the same way that the executemany method does.  This does not match the execute method in (for instance) pyodbc and means one cannot write code that is (fully) agnostic to the connection type.

[1]: http://www.python.org/dev/peps/pep-0249/#id15
[2]: http://docs.python.org/2/library/sqlite3.html#sqlite3.Cursor.execute

Pasted below is an example of this from python 3.3

In [1]: import sqlite3
In [2]: con = sqlite3.connect(":memory:")
In [4]: con.execute('create table foo (bar int, baz int)')
Out[4]: <sqlite3.Cursor at 0x7fe622286730>

In [5]: con.execute('insert into foo values (?, ?)', 4, 5)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-5-a0ea5e3e7a03> in <module>()
----> 1 con.execute('insert into foo values (?, ?)', 4, 5)

TypeError: function takes at most 2 arguments (3 given)

In [6]: con.execute('insert into foo values (?, ?)', (4, 5))
Out[6]: <sqlite3.Cursor at 0x7fe622201880>

In [7]:

----------
components: Library (Lib)
messages: 194710
nosy: Andrew.Myers
priority: normal
severity: normal
status: open
title: sqlite3.Cursor.execute expects sequence as second argument.
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18691>
_______________________________________

From report at bugs.python.org  Fri Aug  9 00:28:32 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Aug 2013 22:28:32 +0000
Subject: [issue18691] sqlite3.Cursor.execute expects sequence as second
	argument.
In-Reply-To: <1376000572.11.0.481266307811.issue18691@psf.upfronthosting.co.za>
Message-ID: <1376000912.25.0.256862056483.issue18691@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18691>
_______________________________________

From report at bugs.python.org  Fri Aug  9 02:02:19 2013
From: report at bugs.python.org (INNA)
Date: Fri, 09 Aug 2013 00:02:19 +0000
Subject: [issue18692] Connection change in compiled code
Message-ID: <1376006539.81.0.90020007488.issue18692@psf.upfronthosting.co.za>


New submission from INNA:

Hi,

I have a compiled code, which currently uses SQLITE connection (datastore). I was wondering if it is possible to change the connection string to use SQL Server database.

I would like to export the datastore to SQL server database, as we are having issues with the limit.

Thank you.
Inna

----------
components: Windows
messages: 194711
nosy: INNESSA
priority: normal
severity: normal
status: open
title: Connection change in compiled code
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18692>
_______________________________________

From report at bugs.python.org  Fri Aug  9 03:13:57 2013
From: report at bugs.python.org (py.user)
Date: Fri, 09 Aug 2013 01:13:57 +0000
Subject: [issue18301] In itertools.chain.from_iterable() there is no cls
	argument
In-Reply-To: <1372186723.21.0.67533324157.issue18301@psf.upfronthosting.co.za>
Message-ID: <1376010837.17.0.322946398209.issue18301@psf.upfronthosting.co.za>


py.user added the comment:

changed iter(arg) to *arg


>>> import itertools
>>> 
>>> class A(itertools.chain):
...     @classmethod
...     def from_iter(cls, arg):
...         return cls(*arg)
... 
>>> class B(A):
...     pass
... 
>>> B('ab', 'cd')
<__main__.B object at 0x7fc280e93cd0>
>>> b = B.from_iter(['ab', 'cd'])
>>> b
<__main__.B object at 0x7fc280e93d20>
>>> next(b)
'a'
>>> next(b)
'b'
>>> next(b)
'c'
>>> next(b)
'd'
>>> next(b)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18301>
_______________________________________

From report at bugs.python.org  Fri Aug  9 03:55:06 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Aug 2013 01:55:06 +0000
Subject: [issue18692] Connection change in compiled code
In-Reply-To: <1376006539.81.0.90020007488.issue18692@psf.upfronthosting.co.za>
Message-ID: <1376013306.61.0.560690214213.issue18692@psf.upfronthosting.co.za>


R. David Murray added the comment:

This issue tracker is for reporting bugs in Python and its standard library.  Your submission looks like a request for help.  You are much more likely to get the answer to your question on the python-list mailing list.  Please submit your question there.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18692>
_______________________________________

From report at bugs.python.org  Fri Aug  9 03:59:52 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 09 Aug 2013 01:59:52 +0000
Subject: [issue18693] help() not helpful with enum
Message-ID: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>


New submission from Ethan Furman:

help(), when used on an enum member or class, returns almost nothing.  I suspect the custom __dir__ is at fault, but whatever is causing the problem needs fixing.

----------
assignee: ethan.furman
messages: 194714
nosy: barry, eli.bendersky, ethan.furman
priority: normal
severity: normal
status: open
title: help() not helpful with enum
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Fri Aug  9 04:14:45 2013
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Fri, 09 Aug 2013 02:14:45 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376014485.23.0.439915329713.issue18606@psf.upfronthosting.co.za>


Stephen J. Turnbull added the comment:

A few small comments and nits.

1. I'm with the author on the question of a sum function in this module.  The arguments that builtin sum isn't accurate enough, and neither is math.fsum for cases where all data is of infinite precision, are enough for me.

2. A general percentile function should be high on the list of next additions.

A substantive question:

3. Can't add_partial be used in the one-pass algorithms?

Several typos and suggested style tweaks:

4. I would find the summary more readable if grouped by function:
add_partial, sum, StatisticsError; mean, median, mode; pstdev, pvariance, stdev, variance.  Maybe I'd like it better if the utilities came last.  IMO YMMV, of course.

5. In the big comment in add_partial, "the inner loop" is mentioned.  Indeed this is the inner loop in statistics.sum, but there's only one loop in add_partial.

6. In the Limitations section of sum's docstring it says "these limitations may change".  Is "these limitations may be relaxed" what is meant?  I would hope so, but the current phrasing makes me nervous.

7. In sum, there are two comments referring to the construct "type(total).__float__(total)", with the first being a forward reference to the second.  I would find a single comment above the "isinstance(total, float)" test more readable.  Eg,

"""
First, accumulate a non-float sum. Until we find a float, we keep adding.
If we find a float, we exit this loop, convert the partial sum to float, and continue with the float code below. Non-floats are converted to float with 'type(x).__float__(x)'. Don't call float() directly, as that converts strings and we don't want that. Also, like all dunder methods, we should call __float__ on the class, not the instance.
"""

8. The docstrings for mean and variance say they are unbiased.  This depends on the strong assumption of a representative (typically i.i.d.) sample.  I think this should be mentioned.

9. Several docstrings say "this function should be used when ...".  In fact the choice of which function to use is somewhat delicate.  My personal preference would be to use "may" rather than "should."

10. In several of the mode functions, the value is a sorted sequence.  The sort key should be specified, because it could be the data value or the score.

----------
nosy: +sjt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Fri Aug  9 06:55:33 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 09 Aug 2013 04:55:33 +0000
Subject: [issue18694] getxattr on Linux ZFS native filesystem happily returns
	partial values
Message-ID: <1376024133.74.0.379846700659.issue18694@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The getxattr() system call retrieves an "extended attribute" on a file.  When you call it you pass in a buffer and a size.  The expected behavior is, if you pass in a buffer that's too small, the function returns -1 and sets errno to ERANGE.

On a ZFS filesystem on Linux, using the "ZFS On Linux" port:
    http://zfsonlinux.org/

getxattr() does not behave this way.  Instead, it fills the buffer with the first buffer-size bytes of data (without a zero terminator).

Python's implementation of getxattr() interprets this as success.  Which means that, the way it's implemented, if you call getxattr() to retrieve a value that's > 128 bytes in length, you only get the first 128 bytes.  (Happily, we already have a regression test that finds this!)

Attached is a patch fixing this behavior.  It checks the return value of getxattr() to see if the buffer was filled to 100%.  If so, it retries with a larger buffer.

----------
assignee: larry
components: Library (Lib)
files: larry.setxattr.zfs.patch.1.txt
messages: 194716
nosy: larry
priority: normal
severity: normal
stage: patch review
status: open
title: getxattr on Linux ZFS native filesystem happily returns partial values
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31203/larry.setxattr.zfs.patch.1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18694>
_______________________________________

From report at bugs.python.org  Fri Aug  9 07:20:21 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 09 Aug 2013 05:20:21 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1376025621.48.0.817315675345.issue18693@psf.upfronthosting.co.za>


Ethan Furman added the comment:

With custom __dir__:

Help on class Enum in module enum:

Enum = <enum 'Enum'>

----------------------------------------------------

Without custom __dir__:

Help on class Enum in module enum:

class Enum(builtins.object)
 |  Generic enumeration.
 |  
 |  Derive from this class to define new enumerations.
 |  
 |  Methods defined here:
 |  
 |  __eq__(self, other)
 |  
 |  __getnewargs__(self)
 |  
 |  __hash__(self)
 |  
 |  __repr__(self)
 |  
 |  __str__(self)
 |  
 |  ----------------------------------------------------------------------
 |  Static methods defined here:
 |  
 |  __new__(cls, value)
 |  
 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |  
 |  __dict__
 |      dictionary for instance variables (if defined)
 |  
 |  __weakref__
 |      list of weak references to the object (if defined)
 |  
 |  name
 |      Route attribute access on a class to __getattr__.
 |      
 |      This is a descriptor, used to define attributes that act differently when
 |      accessed through an instance and through a class.  Instance access remains
 |      normal, but access to an attribute through a class will be routed to the
 |      class's __getattr__ method; this is done by raising AttributeError.
 |  
 |  value
 |      Route attribute access on a class to __getattr__.
 |      
 |      This is a descriptor, used to define attributes that act differently when
 |      accessed through an instance and through a class.  Instance access remains
 |      normal, but access to an attribute through a class will be routed to the
 |      class's __getattr__ method; this is done by raising AttributeError.

---------------------------------------------------------------

I'm thinking we should drop the custom __dir__.  help() is far more important than not seeing some things with dir().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Fri Aug  9 07:46:00 2013
From: report at bugs.python.org (paul j3)
Date: Fri, 09 Aug 2013 05:46:00 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za>
Message-ID: <1376027160.64.0.562040305176.issue12806@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12806>
_______________________________________

From report at bugs.python.org  Fri Aug  9 08:00:08 2013
From: report at bugs.python.org (paul j3)
Date: Fri, 09 Aug 2013 06:00:08 +0000
Subject: [issue13280] argparse should use the new Formatter class
In-Reply-To: <1319746751.8.0.206945992721.issue13280@psf.upfronthosting.co.za>
Message-ID: <1376028008.1.0.233116752238.issue13280@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13280>
_______________________________________

From report at bugs.python.org  Fri Aug  9 08:26:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 06:26:41 +0000
Subject: [issue18694] getxattr on Linux ZFS native filesystem happily returns
	partial values
In-Reply-To: <1376024133.74.0.379846700659.issue18694@psf.upfronthosting.co.za>
Message-ID: <1376029601.22.0.734839246075.issue18694@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18694>
_______________________________________

From report at bugs.python.org  Fri Aug  9 10:05:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 08:05:37 +0000
Subject: [issue18690] memoryview not considered a sequence
In-Reply-To: <1375994306.09.0.288774044914.issue18690@psf.upfronthosting.co.za>
Message-ID: <1376035537.39.0.47777178112.issue18690@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +mark.dickinson, skrah
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18690>
_______________________________________

From report at bugs.python.org  Fri Aug  9 10:08:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 08:08:50 +0000
Subject: [issue18685] Restore re performance to pre-PEP393 level
In-Reply-To: <1375967417.95.0.0303828296889.issue18685@psf.upfronthosting.co.za>
Message-ID: <1376035730.81.0.0889458567201.issue18685@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18685>
_______________________________________

From report at bugs.python.org  Fri Aug  9 10:13:05 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Aug 2013 08:13:05 +0000
Subject: [issue18226] IDLE Unit test for FormatParagrah.py
In-Reply-To: <1371335636.99.0.534048602964.issue18226@psf.upfronthosting.co.za>
Message-ID: <1376035985.5.0.849904624971.issue18226@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I got rid of the shutdown warning by replacing EditorWindow with a simple mock, as explained in the test file. Doing so also reduced the running time from about .40 seconds to .25 (it was 1.0+ before I reduced the redundancy of the tests). All the asserts passed after the substitution except for the last. For some reason, the 2nd line of the comment block looses its \n so that lines 2 and 3 get pasted together. I am baffled since the block is almost the same as the previous one. For the moment, I just commented out that test.

----------
Added file: http://bugs.python.org/file31204/18226FormatPara9.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18226>
_______________________________________

From report at bugs.python.org  Fri Aug  9 11:13:56 2013
From: report at bugs.python.org (Michael Foord)
Date: Fri, 09 Aug 2013 09:13:56 +0000
Subject: [issue18381] unittest warnings counter
In-Reply-To: <1373114259.86.0.274298241842.issue18381@psf.upfronthosting.co.za>
Message-ID: <1376039636.9.0.322035955112.issue18381@psf.upfronthosting.co.za>


Michael Foord added the comment:

Looks good to me, except the backslash continuation is unneeded. Needs documentation.

----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18381>
_______________________________________

From report at bugs.python.org  Fri Aug  9 11:20:54 2013
From: report at bugs.python.org (Michael Foord)
Date: Fri, 09 Aug 2013 09:20:54 +0000
Subject: [issue17974] Migrate unittest to argparse
In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za>
Message-ID: <1376040054.53.0.429947437954.issue17974@psf.upfronthosting.co.za>


Michael Foord added the comment:

The patch looks like an improvement. Does it maintain the ability to pass the discovery arguments positionally and by keyword? If so then it can go in. I like the improved error reporting for nonsenical input to unittest.main.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17974>
_______________________________________

From report at bugs.python.org  Fri Aug  9 12:00:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Aug 2013 10:00:22 +0000
Subject: [issue17974] Migrate unittest to argparse
In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za>
Message-ID: <1376042422.14.0.401889896806.issue17974@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Does it maintain the ability to pass the discovery arguments positionally and by keyword?

Yes, of course. Only such command line are not supported more:

    ./python Lib/test/test_colorsys.py discover -v Lib/test/test_json/

or

    ./python -m test.test_colorsys discover -v Lib/test/test_json/

But this looks as an unintentional and senseless ability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17974>
_______________________________________

From report at bugs.python.org  Fri Aug  9 12:15:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 10:15:21 +0000
Subject: [issue18688] Document undocumented Unicode object API
In-Reply-To: <1375989166.23.0.200448183394.issue18688@psf.upfronthosting.co.za>
Message-ID: <1376043321.87.0.0905674089188.issue18688@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18688>
_______________________________________

From report at bugs.python.org  Fri Aug  9 12:15:57 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 10:15:57 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376043357.67.0.717254618007.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Here is a patch that cleans up the current implementation to avoid making the result of iterparse() an IncrementalParser (with all of its new API).

Please note that the tulip mailing list is not an appropriate place to discuss additions to the XML libraries, and ElementTree in particular.

----------
nosy: +scoder
Added file: http://bugs.python.org/file31205/iterparse_cleanup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 12:19:11 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 10:19:11 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376043551.33.0.379952111084.issue17741@psf.upfronthosting.co.za>


Changes by Stefan Behnel <scoder at users.sourceforge.net>:


----------
components: +XML

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 13:14:59 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 11:14:59 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376046899.82.0.859432304326.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Copying the discussion between Antoine and me from python-dev:

>> IMO it should mimic the interface of the TreeBuilder, which
>> calls the data reception method "feed()" and the termination method
>> "close()". There is no reason to add yet another set of methods names
>> just to do what others do already.
>
> Well, the difference here is that after calling eof_received() you can
> still (and should) call events() once to get the last events. I think
> it would be weird if you could still do something useful with the object
> after calling close().
>
> Also, the method names are not invented, they mimick the PEP 3156
> stream protocols:
> http://www.python.org/dev/peps/pep-3156/#stream-protocols

I see your point about close(). I assume your reasoning was to make the IncrementalParser an arbitrary stream end-point. However, it doesn't really make all that much sense to connect an arbitrary data source to it, as the source wouldn't know that, in addition to passing in data, it would also have to ask for events from time to time. I mean, you could do it, but then it would just fill up the memory with parser events and loose the actual advantages of incremental parsing. So, in a way, the whole point of the class is to *not* be an arbitrary stream end-point.

Anyway, given that there isn't really the One Obvious Way to do it, maybe you should just add a docstring to the class (ahem), reference the stream protocol as the base for its API, and then rename it to IncrementalStreamParser. That would at least make it clear why it doesn't really fit with the rest of the module API (which was designed some decade before PEP 3156) and instead uses its own naming scheme.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 13:32:06 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 11:32:06 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376047926.53.0.437156420144.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Actually, let me take that last paragraph back. There is an Obvious Way to do it, and that's the feed() and close() methods. They are the existing and established ElementTree interface for incremental parsing. The fact that close() doesn't clean up all state is IMHO a minor issue. The state will be cleaned up automatically once the iteration terminates, and that's the normal behaviour of iterators. So it actually fits both protocols quite nicely.

I'd just leave the stream protocol out completely here. For one, the implementation isn't complete anyway (the connection_*() methods don't make much sense), and as I said, it's not very useful to consider the parser a general end-point to that protocol.

I'd also suggest returning the iterator over the remaining events from close(), just like the TreeBuilder returns the tree. That covers the (less common) use case of first parsing everything and then processing the events. I'll add another patch that does that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 13:42:32 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 11:42:32 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376048552.74.0.284728361834.issue17741@psf.upfronthosting.co.za>


Changes by Stefan Behnel <scoder at users.sourceforge.net>:


Added file: http://bugs.python.org/file31206/iterparse_api_cleanup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 13:49:56 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Fri, 09 Aug 2013 11:49:56 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1376014485.23.0.439915329713.issue18606@psf.upfronthosting.co.za>
Message-ID: <CAHVvXxRQvmJUwY5EtzfxZt=O6oyHMOEDbHQLmpVVGAkh+poG_g@mail.gmail.com>


Oscar Benjamin added the comment:

One small point:

I think that the argument `m` to variance, pvariance, stdev and pstdev
should be renamed to `mu` for pvariance/pstdev and `xbar` for
variance/stdev. The doc-strings should carefully distinguish that `mu`
is the true/population mean and `xbar` is the estimated/sample mean
and refer to this difference between the function variants.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Fri Aug  9 14:06:43 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 09 Aug 2013 12:06:43 +0000
Subject: [issue18695] os.statvfs() not working well with unicode paths
Message-ID: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

From: https://code.google.com/p/psutil/issues/detail?id=416


# -*- coding: utf-8 -*-
from __future__ import unicode_literals
import os, errno
name = "???"
try:
    os.mkdir(name)
except OSError as err:
    if err.errno != errno.EEXIST:
        raise
os.statvfs(name)


The script above works fine on Python 3.3 but on 2.7 you'll get:

Traceback (most recent call last):
  File "foo.py", line 10, in <module>
    os.statvfs(name)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128)

Patch in attachment fixes the issue.

----------
components: Unicode
files: statvfs.patch
keywords: needs review, patch
messages: 194726
nosy: ezio.melotti, giampaolo.rodola
priority: normal
severity: normal
status: open
title: os.statvfs() not working well with unicode paths
versions: Python 2.7
Added file: http://bugs.python.org/file31207/statvfs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18695>
_______________________________________

From report at bugs.python.org  Fri Aug  9 15:29:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 13:29:51 +0000
Subject: [issue18685] Restore re performance to pre-PEP393 level
In-Reply-To: <1375967417.95.0.0303828296889.issue18685@psf.upfronthosting.co.za>
Message-ID: <1376054991.87.0.578167661245.issue18685@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I get the same kind of results as Serhiy:

$ python3.2 -m timeit -s "import re; f = re.compile(b'abc').search; x = b'x'*100000"  "f(x)"
10000 loops, best of 3: 81.7 usec per loop
$ python3.2 -m timeit -s "import re; f = re.compile('abc').search; x = 'x'*100000"  "f(x)"
10000 loops, best of 3: 31.1 usec per loop
$ python3.2 -m timeit -s "import re; f = re.compile('abc').search; x = '\u20ac'*100000"  "f(x)"
10000 loops, best of 3: 31.1 usec per loop

Unpatched 3.4:

$ ./python -m timeit -s "import re; f = re.compile(b'abc').search; x = b'x'*100000"  "f(x)"
10000 loops, best of 3: 81.6 usec per loop
$ ./python -m timeit -s "import re; f = re.compile('abc').search; x = 'x'*100000"  "f(x)"
10000 loops, best of 3: 163 usec per loop
$ ./python -m timeit -s "import re; f = re.compile('abc').search; x = '\u20ac'*100000"  "f(x)"
10000 loops, best of 3: 190 usec per loop

Patched 3.4:

$ ./python -m timeit -s "import re; f = re.compile(b'abc').search; x = b'x'*100000"  "f(x)"
10000 loops, best of 3: 54.4 usec per loop
$ ./python -m timeit -s "import re; f = re.compile('abc').search; x = 'x'*100000"  "f(x)"
10000 loops, best of 3: 54.2 usec per loop
$ ./python -m timeit -s "import re; f = re.compile('abc').search; x = '\u20ac'*100000"  "f(x)"
10000 loops, best of 3: 54.5 usec per loop

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18685>
_______________________________________

From report at bugs.python.org  Fri Aug  9 15:37:30 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 13:37:30 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376055450.49.0.222553897675.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Thinking about the original patch some more - I wonder why it doesn't use a wrapper for TreeBuilder to process the events. Antoine, is there a reason why you had to add this _setevents() method to the XMLParser, instead of making the IncrementalParser an IncrementalTreeBuilder?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 15:38:00 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 13:38:00 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376055480.34.0.437894235036.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Oh, and could we reopen this ticket, please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 15:51:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 13:51:04 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376056264.77.0.713332650019.issue17741@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Antoine, is there a reason why you had to add this _setevents() method
> to the XMLParser, instead of making the IncrementalParser an
> IncrementalTreeBuilder?

The point is not to build a tree of potentially unbounded size (think XMPP). The point is to yield events in a non-blocking way (iterparse() is blocking, which makes it useless for non-blocking applications).

An IncrementalTreeBuilder wouldn't have much point IMO. It is not more costly to accumulate a string and parse it at the end, than to progressively build a growing XML tree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 15:53:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 13:53:04 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376056384.34.0.181910595799.issue17741@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

About the patch: I think changing the API names now that alpha1 has been released is a bit gratuitous. I would like to keep the encapsulation part but ditch the naming changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 15:53:09 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 13:53:09 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376056389.67.0.440461905868.issue17741@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 16:09:38 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 14:09:38 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376057378.36.0.0473196005399.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> The point is not to build a tree of potentially unbounded size (think
> XMPP). The point is to yield events in a non-blocking way (iterparse()
> is blocking, which makes it useless for non-blocking applications).

Ok, but that's the only difference. Instead of getting the events from the parser, you could equally well get them from the TreeBuilder, also in a non-blocking way.

Sticking this functionality into a parser target object has the advantage that the parser interface wouldn't have to change. So, instead of introducing an entirely new parser interface, we'd just add a class that can be used as a parser target and provides an additional events() method. That's a substantially less invasive API change.


> An IncrementalTreeBuilder wouldn't have much point IMO. It is not more
> costly to accumulate a string and parse it at the end, than to
> progressively build a growing XML tree.

I don't think I understand what you mean.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 16:14:59 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 14:14:59 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376057699.89.0.787943109483.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> About the patch: I think changing the API names now that alpha1 has been
> released is a bit gratuitous.

Sorry for being late, but I can't see it being my fault.

A change in an alpha release is still way better than a change after a final release. Eventually, lxml will have to go on par here, so it's better to get it right now, before any harm is done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 16:28:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 14:28:22 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1376057378.36.0.0473196005399.issue17741@psf.upfronthosting.co.za>
Message-ID: <972158677.52888499.1376058495831.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> > The point is not to build a tree of potentially unbounded size
> > (think
> > XMPP). The point is to yield events in a non-blocking way
> > (iterparse()
> > is blocking, which makes it useless for non-blocking applications).
> 
> Ok, but that's the only difference. Instead of getting the events
> from the parser, you could equally well get them from the
> TreeBuilder, also in a non-blocking way.

But your TreeBuilder is also growing a tree internally, and therefore
eating more and more memory, right?

I don't see the point of stuffing different kinds of functionality
inside a single class. It makes the intended use less obvious, and
errors more likely. Right now, IncrementalParser has a simple API,
and there's a single way to use it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 16:31:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 14:31:21 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1376057699.89.0.787943109483.issue17741@psf.upfronthosting.co.za>
Message-ID: <457156165.52894501.1376058675842.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> A change in an alpha release is still way better than a change after
> a final release.

But worse than no change at all. Arguing about API naming is a bit futile,
*especially* when the ship has sailed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 16:32:34 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 14:32:34 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376058754.42.0.478779296961.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

But IncrementalParser uses an XMLParser internally, which in turn uses a TreeBuilder internally. So what exactly is your point?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 16:44:15 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 14:44:15 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376059455.74.0.132545766525.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> But worse than no change at all. Arguing about API naming is a bit
> futile, *especially* when the ship has sailed.

<rant>It's easy to say that as a core developer with commit rights who can simply hide changes in a low frequented bug tracker without notifying those who have to know about these changes.</rant> It's pure luck I noticed this change during the alpha release cycle.

I'm also not arguing about naming. I'm questioning the design, trying to get it into a shape that fits the existing APIs. Why do we need two incremental parsing interfaces in one and the same library that use completely different method names, although doing otherwise exactly the same? Why should the type of the *result* of the parsing process change the method name that you need to call to *insert* data into the parser?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 16:47:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 14:47:06 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1376058754.42.0.478779296961.issue17741@psf.upfronthosting.co.za>
Message-ID: <282093699.52926475.1376059619980.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> But IncrementalParser uses an XMLParser internally, which in turn
> uses a TreeBuilder internally. So what exactly is your point?

Well, I would rather like to understand yours. Whatever
IncrementalParser uses internally needn't impact what API it
exposes to the user.

(as a matter of fact, iterparse() doesn't expose a
TreeBuilder-like API, either)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 16:59:46 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 14:59:46 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376060386.37.0.514540235802.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> Well, I would rather like to understand yours.

My point is that the IncrementalParser uses a TreeBuilder that builds an XML tree in the back. So I'm wondering why you are saying that it doesn't build a tree.


> Whatever IncrementalParser uses internally needn't impact what API it
> exposes to the user.

And in fact, we don't even need an IncrementalParser, because XMLParser already *has* an incremental parsing interface. All that's missing is the bit that collects and exposes the events. And my point is that we shouldn't duplicate the existing *data entry* interface for that, especially not under different names for identical functionality, but only add an interface to access those events as *output*, i.e. to add the bit of the API that's actually missing.

As an analogon, what would you say if I asked for adding a new, separate Mapping interface to Python that uses the method name "set_value()" instead of "__setitem__()" because I want it to read data from the hard drive and not from memory?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 17:02:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 15:02:41 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1376059455.74.0.132545766525.issue17741@psf.upfronthosting.co.za>
Message-ID: <372273031.52962415.1376060554943.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> <rant>It's easy to say that as a core developer with commit rights
> who can simply hide changes in a low frequented bug tracker without
> notifying those who have to know about these changes.</rant> It's
> pure luck I noticed this change during the alpha release cycle.

It is the rule for most stdlib improvements that they go directly
through the bug tracker. Most core developers and outsiders
would feel swamped by the traffic if all feature additions went
through the mailing-list.

I'm honestly baffled that you think I am trying to "hide" things.
Why do you think I would feel guilty about proposing an addition,
or try to sneak things inside xml.etree?

(yes, we could theoretically run polls for every addition
we propose, collect and discuss the results, and iterate several
times until the outcome is successful; I don't think any of us
has the bandwidth to do that, which is why that practice is
only used for game-making changes (i.e. PEP material))

> I'm also not arguing about naming. I'm questioning the design, trying
> to get it into a shape that fits the existing APIs. Why do we need
> two incremental parsing interfaces in one and the same library that
> use completely different method names, although doing otherwise
> exactly the same?

Well, unless I'm missing something, TreeBuilder doesn't do parsing,
it takes already parsed data: it has a start() method to open a tag,
and a data() method to add raw text inside that tag. IncrementalParser,
OTOH, has a data_received() method to which you pass a piece of
non-parsed XML string.

The other incremental parsing API is actually iterparse(). The
reason I proposed IncrementalParser is that iterparse() is useless
for non-blocking applications. IncrementalParser produces the same
kind of output as iterparse(), but control of when to feed it data
is transferred to the user of the API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 17:12:46 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 15:12:46 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376061166.65.0.0323609506511.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> TreeBuilder doesn't do parsing, it takes already parsed data: it has a
> start() method to open a tag, and a data() method to add raw text
> inside that tag.

That is correct. However, the XMLParser has a feed() method that sends new data into the parser, and a close() method that tells the parser that it's done. So there already is an incremental parsing interface, and your change is duplicating that interface under a different name. Specifically, IncrementalParser has exactly the same interface as XMLParser when it comes to entering data, but uses different method names for it. This is a Bad Design because it introduces an unnecessary inconsistency in the API.

However, what you are trying to change is not the way data is *entered* into the parser. What you are after is to change the way the *parsed* data is *presented* to the user. That is not the responsibility of the parser, it's the responsibility of the TreeBuilder.

In your code, the TreeBuilder builds a tree, and the new interface *additionally* collects parse events in a list. So, the right way to do it would be to change the parser *target* to do both, i.e. to build a tree and collect events at the same time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 17:14:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 15:14:39 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1376060386.37.0.514540235802.issue17741@psf.upfronthosting.co.za>
Message-ID: <2009715590.52992769.1376061273289.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> > Well, I would rather like to understand yours.
> 
> My point is that the IncrementalParser uses a TreeBuilder that builds
> an XML tree in the back. So I'm wondering why you are saying that it
> doesn't build a tree.

Unless I'm reading it wrong, when _setevents() is called, the internal
hooks are rewired to populate the events list, rather than call the
corresponding TreeBuilder methods. So, yes, there's a TreeBuilder
somewhere, but it stands unused.

(the _setevents() method already existed on the C impl, by the way.
I added it to the Python impl to make things more regular and avoid
two separate iterparse() implementations)

> And my
> point is that we shouldn't duplicate the existing *data entry*
> interface for that, especially not under different names for
> identical functionality, but only add an interface to access those
> events as *output*, i.e. to add the bit of the API that's actually
> missing.

What difference would that make? In the end, you mustn't mix
event-driven/non-blocking and cumulative/blocking styles of
programming, so having two separate APIs doesn't strike me as
a problem (it may be a good thing actually, for clarity reasons).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 17:30:35 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 15:30:35 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376062235.29.0.365491025686.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> Unless I'm reading it wrong, when _setevents() is called, the internal
> hooks are rewired to populate the events list, rather than call the
> corresponding TreeBuilder methods. So, yes, there's a TreeBuilder
> somewhere, but it stands unused.

Yes, you *are* reading it wrong. For example, the "start" callback calls self._start_list, which in turn calls self.target.start(), thus calling into the TreeBuilder. That's the thing that constructs the elements that the IncrementalParser collects in its events list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 17:41:39 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 09 Aug 2013 15:41:39 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376062899.38.0.537351470883.issue17741@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

> <rant>It's easy to say that as a core developer with commit rights who > can simply hide changes in a low frequented bug tracker without
> notifying those who have to know about these changes.</rant> It's pure > luck I noticed this change during the alpha release cycle.

What *are* you talking about? Who is trying to hide anything? Don't you see the history of the bug? Antoine opened it very... openly... and we discussed it. Also, committing to pre-alpha trunk is not a sailed ship - if there are problems, things can be easily fixed.

Please stop complaining and learn to use the tools properly. Here's one tip: http://mail.python.org/mailman/listinfo/python-bugs-list - subscribe to it and use your mail client's filtering to see new bugs on topics that interest you. It isn't very hard.

Another tip: http://mail.python.org/mailman/listinfo/python-checkins - subscribe to it and use your mail client's filtering to see new checkins on topics that interest you. It isn't hard either.

Tip #3: ask to be added to the experts list for ET. No one would object to that, and it would increase the likelihood that people add you to the nosy list directly for ET-related issues (particularly added features).

Now back to a productive discussion please...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 17:44:46 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 15:44:46 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376063086.8.0.903716260503.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> ask to be added to the experts list for ET

Already done, see the corresponding python-dev thread.


> Now back to a productive discussion please...

I think we already are. Keep reading through the rest of the posts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 17:51:32 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 09 Aug 2013 15:51:32 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1376063086.8.0.903716260503.issue17741@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda-y6y_ExP4O7hCBTsjy_R15tQXTPhy5MaPNDtEkKN_6Tg@mail.gmail.com>


Eli Bendersky added the comment:

On Fri, Aug 9, 2013 at 8:44 AM, Stefan Behnel <report at bugs.python.org>wrote:

>
> Stefan Behnel added the comment:
>
> > ask to be added to the experts list for ET
>
> Already done, see the corresponding python-dev thread.
>

Done. 747970502b23

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 17:53:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 15:53:23 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1376062235.29.0.365491025686.issue17741@psf.upfronthosting.co.za>
Message-ID: <94532443.53068424.1376063596900.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> > Unless I'm reading it wrong, when _setevents() is called, the
> > internal
> > hooks are rewired to populate the events list, rather than call the
> > corresponding TreeBuilder methods. So, yes, there's a TreeBuilder
> > somewhere, but it stands unused.
> 
> Yes, you *are* reading it wrong. For example, the "start" callback
> calls self._start_list, which in turn calls self.target.start(),
> thus calling into the TreeBuilder. That's the thing that constructs
> the elements that the IncrementalParser collects in its events list.

Ah, indeed, my bad. That said, using a custom TreeBuilder-alike
would necessitate changes in the C implementation of XMLParser.
(which, I suppose, is why the _setevents hack exists in the first
place)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 17:58:07 2013
From: report at bugs.python.org (py.user)
Date: Fri, 09 Aug 2013 15:58:07 +0000
Subject: [issue18696] In unittest.TestCase.longMessage doc remove a redundant
	sentence
Message-ID: <1376063887.45.0.331340035557.issue18696@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/library/unittest.html#unittest.TestCase.longMessage
"If set to True then any explicit failure message you pass in to the assert methods will be appended to the end of the normal failure message. The normal messages contain useful information about the objects involved, for example the message from assertEqual shows you the repr of the two unequal objects. Setting this attribute to True allows you to have a custom error message in addition to the normal one."

the last sentence duplicates the first one

----------
assignee: docs at python
components: Documentation
files: issue.diff
keywords: patch
messages: 194748
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In unittest.TestCase.longMessage doc remove a redundant sentence
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31208/issue.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18696>
_______________________________________

From report at bugs.python.org  Fri Aug  9 18:04:49 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 09 Aug 2013 16:04:49 +0000
Subject: [issue18685] Restore re performance to pre-PEP393 level
In-Reply-To: <1375967417.95.0.0303828296889.issue18685@psf.upfronthosting.co.za>
Message-ID: <1376064289.16.0.296497184809.issue18685@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

@Antoine: Are you on the same OS as Serhiy?

IIRC, wasn't the performance regression that wxjmfauth complained about in Python 3.3 apparent on Windows, but not on Linux?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18685>
_______________________________________

From report at bugs.python.org  Fri Aug  9 18:05:48 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Aug 2013 16:05:48 +0000
Subject: [issue18696] In unittest.TestCase.longMessage doc remove a redundant
	sentence
In-Reply-To: <1376063887.45.0.331340035557.issue18696@psf.upfronthosting.co.za>
Message-ID: <1376064348.73.0.0952617680905.issue18696@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think the text is OK as it stands.  The first sentence is a technical description of the result of setting the attribute, the last sentence is a conceptual discussion of why you would want to set the attribute.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18696>
_______________________________________

From report at bugs.python.org  Fri Aug  9 18:28:52 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Aug 2013 16:28:52 +0000
Subject: [issue18670] Using read_mime_types function from mimetypes module
	gives resource warning
In-Reply-To: <1375803104.23.0.740839065527.issue18670@psf.upfronthosting.co.za>
Message-ID: <1376065732.37.0.0690746767916.issue18670@psf.upfronthosting.co.za>


R. David Murray added the comment:

Since the TESTFN file is created only in this test, rather than use a tearDown method, it would be better to use addCleanup in the test method itself.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18670>
_______________________________________

From report at bugs.python.org  Fri Aug  9 18:52:25 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 16:52:25 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376067145.12.0.789836502463.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Ok, finally. ;)

Can we agree on discarding the current implementation for now and then rewriting it based on a tree builder instead of a parser wrapper?

"Because we'd need to change internal code" is not a good argument for adding a new API, IMHO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 19:46:15 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Aug 2013 17:46:15 +0000
Subject: [issue18655] GUI apps take long to launch on Windows
In-Reply-To: <1375624154.73.0.44206476328.issue18655@psf.upfronthosting.co.za>
Message-ID: <1376070375.9.0.783763122985.issue18655@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This tracker is for patching CPython, not Windows or 3rd-party C libraries. Ramchandra is right, Python does not display windows. In the cases you mention, this is done by 3-rd party cross-platform graphics libraries interacting with Windows' native graphics system. The fact that you have noticed the slow first launch with all 3 suggests that the problem is generic to Windows and how it initializes dlls that connect to Windows graphics system.

I have the impression that this phenomenon is limited neither to Python nor to gui apps. One 'remedy' used by some apps is to load a 'quickstart' background process as part of startup. But that makes the boot or login process longer.

In the absence of evidence that there is anything specifically wrong and fixable in CPython, I am closing this.

Tim or Brian, if either of you think me mistaken, please re-open.

----------
nosy: +brian.curtin, terry.reedy, tim.golden
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18655>
_______________________________________

From report at bugs.python.org  Fri Aug  9 20:11:54 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Aug 2013 18:11:54 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376071914.4.0.606005764169.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

What about this idea: instead of changing the internal C implementation, we could provide a simple parser target wrapper class (say, "EventBuilder") that the parser would simply recognise with isinstance(). Then it would unpack the wrapped target and configure itself as it currently does. So you'd use it like this:

    target = EventBuilder(TreeBuilder())
    parser = XMLParser(target=target)

    parser.feed(some_xml_data)
    print list(target.events())

I mean, it doesn't really matter if the implementation is a fake, as long as the API is right. And the only API that the EventBuilder has is its events() method that returns the iterator.

The EventBuilder implementation would then be

    class EventBuilder:
        def __init__(self, target=None):
            if target is None:
                target = TreeBuilder()
            self._target = target
            self._events = []

        def events(self):
            # existing code for distructive iteration over self._events goes here
            ...

and the rest would be done by the XMLParser() constructor, i.e. it would register the "_events" list in the expat callbacks. What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 20:48:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Aug 2013 18:48:46 +0000
Subject: [issue18697] Unify arguments names in Unicode object C API
	documentation
Message-ID: <1376074126.58.0.40251146149.issue18697@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In declarations of Unicode object C API functions in Doc/c-api/unicode.rst the first Unicode object argument has different names: "unicode", "str", "u", "s". It will be good to unify these names.

Of course there is no need to change reasonable argument names for such functions as PyUnicode_Concat() or PyUnicode_CopyCharacters().

----------
assignee: docs at python
components: Documentation, Unicode
keywords: easy
messages: 194755
nosy: docs at python, ezio.melotti, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Unify arguments names in Unicode object C API documentation
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18697>
_______________________________________

From report at bugs.python.org  Fri Aug  9 20:50:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Aug 2013 18:50:42 +0000
Subject: [issue18688] Document undocumented Unicode object API
In-Reply-To: <1375989166.23.0.200448183394.issue18688@psf.upfronthosting.co.za>
Message-ID: <1376074242.18.0.238073690862.issue18688@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It will be good first resolve issue18697.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18688>
_______________________________________

From report at bugs.python.org  Fri Aug  9 20:57:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 18:57:15 +0000
Subject: [issue18685] Restore re performance to pre-PEP393 level
In-Reply-To: <1376064289.16.0.296497184809.issue18685@psf.upfronthosting.co.za>
Message-ID: <1376074627.2646.2.camel@fsol>


Antoine Pitrou added the comment:

> @Antoine: Are you on the same OS as Serhiy?

I don't know, I'm under Linux with gcc (on a x86-64 machine) :-)

> IIRC, wasn't the performance regression that wxjmfauth complained
> about in Python 3.3 apparent on Windows, but not on Linux?

I don't know, but I'm not willing to give any attention to something
reported by jmfauth. He's very far in the trollzone, as far as I'm
concerned.

However, if you are under Windows and can give it a try, it would be
nice to have performance numbers for Serhiy's patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18685>
_______________________________________

From report at bugs.python.org  Fri Aug  9 21:34:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 19:34:43 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1376067145.12.0.789836502463.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376076874.2646.25.camel@fsol>


Antoine Pitrou added the comment:

> Can we agree on discarding the current implementation for now and then
> rewriting it based on a tree builder instead of a parser wrapper?

Only if it actually brings something (feature-wise, performance-wise,
maintenance-wise, whatever) that the current implementation doesn't
have.

Otherwise, I'd rather check in the simple inheritance-to-composition
change.

I'm sorry that you noticed this after the alpha. I would have had a
lower threshold for changes if you had manifested when I proposed the
feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 21:52:21 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Aug 2013 19:52:21 +0000
Subject: [issue18600] email.policy doc example passes 'policy' to as_string,
	but that doesn't work
In-Reply-To: <1375197560.98.0.336881142306.issue18600@psf.upfronthosting.co.za>
Message-ID: <1376077941.88.0.83427598485.issue18600@psf.upfronthosting.co.za>


R. David Murray added the comment:

Turns out even with as_string accepting a policy keyword, the example still failed.  It needs to be generating a bytes object, not a string.  Before I even realized that, though, I decided I wanted to add as_bytes (and __bytes__).  So the attached patch does that: adds policy to as_string, and adds new methods as_bytes and __bytes__ to Message.

This patch is only for 3.4.  The 3.3 patch will just delete that part of the policy example, so I'm not going to bother to upload it.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31209/as_string_policy.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18600>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:00:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Aug 2013 20:00:01 +0000
Subject: [issue18685] Restore re performance to pre-PEP393 level
In-Reply-To: <1375967417.95.0.0303828296889.issue18685@psf.upfronthosting.co.za>
Message-ID: <1376078401.87.0.223067099136.issue18685@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18685>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:03:01 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 09 Aug 2013 20:03:01 +0000
Subject: [issue18685] Restore re performance to pre-PEP393 level
In-Reply-To: <1375967417.95.0.0303828296889.issue18685@psf.upfronthosting.co.za>
Message-ID: <1376078581.14.0.745107200042.issue18685@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

With the patch the results are:

C:\Python34\python.exe -m timeit -s "import re; f = re.compile(b'abc').search; x = b'x'*100000" "f(x)" 
10000 loops, best of 3: 113 usec per loop

C:\Python34\python.exe -m timeit -s "import re; f = re.compile('abc').search; x = 'x'*100000" "f(x)" 
10000 loops, best of 3: 113 usec per loop

C:\Python34\python.exe -m timeit -s "import re; f = re.compile('abc').search; x = '\u20ac'*100000" "f(x)" 
10000 loops, best of 3: 113 usec per loop

I'm most impressed! :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18685>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:11:47 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Aug 2013 20:11:47 +0000
Subject: [issue18683] Core dumps on CentOS
In-Reply-To: <1375962081.45.0.433865344111.issue18683@psf.upfronthosting.co.za>
Message-ID: <1376079107.02.0.553519569842.issue18683@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It might be related to #14432. Could you try patch Python with a patch of the issue #14432?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18683>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:11:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Aug 2013 20:11:54 +0000
Subject: [issue18685] Restore re performance to pre-PEP393 level
In-Reply-To: <1375967417.95.0.0303828296889.issue18685@psf.upfronthosting.co.za>
Message-ID: <1376079114.19.0.56593500852.issue18685@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm under 32-bit Linux with gcc 4.6.3.

The above test is only one example for which I expect largest difference. I suppose other tests will show a gain too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18685>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:15:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 20:15:18 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1376079318.4.0.981435866072.issue15301@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The Windows buildbots are broken:


======================================================================
ERROR: test_chown_uid_gid_arguments_must_be_index (test.test_os.MakedirTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\test_os.py", line 875, in test_chown_uid_gid_arguments_must_be_index
    self.assertRaises(TypeError, os.chown, support.TESTFN, value, gid)
AttributeError: 'module' object has no attribute 'chown'

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:17:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Aug 2013 20:17:22 +0000
Subject: [issue18695] os.statvfs() not working well with unicode paths
In-Reply-To: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za>
Message-ID: <1376079442.08.0.758962222074.issue18695@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Functions such as rename(), popen(), mkfifo(), mknod(), etc have the same issue.

----------
nosy: +haypo, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18695>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:17:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Aug 2013 20:17:31 +0000
Subject: [issue18675] Daemon Threads can seg fault
In-Reply-To: <1375867396.76.0.697227657582.issue18675@psf.upfronthosting.co.za>
Message-ID: <1376079451.21.0.948613067875.issue18675@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18675>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:18:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 20:18:26 +0000
Subject: [issue18685] Restore re performance to pre-PEP393 level
In-Reply-To: <1375967417.95.0.0303828296889.issue18685@psf.upfronthosting.co.za>
Message-ID: <1376079506.07.0.434511129898.issue18685@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, here are some results from the benchmarks suite:

Report on Linux fsol 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:17:05 UTC 2013 x86_64 x86_64
Total CPU cores: 4

### regex_effbot ###
Min: 0.058952 -> 0.054367: 1.08x faster
Avg: 0.059060 -> 0.054378: 1.09x faster
Significant (t=132.69)
Stddev: 0.00008 -> 0.00001: 5.9597x smaller

### regex_v8 ###
Min: 0.063401 -> 0.050701: 1.25x faster
Avg: 0.066147 -> 0.053530: 1.24x faster
Significant (t=3.22)
Stddev: 0.00608 -> 0.00630: 1.0363x larger

The following not significant results are hidden, use -v to show them:
regex_compile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18685>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:20:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Aug 2013 20:20:27 +0000
Subject: [issue18600] email.policy doc example passes 'policy' to as_string,
	but that doesn't work
In-Reply-To: <1375197560.98.0.336881142306.issue18600@psf.upfronthosting.co.za>
Message-ID: <3cBd9k57r0z7M26@mail.python.org>


Roundup Robot added the comment:

New changeset 53287858e71f by R David Murray in branch 'default':
#18600: add policy to add_string, and as_bytes and __bytes__ methods.
http://hg.python.org/cpython/rev/53287858e71f

New changeset 8fbaf4e649af by R David Murray in branch '3.3':
#18600: In 3.3, as_string does not accept a policy keyword.
http://hg.python.org/cpython/rev/8fbaf4e649af

New changeset b9a5b7e3b32f by R David Murray in branch 'default':
Null merge related to #18600.
http://hg.python.org/cpython/rev/b9a5b7e3b32f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18600>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:22:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Aug 2013 20:22:20 +0000
Subject: [issue18600] email.policy doc example passes 'policy' to as_string,
	but that doesn't work
In-Reply-To: <1375197560.98.0.336881142306.issue18600@psf.upfronthosting.co.za>
Message-ID: <1376079740.88.0.688916809772.issue18600@psf.upfronthosting.co.za>


R. David Murray added the comment:

Committed with changes pointed out by Antoine (thank you Antoine).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18600>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:23:24 2013
From: report at bugs.python.org (Phil Webster)
Date: Fri, 09 Aug 2013 20:23:24 +0000
Subject: [issue18583] Idle: enhance FormatParagraph
In-Reply-To: <1375065577.4.0.851490009653.issue18583@psf.upfronthosting.co.za>
Message-ID: <1376079804.31.0.481327821316.issue18583@psf.upfronthosting.co.za>


Phil Webster added the comment:

In the case of no selection would it make sense to only format if the cursor is in a string/comment? If not in a string or comment, the single line that the cursor is in could be formatted with a line ending backslash or not at all. Otherwise Format Paragraph will probably just be mangling code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18583>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:25:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Aug 2013 20:25:45 +0000
Subject: [issue18673] Add and use O_TMPFILE for Linux 3.11
In-Reply-To: <1375818220.16.0.883591943761.issue18673@psf.upfronthosting.co.za>
Message-ID: <1376079945.33.0.901354875106.issue18673@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> use O_TEMPFILE in tempfile module when it's supported by the current kernel

How do you detect that a kernel does not support the flag? Try to use the flag and handle the error?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18673>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:28:47 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Aug 2013 20:28:47 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <1375531895.31.0.501848123953.issue18643@psf.upfronthosting.co.za>
Message-ID: <1376080127.27.0.499542223693.issue18643@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:34:08 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 09 Aug 2013 20:34:08 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1376076874.2646.25.camel@fsol>
Message-ID: <CAF-Rda8ec59WxXkaXqmA=Q73nX-qusms09ib4uQ+_puu-ran-Q@mail.gmail.com>


Eli Bendersky added the comment:

On Fri, Aug 9, 2013 at 12:34 PM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou added the comment:
>
> > Can we agree on discarding the current implementation for now and then
> > rewriting it based on a tree builder instead of a parser wrapper?
>
> Only if it actually brings something (feature-wise, performance-wise,
> maintenance-wise, whatever) that the current implementation doesn't
> have.
>
> Otherwise, I'd rather check in the simple inheritance-to-composition
> change.
>
> I'm sorry that you noticed this after the alpha. I would have had a
> lower threshold for changes if you had manifested when I proposed the
> feature.
>

Antoine, I'm not yet very well versed in the release process, but ISTM that
if:

1. We know that a better API can be created
2. The implementation is not overly difficult

It makes sense to do the change even though Alpha 1 was already released.
Alphas are alphas, after all :-) I suppose that we can consult with Larry
and others if this is the only doubt holding the change back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:35:53 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Aug 2013 20:35:53 +0000
Subject: [issue18644] Got ResourceWarning: unclosed file when using test
	function from formatter module
In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za>
Message-ID: <1376080553.11.0.969551660475.issue18644@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Why is the `formatter` module still part of Python 3? This was a dependency for the `htmllib` module in Python 2 only, and that module was deprecated and removed from Python 3."

The formatter module was deprecated? When?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18644>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:38:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Aug 2013 20:38:15 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <CAF-Rda8ec59WxXkaXqmA=Q73nX-qusms09ib4uQ+_puu-ran-Q@mail.gmail.com>
Message-ID: <1376080686.2646.26.camel@fsol>


Antoine Pitrou added the comment:

Le vendredi 09 ao?t 2013 ? 20:34 +0000, Eli Bendersky a ?crit :
> Antoine, I'm not yet very well versed in the release process, but ISTM that
> if:
> 
> 1. We know that a better API can be created
> 2. The implementation is not overly difficult
> 
> It makes sense to do the change even though Alpha 1 was already released.
> Alphas are alphas, after all :-) I suppose that we can consult with Larry
> and others if this is the only doubt holding the change back.

I agree, but this assumes there is a "better API". I would like to see
an API proposal and a patch before I give an opinion :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:45:37 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 09 Aug 2013 20:45:37 +0000
Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0)
	deprecated function "inspect.getargspec()"
In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>
Message-ID: <1376081137.43.0.982230253524.issue8112@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Here's a patch with tests attached.

----------
keywords: +patch
nosy: +Claudiu.Popa
versions: +Python 3.4 -Python 3.1
Added file: http://bugs.python.org/file31210/xmlrpc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8112>
_______________________________________

From report at bugs.python.org  Fri Aug  9 22:47:49 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Aug 2013 20:47:49 +0000
Subject: [issue18695] os.statvfs() not working well with unicode paths
In-Reply-To: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za>
Message-ID: <1376081269.56.0.0691627244361.issue18695@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The script above works fine on Python 3.3 but on 2.7 you'll get: ...

Cool, you now have a good reason to upgrade to Python 3 ;-)

I'm not sure that it's a good idea to invest time on fixing Unicode issues in Python 2, especially in a minor version (Python 2.7.x).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18695>
_______________________________________

From report at bugs.python.org  Sat Aug 10 01:12:10 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Aug 2013 23:12:10 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
	descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1376089930.59.0.986070277439.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Implementation of the PEP 446: non-inheriable file descriptors -> Implementation of the PEP 446: non-inheritable file descriptors

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Sat Aug 10 01:15:38 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Aug 2013 23:15:38 +0000
Subject: [issue4708] os.pipe should return inheritable descriptors (Windows)
In-Reply-To: <1229825725.05.0.791696937909.issue4708@psf.upfronthosting.co.za>
Message-ID: <1376090138.02.0.456987912545.issue4708@psf.upfronthosting.co.za>


STINNER Victor added the comment:

os.pipe() creates non-inheritable pipes on Windows, whereas it creates inheritable pipes on UNIX. IMO the reason is an implementation artifact: os.pipe() calls CreatePipe() on Windows (native API), whereas it calls pipe() on UNIX (POSIX API). The call to CreatePipe() was added in Python in 1994, before the introduction of pipe() in the POSIX API in Windows 98.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4708>
_______________________________________

From report at bugs.python.org  Sat Aug 10 01:27:18 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 09 Aug 2013 23:27:18 +0000
Subject: [issue18698] importlib.reload() does not return the module in
	sys.modules
Message-ID: <1376090838.27.0.832453640234.issue18698@psf.upfronthosting.co.za>


New submission from Eric Snow:

Currently reload() returns the module that loader.load_module() returns, rather than returning the one in sys.modules.  This is different from what happens during normal import.  I would expect reload() to return what's in sys.modules.  Perhaps this got overlooked when we moved reload()?  I haven't had a chance to verify, but I do recall that the switch to importlib-based import in 3.3 exposed a bug where importlib wasn't returning the module in sys.modules during normal import.

----------
components: Library (Lib)
messages: 194776
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
status: open
title: importlib.reload() does not return the module in sys.modules
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18698>
_______________________________________

From report at bugs.python.org  Sat Aug 10 01:48:38 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 09 Aug 2013 23:48:38 +0000
Subject: [issue18699] What is Future.running() for in PEP 3148 /
	concurrent.futures.Future?
Message-ID: <1376092118.24.0.585945689562.issue18699@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

>From glyph (in a particularly snarky mood):

"""
P.S.: I realize that this isn't really within the scope of this message, but as I was reviewing Future's documentation while writing it, I realized what Future.running() does.  Wow.  What a completely pointless bug magnet.  Why does this method even exist?  It seems like the only possible use would be to introduce look-before-you-leap bugs into concurrent code, like 'if not my_future.running(): my_future.cancel()'.  If it were for tracking the state of long-running Future operations for UI purposes or something, then 'my_future.add_start_callback(callback)' would be a much more useful interface, which at least has a hope of being used correctly.  Independently of the rest of stuff in this message, it would be great if that could be deprecated and removed.
"""

Despite the snarkiness, he does have a point.  Perhaps it was copied mindlessly from Java?

----------
components: Library (Lib)
messages: 194777
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: What is Future.running() for in PEP 3148 / concurrent.futures.Future?
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18699>
_______________________________________

From report at bugs.python.org  Sat Aug 10 01:59:55 2013
From: report at bugs.python.org (Madison May)
Date: Fri, 09 Aug 2013 23:59:55 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1373400107.5.0.285657244525.issue18416@psf.upfronthosting.co.za>
Message-ID: <1376092795.97.0.29503460495.issue18416@psf.upfronthosting.co.za>


Madison May added the comment:

I quickly ran the tests with each of the above edits to see what bits of the test suite would break.

With option 1 (edits to PathFinder only):

``1 test failed:
    test_importlib``
 

With option 2 (edits to FileFinder only):

``3 tests failed:
    test_import test_importlib test_support``


With option 3 (edits to PathFinder and FileFinder):

``3 tests failed:
    test_import test_importlib test_support``

So using the cwd as a key in sys.path_importer_cache seems to break fewer tests than using '' as a key does.  Perhaps that counts for something.

In test_importlib, the only test to fail was `test_path_importer_cache_empty_string()`, for rather obvious reasons. 
I haven't spent much time looking at failing tests in test_import and test_support yet, though.


In regard to sys.path_importer_cache behavior -- at first glance, I'd lean toward either:

1) Creating a new entry in sys.path_importer_cache after changing directories and importing a new module (as is the case in option 1).

Key: os.getcwd() => Value: FileFinder(os.getcwd())

2) Keeping the current behavior in sys.path_importer_cache and somehow changing the __file__ attribute a bit further down the line (perhaps in `FileFinder._init_file_attr()` or `FileLoader.get_filename()`).

Key: '.' => Value: FileFinder('.') 

or with a minor tweak for consistency with sys.path:

Key: ''  => Value: FileFinder('.')

Have you given the issue any more thought, Brett?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18416>
_______________________________________

From report at bugs.python.org  Sat Aug 10 03:57:21 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 10 Aug 2013 01:57:21 +0000
Subject: [issue18660] os.read behavior on Linux
In-Reply-To: <1375692451.71.0.0379690285011.issue18660@psf.upfronthosting.co.za>
Message-ID: <1376099841.31.0.69001113674.issue18660@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18660>
_______________________________________

From report at bugs.python.org  Sat Aug 10 03:58:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 01:58:20 +0000
Subject: [issue18699] What is Future.running() for in PEP 3148 /
	concurrent.futures.Future?
In-Reply-To: <1376092118.24.0.585945689562.issue18699@psf.upfronthosting.co.za>
Message-ID: <3cBmgb6Jjpz7M67@mail.python.org>


Roundup Robot added the comment:

New changeset 922c0fe6ebee by Guido van Rossum in branch 'default':
Get rid of Future.running(); see bug 18699.
http://hg.python.org/peps/rev/922c0fe6ebee

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18699>
_______________________________________

From report at bugs.python.org  Sat Aug 10 03:58:25 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 10 Aug 2013 01:58:25 +0000
Subject: [issue18673] Add and use O_TMPFILE for Linux 3.11
In-Reply-To: <1375818220.16.0.883591943761.issue18673@psf.upfronthosting.co.za>
Message-ID: <1376099905.97.0.258487540762.issue18673@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18673>
_______________________________________

From report at bugs.python.org  Sat Aug 10 04:02:03 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 10 Aug 2013 02:02:03 +0000
Subject: [issue18699] What is Future.running() for in PEP 3148 /
	concurrent.futures.Future?
In-Reply-To: <1376092118.24.0.585945689562.issue18699@psf.upfronthosting.co.za>
Message-ID: <1376100123.69.0.915342241991.issue18699@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

(Note that my change to PEP 3156 is somewhat separate -- Tulip's Future doesn't have to follow all of the PEP 3148 API and its running() method did nothing anyway.  But concurrent.futures.Future has been released for several cycles and we must consider the removal of running() there more carefully.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18699>
_______________________________________

From report at bugs.python.org  Sat Aug 10 04:07:25 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 10 Aug 2013 02:07:25 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375266225.61.0.177800626076.issue18606@psf.upfronthosting.co.za>
Message-ID: <5205A055.20003@pearwood.info>


Steven D'Aprano added the comment:

On 31/07/13 20:23, Antoine Pitrou added the comment:
>
> I suppose you should write a PEP for the module inclusion proposal

Done.

http://www.python.org/dev/peps/pep-0450/

I hope to have an updated reference implementation, plus unittests, up later today or tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Sat Aug 10 04:25:56 2013
From: report at bugs.python.org (Madison May)
Date: Sat, 10 Aug 2013 02:25:56 +0000
Subject: [issue18700] test_cgi raises ResourceWarning
Message-ID: <1376101556.78.0.0722365020142.issue18700@psf.upfronthosting.co.za>


New submission from Madison May:

I'm currently running the tests on a 64-bit Ubuntu 13.04 laptop using the default branch of python.

``/home/mmay/cpython/Lib/test/test_cgi.py:276: ResourceWarning: unclosed file <_io.BufferedRandom name=3>``

----------
components: Tests
messages: 194782
nosy: madison.may
priority: normal
severity: normal
status: open
title: test_cgi raises ResourceWarning
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18700>
_______________________________________

From report at bugs.python.org  Sat Aug 10 04:44:24 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 10 Aug 2013 02:44:24 +0000
Subject: [issue18695] os.statvfs() not working well with unicode paths
In-Reply-To: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za>
Message-ID: <1376102664.45.0.890731622872.issue18695@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

> I'm not sure that it's a good idea to invest time on fixing Unicode 
> issues in Python 2, especially in a minor version (Python 2.7.x).

I admit I sort of share the same doubts, but considering 2.7 a "minor python version", especially at this point, would be a mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18695>
_______________________________________

From report at bugs.python.org  Sat Aug 10 06:23:08 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 10 Aug 2013 04:23:08 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376108588.03.0.928431964103.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> I agree, but this assumes there is a "better API". I would like to see
> an API proposal and a patch before I give an opinion :-)

Well, I have already proposed an API throughout this thread, and then given a usage example and an almost complete sketch of the implementation. Please comment.

I really can't accept the current wart for lxml, that's why I'm asking to not have it in ET either. This would be the first time I can remember that ET has a wrong API that lxml won't copy.

I was asking for removal now, because if we can't manage to come up with a new implementation quickly enough and keep the code in, we'll end up with a quirk that we'll have to keep alive basically forever, in addition to whatever clean API we add later. Time's currently running against us. If we back out the current code, definitely before alpha 2, it'll start running for us again. I clearly prefer that situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sat Aug 10 09:22:39 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 10 Aug 2013 07:22:39 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1376119359.66.0.702206873011.issue18647@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Just a side note for 2.7: could I recommend people to be really extra, extra careful when changing what kind of regexps are accepted and what kind of regexps are outright rejected?  I believe the risk of making long-existing and working 2.7 programs suddenly crash on the next 2.7 micro version should *by far* outweight the theoretical advantage of crashing early on sufficiently bogus regexps.

(Fwiw, I believe the same would apply on 3.x too, where rejecting previously-accepted regexps should only be done in a minor version upgrade.)

----------
nosy: +arigo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18647>
_______________________________________

From report at bugs.python.org  Sat Aug 10 09:38:24 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 10 Aug 2013 07:38:24 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1376120304.51.0.341087658749.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I gave the implementation a try and attached an incomplete patch. Some tests are failing.

It turns out that it's not entirely easy to do this. As Antoine noticed, the hack in the C implementation of the TreeBuilder makes it tricky to integrate with other targets, specifically when intercepting events that the tree builder needs . That's a more general bug and it currently gets in the way.

Anyway, here's how it should eventually look like.

----------
Added file: http://bugs.python.org/file31211/iterparse_TreeEventBuilder.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sat Aug 10 10:26:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Aug 2013 08:26:45 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1376123205.2.0.699065843018.issue18647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Serhiy, yup, that regexp is slow, but it does finish - so the engine is doing something to avoid _unbounded_ repetitive matching of an empty string.

Yes, it finish, but it has exponential computation complexity. Increase the length of the string to 21, 22, 30, 100...

There were multiple bug reports about "hanged" regexps which actually had quadratic or exponential computation complexity (see for example issue1662581, issue16430, issue15077, issue15515). In all such cases the regexp can be rewritten to have linear computation complexity. However peoples constantly do such mistakes.

Armin, I totally agree with you.

Note that before b78c321ee9a5 the regexp '(?:.{0,60000}.{0,5535})?' was forbidden while '(?:.{0,60000}.{0,5534})?' and '(?:.{0,60000}.{0,5536})?' were allowed. Existing check allowed false positives.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18647>
_______________________________________

From report at bugs.python.org  Sat Aug 10 11:47:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Aug 2013 09:47:34 +0000
Subject: [issue18695] os.statvfs() not working well with unicode paths
In-Reply-To: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za>
Message-ID: <1376128054.2.0.713018329131.issue18695@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

2.7.x is a minor version, not 2.7. We fixed Unicode issues in Python 2 bugfixes many times.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18695>
_______________________________________

From report at bugs.python.org  Sat Aug 10 12:21:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Aug 2013 10:21:54 +0000
Subject: [issue18701] Remove outdated PY_VERSION_HEX checks
Message-ID: <1376130113.84.0.145821919316.issue18701@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which removes PY_VERSION_HEX checks in Modules/_ctypes/_ctypes.c, Modules/_sre.c, Objects/stringlib/unicodedefs.h and removes the Modules/_sqlite/sqlitecompat.h file.

_sre.c checks support Python versions <2.2, <2.2 or <1.6 which doesn't made sense because the code overall uses Unicode object API available only in Python >=3.3.

unicodedefs.h contains code to support Python <3.0, but stringlib code can't be shared with Python <3.3.

_ctypes.c and sqlitecompat.h contain code to support Python <2.5 which is not supported version.

----------
assignee: serhiy.storchaka
components: Extension Modules, Interpreter Core
files: no_version_checks.patch
keywords: patch
messages: 194789
nosy: amaury.forgeotdarc, belopolsky, benjamin.peterson, ezio.melotti, ghaering, haypo, lemburg, meador.inge, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Remove outdated PY_VERSION_HEX checks
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31212/no_version_checks.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18701>
_______________________________________

From report at bugs.python.org  Sat Aug 10 13:09:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Aug 2013 11:09:27 +0000
Subject: [issue18702] Report skipped tests as skipped
Message-ID: <1376132966.91.0.713996712724.issue18702@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Some tests in Python testsuite are silently skipped if requirements is not satisfied. The proposed patch adds explicit "skipUnless()" and "raise SkipTest()" so that these tests now reported as skipped.

I.e. the code like

    if not condition:
        def test_foo(self):
            ...

is replaced by

    @unittest.skipUnless(condition, "requires foo")
    def test_foo(self):
        ...

and the code like

    def test_foo(self):
        ...
        if not condition:
            return
        ...

is replaced by

    def test_foo(self):
        ...
        if not condition:
            raise unittest.SkipTest("requires foo")
        ...

----------
components: Tests
files: skip_tests.patch
keywords: patch
messages: 194790
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Report skipped tests as skipped
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31213/skip_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18702>
_______________________________________

From report at bugs.python.org  Sat Aug 10 14:55:54 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 10 Aug 2013 12:55:54 +0000
Subject: [issue18268] ElementTree.fromstring non-deterministically gives
	unicode text data
In-Reply-To: <1371676914.3.0.530507394222.issue18268@psf.upfronthosting.co.za>
Message-ID: <1376139354.06.0.0824989472898.issue18268@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18268>
_______________________________________

From report at bugs.python.org  Sat Aug 10 14:58:45 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 12:58:45 +0000
Subject: [issue18668] Properly document setting m_size in PyModuleDef
In-Reply-To: <1375795246.61.0.949649493069.issue18668@psf.upfronthosting.co.za>
Message-ID: <3cC3Kd1yMLz7LmJ@mail.python.org>


Roundup Robot added the comment:

New changeset f55ba27776d4 by Eli Bendersky in branch '3.3':
Issue #18668: Further clarify m_size setting for non-negative values
http://hg.python.org/cpython/rev/f55ba27776d4

New changeset d43435e82e21 by Eli Bendersky in branch 'default':
Issue #18668: Further clarify m_size setting for non-negative values
http://hg.python.org/cpython/rev/d43435e82e21

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18668>
_______________________________________

From report at bugs.python.org  Sat Aug 10 16:09:41 2013
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Sat, 10 Aug 2013 14:09:41 +0000
Subject: [issue18418] Thread.isAlive() sometimes True after fork
In-Reply-To: <1373408030.66.0.77258289483.issue18418@psf.upfronthosting.co.za>
Message-ID: <1376143781.08.0.0834379625357.issue18418@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

Bump.

I think my most recent patch (August 4) addresses all of Charles-Fran?ois's comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18418>
_______________________________________

From report at bugs.python.org  Sat Aug 10 16:31:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Aug 2013 14:31:38 +0000
Subject: [issue17909] Autodetecting JSON encoding
In-Reply-To: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za>
Message-ID: <1376145098.27.0.410773649813.issue17909@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17909>
_______________________________________

From report at bugs.python.org  Sat Aug 10 16:36:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 14:36:27 +0000
Subject: [issue16400] update default PyPI behavior in docs re: listing versions
In-Reply-To: <1352023055.39.0.262942434831.issue16400@psf.upfronthosting.co.za>
Message-ID: <3cC5VM00rBz7LmJ@mail.python.org>


Roundup Robot added the comment:

New changeset dd0d751cc7f1 by Christian Heimes in branch 'default':
Issue #16400: Add command line option for isolated mode.
http://hg.python.org/cpython/rev/dd0d751cc7f1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16400>
_______________________________________

From report at bugs.python.org  Sat Aug 10 16:37:53 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sat, 10 Aug 2013 14:37:53 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1376145473.35.0.538916186144.issue8713@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


Added file: http://bugs.python.org/file31214/c7aa0005f231.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Sat Aug 10 16:38:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 14:38:31 +0000
Subject: [issue16499] CLI option for isolated mode
In-Reply-To: <1353248771.63.0.703024605939.issue16499@psf.upfronthosting.co.za>
Message-ID: <3cC5Xl037Gz7LpB@mail.python.org>


Roundup Robot added the comment:

New changeset 06c39789061e by Christian Heimes in branch 'default':
typo, changeset dd0d751cc7f1 belongs to issue #16499 not issue #16400
http://hg.python.org/cpython/rev/06c39789061e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16499>
_______________________________________

From report at bugs.python.org  Sat Aug 10 16:38:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 14:38:32 +0000
Subject: [issue16400] update default PyPI behavior in docs re: listing versions
In-Reply-To: <1352023055.39.0.262942434831.issue16400@psf.upfronthosting.co.za>
Message-ID: <3cC5Xl5SZZz7LpB@mail.python.org>


Roundup Robot added the comment:

New changeset 06c39789061e by Christian Heimes in branch 'default':
typo, changeset dd0d751cc7f1 belongs to issue #16499 not issue #16400
http://hg.python.org/cpython/rev/06c39789061e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16400>
_______________________________________

From report at bugs.python.org  Sat Aug 10 16:41:16 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sat, 10 Aug 2013 14:41:16 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1376145676.38.0.406627807199.issue8713@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

The forkserver process is now started using _posixsubprocess.fork_exec().  This should fix the order dependent problem mentioned before.

Also the forkserver tests are now reenabled on OSX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Sat Aug 10 16:41:44 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 10 Aug 2013 14:41:44 +0000
Subject: [issue16499] CLI option for isolated mode
In-Reply-To: <1353248771.63.0.703024605939.issue16499@psf.upfronthosting.co.za>
Message-ID: <1376145704.56.0.406653253946.issue16499@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16499>
_______________________________________

From report at bugs.python.org  Sat Aug 10 16:59:02 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Aug 2013 14:59:02 +0000
Subject: [issue18504] IDLE:Improvements- Improving Mock_Text
In-Reply-To: <1374238852.66.0.963662486602.issue18504@psf.upfronthosting.co.za>
Message-ID: <1376146742.94.0.813412200349.issue18504@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18504>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:01:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 15:01:21 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za>
Message-ID: <3cC6345F2dzNQC@mail.python.org>


Roundup Robot added the comment:

New changeset 8a060e2de608 by Eli Bendersky in branch 'default':
Issue #15651: PEP 3121 refactoring for _elementtree
http://hg.python.org/cpython/rev/8a060e2de608

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:07:26 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 10 Aug 2013 15:07:26 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za>
Message-ID: <1376147246.03.0.431690684519.issue15651@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Antoine, I committed your patch (with a bit of comments added), *leaving the module caching in*. This is because removing it breaks the tests, unfortunately. The _elementtree tests are so crooked that they manage to create a situation in which the module under test throws ParseError which is a different class from ET.ParseError. This is "achieved" by multiple invocations of import_fresh_module with various fresh & blocked parameters, and I still haven't fully traced all the problems yet. Since this caching only potentially harms other tests, it's ok to leave in.

A longer term solution to all this will be http://mail.python.org/pipermail/python-dev/2013-August/127766.html - I want to eventually run all "monkey-patch the import environment to simulate some situation" sub-tests of ET in different subprocesses to they are kept independent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:09:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 15:09:12 +0000
Subject: [issue18483] Add hour-24 type of time to test_http2time_formats in
	test_http_cookiejar.py
In-Reply-To: <1374076234.14.0.497135423695.issue18483@psf.upfronthosting.co.za>
Message-ID: <3cC6D73yYPzNcC@mail.python.org>


Roundup Robot added the comment:

New changeset ab8da1936297 by Ezio Melotti in branch '3.3':
#18483: add one more date format in test_http2time_formats.  Patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/ab8da1936297

New changeset 5c3708f23351 by Ezio Melotti in branch 'default':
#18483: merge with 3.3.
http://hg.python.org/cpython/rev/5c3708f23351

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18483>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:10:45 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Aug 2013 15:10:45 +0000
Subject: [issue18483] Add hour-24 type of time to test_http2time_formats in
	test_http_cookiejar.py
In-Reply-To: <1374076234.14.0.497135423695.issue18483@psf.upfronthosting.co.za>
Message-ID: <1376147445.9.0.157574149498.issue18483@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18483>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:21:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 15:21:20 +0000
Subject: [issue18484] No unit test for iso2time function from http.cookiejar
	module
In-Reply-To: <1374079077.48.0.0605853512742.issue18484@psf.upfronthosting.co.za>
Message-ID: <3cC6V75lzHzPKm@mail.python.org>


Roundup Robot added the comment:

New changeset fe5d105eba4b by Ezio Melotti in branch '3.3':
#18484: improve test coverage of http.cookiejar.  Patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/fe5d105eba4b

New changeset 7bf1f8892df5 by Ezio Melotti in branch 'default':
#18484: merge with 3.3.
http://hg.python.org/cpython/rev/7bf1f8892df5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18484>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:22:20 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Aug 2013 15:22:20 +0000
Subject: [issue18484] No unit test for iso2time function from http.cookiejar
	module
In-Reply-To: <1374079077.48.0.0605853512742.issue18484@psf.upfronthosting.co.za>
Message-ID: <1376148140.8.0.652080850392.issue18484@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type:  -> enhancement
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18484>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:23:32 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Aug 2013 15:23:32 +0000
Subject: [issue18466] Spelling mistakes in various code comments.
In-Reply-To: <1373909571.44.0.949892598858.issue18466@psf.upfronthosting.co.za>
Message-ID: <1376148212.63.0.272170445099.issue18466@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18466>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:31:49 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 15:31:49 +0000
Subject: [issue18465] There are unused variables and unused import in
	Lib/test/test_minidom.py
In-Reply-To: <1373904018.67.0.333776446798.issue18465@psf.upfronthosting.co.za>
Message-ID: <3cC6kD3FTCzPdS@mail.python.org>


Roundup Robot added the comment:

New changeset 4daa18b5ad49 by Ezio Melotti in branch '3.3':
#18465: fix unused variables in test_minidom.  Patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/4daa18b5ad49

New changeset 47770b408321 by Ezio Melotti in branch 'default':
#18465: merge with 3.3.
http://hg.python.org/cpython/rev/47770b408321

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18465>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:32:21 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Aug 2013 15:32:21 +0000
Subject: [issue18465] There are unused variables and unused import in
	Lib/test/test_minidom.py
In-Reply-To: <1373904018.67.0.333776446798.issue18465@psf.upfronthosting.co.za>
Message-ID: <1376148741.0.0.52831085058.issue18465@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18465>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:37:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 15:37:56 +0000
Subject: [issue18453] There are unused variables inside DateTimeTestCase class
	in test_xmlrpc.py
In-Reply-To: <1373817539.24.0.0142880431752.issue18453@psf.upfronthosting.co.za>
Message-ID: <3cC6sH5XlMzQHY@mail.python.org>


Roundup Robot added the comment:

New changeset 28c756093a63 by Ezio Melotti in branch '3.3':
#18453: fix unused variables in test_xmlrpc.  Patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/28c756093a63

New changeset 9f7581816890 by Ezio Melotti in branch 'default':
#18453: merge with 3.3.
http://hg.python.org/cpython/rev/9f7581816890

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18453>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:38:22 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Aug 2013 15:38:22 +0000
Subject: [issue18453] There are unused variables inside DateTimeTestCase class
	in test_xmlrpc.py
In-Reply-To: <1373817539.24.0.0142880431752.issue18453@psf.upfronthosting.co.za>
Message-ID: <1376149102.98.0.0264933593766.issue18453@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18453>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:49:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Aug 2013 15:49:25 +0000
Subject: [issue18516] Typos in Lib/email/generator.py and
	Lib/email/architecture.rst
In-Reply-To: <1374375453.94.0.44126763837.issue18516@psf.upfronthosting.co.za>
Message-ID: <1376149765.86.0.856781905886.issue18516@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed in 168f6ac90abf (3.3) and 40ef5ce25d08 (default).
Thanks for the report!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18516>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:51:47 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Aug 2013 15:51:47 +0000
Subject: [issue18512] sys.stdout.write does not allow bytes in Python 3.x
In-Reply-To: <1374287481.36.0.643885131326.issue18512@psf.upfronthosting.co.za>
Message-ID: <1376149907.38.0.210654617958.issue18512@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> You can do
>    sys.stdout.buffer.write(b"hello")

Note that this might not work when sys.stdout has been replaced with something else (e.g. a StringIO).

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18512>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:54:33 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 10 Aug 2013 15:54:33 +0000
Subject: [issue18667] missing HAVE_FCHOWNAT
In-Reply-To: <1375772087.0.0.361755653525.issue18667@psf.upfronthosting.co.za>
Message-ID: <1376150073.12.0.132858321181.issue18667@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Here's a patch for trunk.  It's essentially what salinger wrote, but as a patch file so it works for "review".

I poked around a little to make sure we weren't going to have another baffling situation like fchmodat.  AFAICT, nope, it's fine, it's as simple as the four-line patch before.

----------
Added file: http://bugs.python.org/file31215/larry.have_fchownat.trunk.patch.1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18667>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:55:48 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 10 Aug 2013 15:55:48 +0000
Subject: [issue18667] missing HAVE_FCHOWNAT
In-Reply-To: <1375772087.0.0.361755653525.issue18667@psf.upfronthosting.co.za>
Message-ID: <1376150148.63.0.875863416515.issue18667@psf.upfronthosting.co.za>


Larry Hastings added the comment:

And here's a patch for 3.3.  I should have mentioned--both these patches pass the same tests as an unmodified trunk.  So I think it's just ready to go in.

----------
Added file: http://bugs.python.org/file31216/larry.have_fchownat.3.3.patch.1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18667>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:58:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 15:58:07 +0000
Subject: [issue18505] Duplicate function names in test_email.py
In-Reply-To: <1374250961.33.0.0492824952219.issue18505@psf.upfronthosting.co.za>
Message-ID: <3cC7Jb0ZctzQyZ@mail.python.org>


Roundup Robot added the comment:

New changeset 53d54503fc06 by Ezio Melotti in branch '3.3':
#18505: fix duplicate name and remove duplicate test.  Patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/53d54503fc06

New changeset cb0fba5c7828 by Ezio Melotti in branch 'default':
#18505: merge with 3.3.
http://hg.python.org/cpython/rev/cb0fba5c7828

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18505>
_______________________________________

From report at bugs.python.org  Sat Aug 10 17:58:38 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Aug 2013 15:58:38 +0000
Subject: [issue18505] Duplicate function names in test_email.py
In-Reply-To: <1374250961.33.0.0492824952219.issue18505@psf.upfronthosting.co.za>
Message-ID: <1376150318.09.0.806631125542.issue18505@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18505>
_______________________________________

From report at bugs.python.org  Sat Aug 10 18:01:48 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Aug 2013 16:01:48 +0000
Subject: [issue18696] In unittest.TestCase.longMessage doc remove a redundant
	sentence
In-Reply-To: <1376063887.45.0.331340035557.issue18696@psf.upfronthosting.co.za>
Message-ID: <1376150508.3.0.277946149758.issue18696@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Agreed, closing.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18696>
_______________________________________

From report at bugs.python.org  Sat Aug 10 18:13:12 2013
From: report at bugs.python.org (Tim Golden)
Date: Sat, 10 Aug 2013 16:13:12 +0000
Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, 
	creates wrong mappings
In-Reply-To: <1340813009.36.0.80214060404.issue15207@psf.upfronthosting.co.za>
Message-ID: <1376151192.86.0.933966523267.issue15207@psf.upfronthosting.co.za>


Tim Golden added the comment:

I attach a patch against 3.3; this is substantially Dave Chambers' original patch with a trivial test added and a doc change. This means that HKCR is scanned to determine extensions and these will override anything in the mimetypes db. The doc change highlights the possibility of overriding this by passing files=[].

I can't see an easy solution for this which will suit everyone but I've sat on it waay too long already. The module startup time is increased but, for bugfix releases, I can't see any other solution which won't break compatibility somewhere. 

I'm taking the simplest view which says that: .jpg => image/pjpeg is broken but that the winreg code has been in place for too long to simply back it out altogether.

I'll commit appropriate versions of this within the next day to 2.7, 3.3 and 3.4 unless anyone objects. Please understand: this *is* a compromise; but I don't think there's a perfect solution for this, short of the rethink which mimetypes needs per MALs suggestion or otherwise.

----------
Added file: http://bugs.python.org/file31217/issue15207.33.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15207>
_______________________________________

From report at bugs.python.org  Sat Aug 10 18:15:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 16:15:50 +0000
Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0)
	deprecated function "inspect.getargspec()"
In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>
Message-ID: <3cC7j14zBCzNRD@mail.python.org>


Roundup Robot added the comment:

New changeset bc49e82ee013 by R David Murray in branch '3.3':
#8112: Update the documenting xmlrpc server to use getfullargspec.
http://hg.python.org/cpython/rev/bc49e82ee013

New changeset 69e515209fa9 by R David Murray in branch 'default':
Merge #8112: Update the documenting xmlrpc server to use getfullargspec.
http://hg.python.org/cpython/rev/69e515209fa9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8112>
_______________________________________

From report at bugs.python.org  Sat Aug 10 18:17:29 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 10 Aug 2013 16:17:29 +0000
Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0)
	deprecated function "inspect.getargspec()"
In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>
Message-ID: <1376151449.31.0.683910720918.issue8112@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Claudio.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8112>
_______________________________________

From report at bugs.python.org  Sat Aug 10 18:32:09 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 10 Aug 2013 16:32:09 +0000
Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0)
	deprecated function "inspect.getargspec()"
In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>
Message-ID: <1376152329.53.0.546992417088.issue8112@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
Removed message: http://bugs.python.org/msg194816

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8112>
_______________________________________

From report at bugs.python.org  Sat Aug 10 18:34:01 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 10 Aug 2013 16:34:01 +0000
Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0)
	deprecated function "inspect.getargspec()"
In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za>
Message-ID: <1376152441.5.0.66872947056.issue8112@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Popa.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8112>
_______________________________________

From report at bugs.python.org  Sat Aug 10 18:54:12 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 10 Aug 2013 16:54:12 +0000
Subject: [issue18689] add argument for formatter to logging.Handler and
	subclasses in logging module
In-Reply-To: <1375992937.35.0.58426954587.issue18689@psf.upfronthosting.co.za>
Message-ID: <1376153652.37.0.581450039029.issue18689@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I suggest that the declarative configuration approach of logging.config.dictConfig() be used for configurations which can't be handled by basicConfig().

I don't propose to enhance the Handler API as suggested, as at the very least every handler would need to be changed to accommodate the new kwarg. Also, this isn't going to work for third-party handlers which are out there already, since they won't necessarily recognise a new kwarg.

----------
nosy: +vinay.sajip
resolution:  -> wont fix
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18689>
_______________________________________

From report at bugs.python.org  Sat Aug 10 19:02:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 17:02:44 +0000
Subject: [issue18681] typo in imp.reload
In-Reply-To: <1375932142.75.0.662721125733.issue18681@psf.upfronthosting.co.za>
Message-ID: <3cC8l73KHDzQCy@mail.python.org>


Roundup Robot added the comment:

New changeset 80b65aa2d579 by Ezio Melotti in branch '3.3':
#18681: Fix a NameError in imp.reload() (noticed by Weizhao Li).
http://hg.python.org/cpython/rev/80b65aa2d579

New changeset 6bee7f1061e0 by Ezio Melotti in branch 'default':
#18681: merge with 3.3.
http://hg.python.org/cpython/rev/6bee7f1061e0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18681>
_______________________________________

From report at bugs.python.org  Sat Aug 10 19:03:37 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Aug 2013 17:03:37 +0000
Subject: [issue18681] typo in imp.reload
In-Reply-To: <1375932142.75.0.662721125733.issue18681@psf.upfronthosting.co.za>
Message-ID: <1376154217.75.0.93567141818.issue18681@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18681>
_______________________________________

From report at bugs.python.org  Sat Aug 10 19:18:46 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Aug 2013 17:18:46 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
	iterable)
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1376155126.7.0.344584000367.issue18652@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18652>
_______________________________________

From report at bugs.python.org  Sat Aug 10 19:24:16 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Aug 2013 17:24:16 +0000
Subject: [issue18648] FP Howto and the PEP 8 lambda guildline
In-Reply-To: <1375563496.73.0.458556999556.issue18648@psf.upfronthosting.co.za>
Message-ID: <1376155456.26.0.982070542484.issue18648@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

IMHO that part should not suggest to use lambdas as small functions, so I would drop the example with adder/print_assign and the discussion about lambdas vs defs (the example that uses defs can stay), and keep the rest (from the "reduce" example).

----------
nosy: +ezio.melotti, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18648>
_______________________________________

From report at bugs.python.org  Sat Aug 10 19:31:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Aug 2013 17:31:25 +0000
Subject: [issue18646] Improve tutorial entry on 'Lambda Forms'.
In-Reply-To: <1375562526.59.0.207872880438.issue18646@psf.upfronthosting.co.za>
Message-ID: <1376155885.46.0.323387979522.issue18646@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18646>
_______________________________________

From report at bugs.python.org  Sat Aug 10 19:38:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Aug 2013 17:38:42 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1376147246.03.0.431690684519.issue15651@psf.upfronthosting.co.za>
Message-ID: <1376156314.2570.1.camel@fsol>


Antoine Pitrou added the comment:

> Antoine, I committed your patch (with a bit of comments added),
> *leaving the module caching in*.

Thanks!

> A longer term solution to all this will be
> http://mail.python.org/pipermail/python-dev/2013-August/127766.html -
> I want to eventually run all "monkey-patch the import environment to
> simulate some situation" sub-tests of ET in different subprocesses to
> they are kept independent.

I find it useful that the test suite stresses module unloading or
reloading. There's probably a bug either in ET or in the ET tests. I'm
not saying it's a very important issue of course, but IMHO it would be
better if we don't try to swipe it under the carpet :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Sat Aug 10 19:51:45 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 10 Aug 2013 17:51:45 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1376157105.56.0.178403871169.issue18647@psf.upfronthosting.co.za>


Tim Peters added the comment:

Serhiy, yes, I know the regexp you gave takes exponential time.  But:

1. This appears to have nothing to do with repeated 0-length matches.  I gave you an example of a very similar regexp that also takes exponential time, but never makes any 0-length sub-match.

2. Matthew said that Python's engine is not robust against _unbounded_ repeated matching of an empty sub-match, and so "That's the reason for the up-front check".  I was asking for an example of _that_ behavior.  I still haven't seen one.

My goal here is to understand why we're doing this check at all.  If Python's engine cannot in fact be provoked into an infinite loop, the check has at best very little value, as there are many ways to provoke exponential-time behavior, and the possibility of a repeated 0-length sub-match doesn't appear to have much (if anything) to do with it.

(By the way, exponential-time regexps can't always be rewritten to take linear time, although it takes gimmicks like back references to create examples that are inherently expensive.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18647>
_______________________________________

From report at bugs.python.org  Sat Aug 10 20:01:15 2013
From: report at bugs.python.org (madan ram)
Date: Sat, 10 Aug 2013 18:01:15 +0000
Subject: [issue18703] To change the doc of html/faq/gui.html
Message-ID: <1376157675.52.0.120458668025.issue18703@psf.upfronthosting.co.za>


New submission from madan ram:

"Qt 4.5 upwards is licensed under the LGPL license; also, commercial licenses are available from Nokia."

Since new version of Qt 5 is realsed and Licenced under Digia.

So i am fixing this issue .

i am going to write it as 

PyQt5 is licensed on all platforms under a commercial license and the GPL v3. Your PyQt5 license must be compatible with your Qt license.
If you use the GPL version then your own code must also use a compatible license.

Note:-PyQt5, unlike Qt, is not available under the LGPL.

You can purchase a commercial PyQt5 license here.

----------
assignee: docs at python
components: Documentation
files: gui.rst
messages: 194824
nosy: docs at python, madan.ram
priority: normal
severity: normal
status: open
title: To change the doc of html/faq/gui.html
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31218/gui.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18703>
_______________________________________

From report at bugs.python.org  Sat Aug 10 20:01:27 2013
From: report at bugs.python.org (madan ram)
Date: Sat, 10 Aug 2013 18:01:27 +0000
Subject: [issue18703] To change the doc of html/faq/gui.html
In-Reply-To: <1376157675.52.0.120458668025.issue18703@psf.upfronthosting.co.za>
Message-ID: <1376157687.42.0.154948634141.issue18703@psf.upfronthosting.co.za>


Changes by madan ram <madan_ram at rocketmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18703>
_______________________________________

From report at bugs.python.org  Sat Aug 10 20:29:13 2013
From: report at bugs.python.org (madan ram)
Date: Sat, 10 Aug 2013 18:29:13 +0000
Subject: [issue18703] To change the doc of html/faq/gui.html
In-Reply-To: <1376157675.52.0.120458668025.issue18703@psf.upfronthosting.co.za>
Message-ID: <1376159353.62.0.201822695997.issue18703@psf.upfronthosting.co.za>


Changes by madan ram <madan_ram at rocketmail.com>:


Removed file: http://bugs.python.org/file31218/gui.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18703>
_______________________________________

From report at bugs.python.org  Sat Aug 10 20:29:30 2013
From: report at bugs.python.org (madan ram)
Date: Sat, 10 Aug 2013 18:29:30 +0000
Subject: [issue18703] To change the doc of html/faq/gui.html
In-Reply-To: <1376157675.52.0.120458668025.issue18703@psf.upfronthosting.co.za>
Message-ID: <1376159370.36.0.876348409087.issue18703@psf.upfronthosting.co.za>


Changes by madan ram <madan_ram at rocketmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31219/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18703>
_______________________________________

From report at bugs.python.org  Sat Aug 10 20:34:09 2013
From: report at bugs.python.org (madan ram)
Date: Sat, 10 Aug 2013 18:34:09 +0000
Subject: [issue18703] To change the doc of html/faq/gui.html
In-Reply-To: <1376157675.52.0.120458668025.issue18703@psf.upfronthosting.co.za>
Message-ID: <1376159649.07.0.0302865967814.issue18703@psf.upfronthosting.co.za>


Changes by madan ram <madan_ram at rocketmail.com>:


----------
nosy: +aleax, eric.araujo, ezio.melotti, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18703>
_______________________________________

From report at bugs.python.org  Sat Aug 10 20:39:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Aug 2013 18:39:15 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1376159955.83.0.826341216748.issue18647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> 2. Matthew said that Python's engine is not robust against _unbounded_ repeated matching of an empty sub-match, and so "That's the reason for the up-front check".  I was asking for an example of _that_ behavior.  I still haven't seen one.

Perhaps Matthew did not understand you or you did not understand Matthew. 
For non-greedy repeats this was fixed in issue9669 (thank to Matthew). For greedy repeats this was fixed some time before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18647>
_______________________________________

From report at bugs.python.org  Sat Aug 10 20:43:47 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 10 Aug 2013 18:43:47 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1376160227.27.0.946018128683.issue18647@psf.upfronthosting.co.za>


Tim Peters added the comment:

So does anyone believe this check serves a useful purpose _now_?  Doesn't seem so to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18647>
_______________________________________

From report at bugs.python.org  Sat Aug 10 22:01:14 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Aug 2013 20:01:14 +0000
Subject: [issue18698] importlib.reload() does not return the module in
	sys.modules
In-Reply-To: <1376090838.27.0.832453640234.issue18698@psf.upfronthosting.co.za>
Message-ID: <1376164874.83.0.631928039564.issue18698@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'm sure it's an oversight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18698>
_______________________________________

From report at bugs.python.org  Sat Aug 10 22:01:54 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 20:01:54 +0000
Subject: [issue18264] enum.IntEnum is not compatible with JSON serialisation
In-Reply-To: <1371649541.07.0.776235119954.issue18264@psf.upfronthosting.co.za>
Message-ID: <3cCDjs2y7FzNWy@mail.python.org>


Roundup Robot added the comment:

New changeset ae1a7c420f08 by Ethan Furman in branch 'default':
Close #18264: int- and float-derived enums now converted to int or float.
http://hg.python.org/cpython/rev/ae1a7c420f08

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18264>
_______________________________________

From report at bugs.python.org  Sat Aug 10 22:03:12 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Aug 2013 20:03:12 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1373400107.5.0.285657244525.issue18416@psf.upfronthosting.co.za>
Message-ID: <1376164992.19.0.725374464734.issue18416@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'm currently leaning towards having sys.path_importer_cache store the actual directory name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18416>
_______________________________________

From report at bugs.python.org  Sat Aug 10 22:07:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 20:07:57 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <3cCDrs21XtzQtj@mail.python.org>


Roundup Robot added the comment:

New changeset 5d417257748e by Ethan Furman in branch 'default':
Close #18693: __dir__ removed from Enum; help() now helpful.
http://hg.python.org/cpython/rev/5d417257748e

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Sat Aug 10 22:15:43 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 10 Aug 2013 20:15:43 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1373400107.5.0.285657244525.issue18416@psf.upfronthosting.co.za>
Message-ID: <1376165743.2.0.787854541874.issue18416@psf.upfronthosting.co.za>


Eric Snow added the comment:

> I'm currently leaning towards having sys.path_importer_cache store
> the actual directory name.

Makes sense to me.  It the problem that sys.path will still have '' in it and it may be hard to figure out what it means (and how it maps to sys.path_importer_cache)?

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18416>
_______________________________________

From report at bugs.python.org  Sat Aug 10 22:22:37 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 10 Aug 2013 20:22:37 +0000
Subject: [issue18703] To change the doc of html/faq/gui.html
In-Reply-To: <1376157675.52.0.120458668025.issue18703@psf.upfronthosting.co.za>
Message-ID: <1376166157.74.0.506031961229.issue18703@psf.upfronthosting.co.za>


R. David Murray added the comment:

It seems to me (having checked) that the current language is correct.  The fact that PyQt5 is available under the GPL isn't really relevant to the FAQ as it currently exists (it doesn't mention the GPL anywhere else).  Keep in mind that Python's license is non-GPL.  Adding GPL-licensed product information would be a whole different level of change, I think.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18703>
_______________________________________

From report at bugs.python.org  Sat Aug 10 22:57:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 20:57:27 +0000
Subject: [issue18226] IDLE Unit test for FormatParagrah.py
In-Reply-To: <1371335636.99.0.534048602964.issue18226@psf.upfronthosting.co.za>
Message-ID: <3cCFxz17TRzNxJ@mail.python.org>


Roundup Robot added the comment:

New changeset 453b4f89a2b4 by Terry Jan Reedy in branch '2.7':
Issue #18226: Add docstrings and unittests for idlelib/FormatParagraph.py.
http://hg.python.org/cpython/rev/453b4f89a2b4

New changeset bfdb687ca485 by Terry Jan Reedy in branch '3.3':
Issue #18226: Add docstrings and unittests for idlelib/FormatParagraph.py.
http://hg.python.org/cpython/rev/bfdb687ca485

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18226>
_______________________________________

From report at bugs.python.org  Sat Aug 10 23:08:13 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 10 Aug 2013 21:08:13 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1376168893.55.0.125917265269.issue18693@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Less than two days passed since this issue was opened. No waiting for feedback? No patch? No code review?

Maybe there's another solution? Personally I find dir() often more useful than help(). Maybe help() can be adapted to behave nicely for classes with custom __dir__ and it could be useful elsewhere?

Is this such a burning immediate need that we forego all the usual discussion channels?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Sat Aug 10 23:12:21 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 10 Aug 2013 21:12:21 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1376156314.2570.1.camel@fsol>
Message-ID: <CAF-Rda-V_A11NwPFVJkw92OM34jocfXEKzXro50Fu2S1hDzw3A@mail.gmail.com>


Eli Bendersky added the comment:

On Sat, Aug 10, 2013 at 10:38 AM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou added the comment:
>
> > Antoine, I committed your patch (with a bit of comments added),
> > *leaving the module caching in*.
>
> Thanks!
>
> > A longer term solution to all this will be
> > http://mail.python.org/pipermail/python-dev/2013-August/127766.html -
> > I want to eventually run all "monkey-patch the import environment to
> > simulate some situation" sub-tests of ET in different subprocesses to
> > they are kept independent.
>
> I find it useful that the test suite stresses module unloading or
> reloading. There's probably a bug either in ET or in the ET tests. I'm
> not saying it's a very important issue of course, but IMHO it would be
> better if we don't try to swipe it under the carpet :-)
>

I have no intention swiping things under the carpet. I'll get to the bottom
of this to understand the exact flow that causes this to happen.

But I still think ET tests should be logically separated into subprocesses.
If we want to stress test module unloading and reloading, let's have
specific, targeted tests for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Sat Aug 10 23:24:34 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Aug 2013 21:24:34 +0000
Subject: [issue18226] IDLE Unit test for FormatParagrah.py
In-Reply-To: <1371335636.99.0.534048602964.issue18226@psf.upfronthosting.co.za>
Message-ID: <1376169874.15.0.248052258009.issue18226@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Unless there is a buildbot problem, further enhancements of either file will be part of #18583

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> Idle: enhance FormatParagraph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18226>
_______________________________________

From report at bugs.python.org  Sat Aug 10 23:36:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Aug 2013 21:36:21 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <CAF-Rda-V_A11NwPFVJkw92OM34jocfXEKzXro50Fu2S1hDzw3A@mail.gmail.com>
Message-ID: <1376170573.2591.3.camel@fsol>


Antoine Pitrou added the comment:

> If we want to stress test module unloading and reloading, let's have
> specific, targeted tests for that.

Agreed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Sat Aug 10 23:40:09 2013
From: report at bugs.python.org (Phil Webster)
Date: Sat, 10 Aug 2013 21:40:09 +0000
Subject: [issue18592] IDLE: Unit test for SearchDialogBase.py
In-Reply-To: <1375146770.41.0.774627283078.issue18592@psf.upfronthosting.co.za>
Message-ID: <1376170809.86.0.240460879363.issue18592@psf.upfronthosting.co.za>


Phil Webster added the comment:

As suggested by Ezio, I factored out the button tests to a common method.

----------
Added file: http://bugs.python.org/file31220/test_searchdialogbase2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18592>
_______________________________________

From report at bugs.python.org  Sat Aug 10 23:47:11 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 21:47:11 +0000
Subject: [issue18429] IDLE: Format Paragraph doesn't function with comment
	blocks
In-Reply-To: <1373565372.76.0.397397850212.issue18429@psf.upfronthosting.co.za>
Message-ID: <3cCH3L1XsgzPGX@mail.python.org>


Roundup Robot added the comment:

New changeset 841984e96df6 by Terry Jan Reedy in branch '2.7':
Issue #18429: Add user-oriented News entry about Format / Format Paragraph
http://hg.python.org/cpython/rev/841984e96df6

New changeset 9eea6401b892 by Terry Jan Reedy in branch '3.3':
Issue #18429: Add user-oriented News entry about Format / Format Paragraph
http://hg.python.org/cpython/rev/9eea6401b892

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18429>
_______________________________________

From report at bugs.python.org  Sat Aug 10 23:57:23 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Aug 2013 21:57:23 +0000
Subject: [issue18676] Queue: document that zero is accepted as timeout value
In-Reply-To: <1375883528.55.0.275850242187.issue18676@psf.upfronthosting.co.za>
Message-ID: <1376171843.48.0.193483809737.issue18676@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee: docs at python -> terry.reedy
nosy: +terry.reedy
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18676>
_______________________________________

From report at bugs.python.org  Sat Aug 10 23:58:20 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 10 Aug 2013 21:58:20 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1373400107.5.0.285657244525.issue18416@psf.upfronthosting.co.za>
Message-ID: <1376171900.21.0.535232815325.issue18416@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

It seems to me that by *not* doing that, we may have a bug if the cwd changes and the import machinery returns a stateful importer that remembers the path name. Using the actual filesystem path for everything other than sys.path sounds like a much better option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18416>
_______________________________________

From report at bugs.python.org  Sun Aug 11 00:17:23 2013
From: report at bugs.python.org (R. Jayakrishnan)
Date: Sat, 10 Aug 2013 22:17:23 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
Message-ID: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>


New submission from R. Jayakrishnan:

This is to create an IDLE extension that would integrate PEP8 (Syntax Style Checker https://pypi.python.org/pypi/pep8 ) into the IDLE editor window,so the developer who is using the IDLE editor can quickly and frequently check the PEP8 standards of the code which is being developed in an IDLE editor window. Many modern IDE's have not only syntax highlighting but on the fly syntax checking.

Python ensures the quality of code with its own standards implemented as PEP8. The tool pep8 checks Python code against some of the style conventions in PEP8. Also the PEP8 standardization should not be a ?must emphasizing? for a python developer, therefore configuring pep8 to enable/disable errors and warning in various levels should be implemented.

The implementation work is started by Todd at https://bitbucket.org/rovitotv/pythonpatches/src/fae1fdab936043ec35db541808f5789325762fb3/PEP8CheckExtension.patch?at=default

The submitted patch is an effort started from Todd's patch as an example. 
The IDLE with this patch will show PEP8 style check toggle menu in Options.
Once PEP8 check enabled the current module is checked by pep8 tool and the defects will be shown in a extended left pane. 
Defect codes will be listed as a Buttons, button click leads to highlighting the line and column of the defect and scroll editor window if needed. 
It is expected that the developer will correct the defect with the help of the message and eventually press the Resolve button,which refresh the pane.

This is an initial work and I am looking forward for suggestions on improvements and mistakes of this patch.

----------
components: IDLE
files: PEP8Extension_1.patch
keywords: patch
messages: 194841
nosy: JayKrish
priority: normal
severity: normal
status: open
title: IDLE: PEP8 Style Check Integration
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31221/PEP8Extension_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Sun Aug 11 00:18:03 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Aug 2013 22:18:03 +0000
Subject: [issue15721] PEP 3121, 384 Refactoring applied to tkinter module
In-Reply-To: <1345287224.98.0.204885883161.issue15721@psf.upfronthosting.co.za>
Message-ID: <1376173083.01.0.0689437963188.issue15721@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The first two patches (_tkinter_pep3121-384_v0.patch and _tkinter_pep3121-384_v1.patch) seemed to have the refcounts right, but Andrew's further patches lost the required Py_INCREF in the various new() functions (and the corresponding Py_DECREF in deallocs), which is the cause for the crash in #15667.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15721>
_______________________________________

From report at bugs.python.org  Sun Aug 11 00:20:53 2013
From: report at bugs.python.org (R. Jayakrishnan)
Date: Sat, 10 Aug 2013 22:20:53 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1376173253.5.0.720269030085.issue18704@psf.upfronthosting.co.za>


Changes by R. Jayakrishnan <raajjya at gmail.com>:


----------
nosy: +Todd.Rovito

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Sun Aug 11 00:22:39 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 22:22:39 +0000
Subject: [issue15721] PEP 3121, 384 Refactoring applied to tkinter module
In-Reply-To: <1345287224.98.0.204885883161.issue15721@psf.upfronthosting.co.za>
Message-ID: <3cCHrG6WcbzPJr@mail.python.org>


Roundup Robot added the comment:

New changeset 4d0c938870bc by Antoine Pitrou in branch 'default':
Fix refcounting issue with extension types in tkinter.
http://hg.python.org/cpython/rev/4d0c938870bc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15721>
_______________________________________

From report at bugs.python.org  Sun Aug 11 00:31:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 22:31:14 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <3cCJ296d4vzPYS@mail.python.org>


Roundup Robot added the comment:

New changeset 1edff836c954 by Antoine Pitrou in branch 'default':
Issue #10241: Clear extension module dict copies at interpreter shutdown.
http://hg.python.org/cpython/rev/1edff836c954

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10241>
_______________________________________

From report at bugs.python.org  Sun Aug 11 00:31:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Aug 2013 22:31:51 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <1376173911.06.0.159478324448.issue10241@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Re-applied patch after having fixed the tkinter issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10241>
_______________________________________

From report at bugs.python.org  Sun Aug 11 00:40:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Aug 2013 22:40:28 +0000
Subject: [issue18676] Queue: document that zero is accepted as timeout value
In-Reply-To: <1375883528.55.0.275850242187.issue18676@psf.upfronthosting.co.za>
Message-ID: <3cCJDr0vdjzQ02@mail.python.org>


Roundup Robot added the comment:

New changeset 737b53ec5d1a by Terry Jan Reedy in branch '2.7':
Issue #18676: Change 'positive' to 'non-negative' in queue.py put and get
http://hg.python.org/cpython/rev/737b53ec5d1a

New changeset 2122d56d6bc5 by Terry Jan Reedy in branch '3.3':
Issue #18676: Change 'positive' to 'non-negative' in queue.py put and get
http://hg.python.org/cpython/rev/2122d56d6bc5

New changeset d9a9fe5e700d by Terry Jan Reedy in branch 'default':
Issue #18676: Merge from 3.3
http://hg.python.org/cpython/rev/d9a9fe5e700d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18676>
_______________________________________

From report at bugs.python.org  Sun Aug 11 01:03:53 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Aug 2013 23:03:53 +0000
Subject: [issue18676] Queue: document that zero is accepted as timeout value
In-Reply-To: <1375883528.55.0.275850242187.issue18676@psf.upfronthosting.co.za>
Message-ID: <1376175833.91.0.809136617201.issue18676@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Zhongyue, we merge 3.x patches forward (currently 3.3 to 3.4) so only one patch is usually needed unless the differences are non-trivial. It is easier if different version patches are tagged with the version in the filename.('-27', for instance.

If you think you will ever contribute another patch, especially one less trivial than this one, please go to
http://www.python.org/psf/contrib/ and
http://www.python.org/psf/contrib/contrib-form/
Note that the agreement can now be submitted electronically.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18676>
_______________________________________

From report at bugs.python.org  Sun Aug 11 01:05:17 2013
From: report at bugs.python.org (James Sanders)
Date: Sat, 10 Aug 2013 23:05:17 +0000
Subject: [issue5527] multiprocessing won't work with Tkinter (under Linux)
In-Reply-To: <1237574081.02.0.0677822756927.issue5527@psf.upfronthosting.co.za>
Message-ID: <1376175917.76.0.429880331823.issue5527@psf.upfronthosting.co.za>


James Sanders added the comment:

I recently got hit by this bug on 64-bit ubuntu 13.04, with python 3.3.1 and tcl/tk 8.5.13 installed from the Ubuntu repositories.  However, I tried building the same versions of tcl, tk, and python locally, and couldn't reproduce the bug.  I also built python 3.3.2 with several releases of tcl/tk.  With 8.5.8 and earlier, I get a buffer overflow.  With 8.5.9-14 and recent trunk versions of tk and tcl, everything works.  With 8.6.0, I get the hang.

In the tcl/tk versions where the script works correctly, if I also have some tkinter code (such as instantiating a Tk and a Button) in the main process before the fork, then I sometimes get a crash with one of several different weird error messages from X, but this is very inconsistent.

The direct cause of the bug seems to be the call to Tcl_FindExecutable in _tkinter's initialization code, which tells tcl the path of the python executable, but as a side effect triggers tcl into running some initialization routines earlier than it would do otherwise.  Removing this call (which doesn't seem to have any adverse effects on my system) appears to "fix" the bug, but if anything else triggers tcl's initialization code before the fork (such as instantiating a tkinter.Tk object), the hang returns.

I'm not really sure where else to go with this.  I've attached a simplified python-3-compatible script displaying the problem in case someone else wants to have a look.

----------
nosy: +James.Sanders
versions: +Python 2.7, Python 3.3, Python 3.4 -Python 2.6
Added file: http://bugs.python.org/file31222/hanger.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5527>
_______________________________________

From report at bugs.python.org  Sun Aug 11 01:24:09 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Aug 2013 23:24:09 +0000
Subject: [issue18686] Tkinter focus_get on menu results in KeyError
In-Reply-To: <1375980942.46.0.944431245569.issue18686@psf.upfronthosting.co.za>
Message-ID: <1376177049.13.0.0628293563535.issue18686@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am not able to reproduce any problem on Win 7 with either recent 2.7.6a0 (repository) or 3.3.2. Nothing happens if I click on [File] or anywhere else outside of the entry box or [_]...[X] window buttons. Please give the signin info such as "Python 2.7.5+ (default, Jul  1 2013, 14:50:57) [MSC v.1500 32 bit (Intel)] on win32" and update if you do not have 2.7.5.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18686>
_______________________________________

From report at bugs.python.org  Sun Aug 11 01:45:20 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Sat, 10 Aug 2013 23:45:20 +0000
Subject: [issue18705] Fix arround 100 typos/spelling mistakes
Message-ID: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>


New submission from F?vry Thibault:

In issue 18466 I had said I was planning to write a tool that checks python source code to see if they are spelling mistakes in comments/strings. As it was said there, the big issue was the fact that python has so many non-english words and that docstrings often had variable names in them, so I had to work arround the issue and add a personal word list.

I only applied the tool to Lib/*.py yet, as it takes some time to check false-positives and I didn't want to end with patches too big to be reviewed.

----------
assignee: docs at python
components: Documentation
files: spelling_Lib.diff
keywords: patch
messages: 194850
nosy: docs at python, iwontbecreative
priority: normal
severity: normal
status: open
title: Fix arround 100 typos/spelling mistakes
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31223/spelling_Lib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18705>
_______________________________________

From report at bugs.python.org  Sun Aug 11 01:48:10 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Sat, 10 Aug 2013 23:48:10 +0000
Subject: [issue18705] Fix arround 100 typos/spelling mistakes
In-Reply-To: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>
Message-ID: <1376178490.13.0.863752745187.issue18705@psf.upfronthosting.co.za>


F?vry Thibault added the comment:

Note that I am not a very good python programmer so the attached script may look ugly to you, but it works.

----------
versions: +Python 3.3
Added file: http://bugs.python.org/file31224/spell.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18705>
_______________________________________

From report at bugs.python.org  Sun Aug 11 01:48:56 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Sat, 10 Aug 2013 23:48:56 +0000
Subject: [issue18705] Fix arround 100 typos/spelling mistakes
In-Reply-To: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>
Message-ID: <1376178536.93.0.384771582335.issue18705@psf.upfronthosting.co.za>


F?vry Thibault added the comment:

And here is a python_words.txt so you have to press enter less times :)

----------
Added file: http://bugs.python.org/file31225/python_words.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18705>
_______________________________________

From report at bugs.python.org  Sun Aug 11 01:50:17 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Sat, 10 Aug 2013 23:50:17 +0000
Subject: [issue18466] Spelling mistakes in various code comments.
In-Reply-To: <1373909571.44.0.949892598858.issue18466@psf.upfronthosting.co.za>
Message-ID: <1376178617.07.0.719728758348.issue18466@psf.upfronthosting.co.za>


F?vry Thibault added the comment:

See issue 18705 for a basic script.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18466>
_______________________________________

From report at bugs.python.org  Sun Aug 11 02:03:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Aug 2013 00:03:15 +0000
Subject: [issue18706] test failure in test_codeccallbacks
Message-ID: <1376179395.42.0.0457635695026.issue18706@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Since issue #18681, the following test sequence fails:

./python -m test -v test_codecencodings_kr test_imp test_codeccallbacks

[...]

======================================================================
ERROR: test_xmlcharnamereplace (test.test_codeccallbacks.CodecCallbackTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_codeccallbacks.py", line 112, in test_xmlcharnamereplace
    self.assertEqual(sin.encode("ascii", "test.xmlcharnamereplace"), sout)
  File "/home/antoine/cpython/default/Lib/test/test_codeccallbacks.py", line 102, in xmlcharnamereplace
    l.append("&%s;" % html.entities.codepoint2name[ord(c)])
AttributeError: 'module' object has no attribute 'entities'

----------
assignee: ezio.melotti
components: Tests
messages: 194854
nosy: ezio.melotti, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test failure in test_codeccallbacks
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18706>
_______________________________________

From report at bugs.python.org  Sun Aug 11 02:30:09 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 11 Aug 2013 00:30:09 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za>
Message-ID: <1376181009.14.0.542635704841.issue15651@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Found some problems in the interaction of PEP 3121 and import_fresh_module: http://mail.python.org/pipermail/python-dev/2013-August/127862.html

I'd still like to see the in-PyInit__elementtree caching deleted eventually, without harming test coverage. So this issue will remain open for now, until we decide what to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Sun Aug 11 02:44:52 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 11 Aug 2013 00:44:52 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za>
Message-ID: <1376181892.93.0.06100064963.issue15651@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

BTW, Antoine, w.r.t documentation - I agree that the whole PyState_* sequence needs better documentation and examples, but in the meantime I'm attaching a simple patch for c-api/module.rst. It clarifies that PyState_AddModule doesn't really have to be called explicitly in extensions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Sun Aug 11 02:45:03 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 11 Aug 2013 00:45:03 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za>
Message-ID: <1376181903.37.0.774381458072.issue15651@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Added file: http://bugs.python.org/file31226/pystate-findmodule-clarify.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Sun Aug 11 02:59:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Aug 2013 00:59:19 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <3cCMK16vHKzRLF@mail.python.org>


Roundup Robot added the comment:

New changeset 9b0e9e9812f8 by Terry Jan Reedy in branch 'default':
Issue #15301: skip new test method so Windows builtbots stop failing.
http://hg.python.org/cpython/rev/9b0e9e9812f8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Sun Aug 11 03:03:15 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 11 Aug 2013 01:03:15 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1376182995.89.0.28698192857.issue15301@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This was the only failure on 2 of 4 buildbots when I last looked.

test_os has several methods like this:

    def test_dup2(self):
        if hasattr(os, "dup2"):
            self.check(os.dup2, 20)

Should the hasattr be moved to skipUnless for all of these?
They now 'pass' without the needed os method.

----------
nosy: +terry.reedy
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Sun Aug 11 03:09:01 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 11 Aug 2013 01:09:01 +0000
Subject: [issue18706] test failure in test_codeccallbacks
In-Reply-To: <1376179395.42.0.0457635695026.issue18706@psf.upfronthosting.co.za>
Message-ID: <1376183341.11.0.550397880496.issue18706@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Failure is intermittent. The only related lines in test_codeccallbacks are

002: import html.entities
102:    l.append("&%s;" % html.entities.codepoint2name[ord(c)])

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18706>
_______________________________________

From report at bugs.python.org  Sun Aug 11 03:55:05 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 11 Aug 2013 01:55:05 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1376182995.89.0.28698192857.issue15301@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o9a2vnYrWM5To+gRA8fhJ1pLpW7uizk9UfP1siH+4Q6FA@mail.gmail.com>


Benjamin Peterson added the comment:

Likely they were written before the invention of unittest test
skpping. They could be converted.

2013/8/10 Terry J. Reedy <report at bugs.python.org>:
>
> Terry J. Reedy added the comment:
>
> This was the only failure on 2 of 4 buildbots when I last looked.
>
> test_os has several methods like this:
>
>     def test_dup2(self):
>         if hasattr(os, "dup2"):
>             self.check(os.dup2, 20)
>
> Should the hasattr be moved to skipUnless for all of these?
> They now 'pass' without the needed os method.
>
> ----------
> nosy: +terry.reedy
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue15301>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Sun Aug 11 05:09:54 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 11 Aug 2013 03:09:54 +0000
Subject: [issue18429] IDLE: Format Paragraph doesn't function with comment
	blocks
In-Reply-To: <1373565372.76.0.397397850212.issue18429@psf.upfronthosting.co.za>
Message-ID: <1376190594.13.0.363211224646.issue18429@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The 'fix', including the test, is included with the patch for #18226.  It shares with normal text the problem that selections of partial lines do not work well. I think this might be fixed in #18583 by only re-wrapping complete lines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18429>
_______________________________________

From report at bugs.python.org  Sun Aug 11 06:21:14 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 11 Aug 2013 04:21:14 +0000
Subject: [issue18667] missing HAVE_FCHOWNAT
In-Reply-To: <1375772087.0.0.361755653525.issue18667@psf.upfronthosting.co.za>
Message-ID: <1376194874.25.0.983538867355.issue18667@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Georg, I'm gonna commit this for 3.4.  You want it in 3.3 as well?  I claim it's 100% a bugfix.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18667>
_______________________________________

From report at bugs.python.org  Sun Aug 11 07:48:50 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 11 Aug 2013 05:48:50 +0000
Subject: [issue18667] missing HAVE_FCHOWNAT
In-Reply-To: <1375772087.0.0.361755653525.issue18667@psf.upfronthosting.co.za>
Message-ID: <1376200130.73.0.677034683622.issue18667@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Well, since you're a RM now you should know :D

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18667>
_______________________________________

From report at bugs.python.org  Sun Aug 11 07:57:32 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 11 Aug 2013 05:57:32 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1376200652.15.0.541353178873.issue18693@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Sorry, sorry.

Long week, felt like more than two days, mild sense of unease and stress due to non-functioning Release Schedule on python.org, and wanting to get Enum used /somewhere/ in the stdlib before 3.4 is locked down.

Making help() better would be a better solution, especially if we enhanced it to show docstrings on instances.

I'll see what I can figure out.  Feel free to beat me to it.  :)

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Sun Aug 11 08:11:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Aug 2013 06:11:33 +0000
Subject: [issue18706] test failure in test_codeccallbacks
In-Reply-To: <1376179395.42.0.0457635695026.issue18706@psf.upfronthosting.co.za>
Message-ID: <1376201493.35.0.32058693304.issue18706@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18706>
_______________________________________

From report at bugs.python.org  Sun Aug 11 08:18:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Aug 2013 06:18:31 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1376201911.62.0.307078999912.issue15301@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Likely they were written before the invention of unittest test
skpping. They could be converted.

See issue18702.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Sun Aug 11 08:37:04 2013
From: report at bugs.python.org (madan ram)
Date: Sun, 11 Aug 2013 06:37:04 +0000
Subject: [issue18707] the readme should also talk about how to build doc.
Message-ID: <1376203024.02.0.197448582438.issue18707@psf.upfronthosting.co.za>


New submission from madan ram:

Since most of and also I faced problem of building Doc initially then later i found out how to build Doc.

So i thought to include details on how to build Doc in README.

----------
assignee: docs at python
components: Build, Devguide, Documentation, Installation
files: README.diff
keywords: patch
messages: 194866
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, madan.ram
priority: normal
severity: normal
status: open
title: the readme should also talk about how to build doc.
versions: Python 3.4
Added file: http://bugs.python.org/file31227/README.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18707>
_______________________________________

From report at bugs.python.org  Sun Aug 11 08:47:16 2013
From: report at bugs.python.org (madan ram)
Date: Sun, 11 Aug 2013 06:47:16 +0000
Subject: [issue18708] Change required in python 3.4 interpretor .
Message-ID: <1376203636.29.0.712075241068.issue18708@psf.upfronthosting.co.za>


New submission from madan ram:

As I observed when using python 3.4 Interpretor  is that it would be able to distinguish between char by '' and string by ""

>>> input()    
a
'a'

and 

>>> input()
aa
'aa'

it would be better if output was
"aa"

but if i want to fix this which file to edit.

----------
components: Interpreter Core
messages: 194867
nosy: madan.ram, rhettinger
priority: normal
severity: normal
status: open
title: Change required in python 3.4 interpretor .
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18708>
_______________________________________

From report at bugs.python.org  Sun Aug 11 08:49:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Aug 2013 06:49:36 +0000
Subject: [issue18706] test failure in test_codeccallbacks
In-Reply-To: <1376179395.42.0.0457635695026.issue18706@psf.upfronthosting.co.za>
Message-ID: <1376203776.76.0.435537159735.issue18706@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are two ways to fix this issue -- one change test_imp.py and other change test_codeccallbacks.py. The proposed patch contains both.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31228/issue18706.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18706>
_______________________________________

From report at bugs.python.org  Sun Aug 11 09:40:20 2013
From: report at bugs.python.org (sdia)
Date: Sun, 11 Aug 2013 07:40:20 +0000
Subject: [issue18445] Tools/Script/Readme is outdated
In-Reply-To: <1373782620.19.0.347266346086.issue18445@psf.upfronthosting.co.za>
Message-ID: <1376206820.71.0.316824052789.issue18445@psf.upfronthosting.co.za>


sdia added the comment:

Hello,

I will try to submit a patch for this issue.

----------
nosy: +seydou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18445>
_______________________________________

From report at bugs.python.org  Sun Aug 11 09:42:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Aug 2013 07:42:45 +0000
Subject: [issue18706] test failure in test_codeccallbacks
In-Reply-To: <1376179395.42.0.0457635695026.issue18706@psf.upfronthosting.co.za>
Message-ID: <1376206965.67.0.767372319977.issue18706@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

However it looks weird:

>>> def f():
...     import html.entities
...     del sys.modules['html']
... 
>>> f()
>>> import html.entities
>>> html.entities
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'entities'

Perhaps import machinery should be fixed instead of tests.

----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18706>
_______________________________________

From report at bugs.python.org  Sun Aug 11 09:57:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Aug 2013 07:57:19 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1376207839.74.0.757064287433.issue18647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And not to me. This check forbids some possible legal regexps and doesn't prevent from shooting in the leg.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18647>
_______________________________________

From report at bugs.python.org  Sun Aug 11 10:28:50 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Aug 2013 08:28:50 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1376209730.04.0.487789558358.issue18693@psf.upfronthosting.co.za>


Ned Deily added the comment:

Ethan, http://www.python.org/dev/peps/pep-0429/#release-schedule
TL;DR - no new features after beta 1 (2013-11-24), no non-release-critical bug fixes after rc1 (2014-01-19)

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Sun Aug 11 10:35:22 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 11 Aug 2013 08:35:22 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
	iterable)
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1376210122.98.0.63467048796.issue18652@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

So I wanted to provide a first patch to move the discussion on and realized that itertools appears currently to be completely inside of `Modules/itertoolsmodule.c`. :-/

Any volunteers? :)

----------
assignee: hynek -> 
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18652>
_______________________________________

From report at bugs.python.org  Sun Aug 11 10:45:42 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 11 Aug 2013 08:45:42 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1376210742.57.0.162140658587.issue18704@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

I like the idea of having a PEP8-checker for IDLE.

----------
nosy: +Ramchandra Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Sun Aug 11 10:47:57 2013
From: report at bugs.python.org (Seydou Dia)
Date: Sun, 11 Aug 2013 08:47:57 +0000
Subject: [issue18445] Tools/Script/Readme is outdated
In-Reply-To: <1373782620.19.0.347266346086.issue18445@psf.upfronthosting.co.za>
Message-ID: <1376210877.43.0.797516656923.issue18445@psf.upfronthosting.co.za>


Seydou Dia added the comment:

>Several issues :
>- abitype.py, analyze_dxp.py, get-remote-certificate.py, import_diagnostics.py, parse_html5_entities.py are not documented.

Except analyze_dxp.py, all those files have been docummented in README. analyze_dxp.py was already documented so I don't understand what action is needed.
Note that I have also documented find-uname.py.

>- README mentions redemo.py which was moved to Tools/Demo.
Done.

>- README says all python scripts are executables, but some need chmod +x
I can help here.

> - The script list in readme would benefit from being sorted in alphabetical order
Done.

----------
keywords: +patch
Added file: http://bugs.python.org/file31229/issue-18445.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18445>
_______________________________________

From report at bugs.python.org  Sun Aug 11 10:50:17 2013
From: report at bugs.python.org (Seydou Dia)
Date: Sun, 11 Aug 2013 08:50:17 +0000
Subject: [issue18445] Tools/Script/Readme is outdated
In-Reply-To: <1373782620.19.0.347266346086.issue18445@psf.upfronthosting.co.za>
Message-ID: <1376211017.79.0.357127898797.issue18445@psf.upfronthosting.co.za>


Seydou Dia added the comment:

>>- README says all python scripts are executables, but some need chmod +x
>I can help here.

Sorry I meant : "I can't help here". :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18445>
_______________________________________

From report at bugs.python.org  Sun Aug 11 11:32:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Aug 2013 09:32:39 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
	iterable)
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1376213559.79.0.641042949327.issue18652@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

How large will be a C implementation of this one-line function?

I'm still -1 for polluting the itertools module with trivial combinations of existing functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18652>
_______________________________________

From report at bugs.python.org  Sun Aug 11 11:46:52 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Aug 2013 09:46:52 +0000
Subject: [issue18706] test failure in test_codeccallbacks
In-Reply-To: <1376179395.42.0.0457635695026.issue18706@psf.upfronthosting.co.za>
Message-ID: <1376214412.66.0.638075460979.issue18706@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> ./python -m test -v test_codecencodings_kr test_imp test_codeccallbacks

Thanks, I was trying to reproduce the failure yesterday with test_imp test_codeccallbacks but it wasn't working -- now I can reproduce it.

My idea was to import html and html.parser and then remove them both, and that's what the patch did:

>>> import sys
>>> m = set(sys.modules)
>>> from html import parser
>>> set(sys.modules) - m
{'html.parser', 'linecache', 'tokenize', 'warnings', '_markupbase', 'html', 'token'}
>>> del sys.modules['html']
>>> set(sys.modules) - m
{'html.parser', 'linecache', 'tokenize', '_markupbase', 'warnings', 'token'}
>>> del sys.modules['html.parser']
>>> set(sys.modules) - m
{'token', '_markupbase', 'tokenize', 'warnings', 'linecache'}

I think the problem is that if test_codecencodings_kr is run before test_imp, test_imp deletes html and html.parser but leaves the html.entities imported by test_codecencodings_kr, and when test_codeccallbacks tries to use it again it fails:

>>> import sys
>>> m = set(sys.modules)
>>> import html.entities
>>> set(sys.modules) - m
{'html.entities', 'html'}
>>> from html import parser
>>> set(sys.modules) - m
{'_markupbase', 'html', 'html.entities', 'tokenize', 'html.parser', 'linecache', 'warnings', 'token'}
>>> del sys.modules['html']
>>> set(sys.modules) - m
{'_markupbase', 'tokenize', 'html.entities', 'token', 'html.parser', 'linecache', 'warnings'}
>>> del sys.modules['html.parser']
>>> set(sys.modules) - m
{'_markupbase', 'tokenize', 'html.entities', 'token', 'linecache', 'warnings'}
>>> html.entities
<module 'html.entities' from '/home/wolf/dev/py/py3k/Lib/html/entities.py'>
>>> import html.entities
>>> html.entities
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'entities'

A solution would be to remove all the modules that start with 'html.' (see attached patch):

>>> import sys
>>> m = set(sys.modules)
>>> import html.entities
>>> from html import parser
>>> del sys.modules['html']
>>> del sys.modules['html.parser']
>>> set(sys.modules) - m
{'warnings', 'linecache', 'token', 'html.entities', 'tokenize', '_markupbase'}
>>> del sys.modules['html.entities']
>>> import html.entities
>>> html.entities
<module 'html.entities' from '/home/wolf/dev/py/py3k/Lib/html/entities.py'>

Another (possibly better) solution would be to copy sys.modules before messing with it and restore it afterwards.  I was looking in test.support for a context manager to do it but I didn't find it, so I just deleted the modules I imported manually.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18706>
_______________________________________

From report at bugs.python.org  Sun Aug 11 11:52:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Aug 2013 09:52:16 +0000
Subject: [issue18706] test failure in test_codeccallbacks
In-Reply-To: <1376206965.67.0.767372319977.issue18706@psf.upfronthosting.co.za>
Message-ID: <1376214729.2672.5.camel@fsol>


Antoine Pitrou added the comment:

> Perhaps import machinery should be fixed instead of tests.

Yes, the import machinery is acting weird here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18706>
_______________________________________

From report at bugs.python.org  Sun Aug 11 11:53:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Aug 2013 09:53:17 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
	iterable)
In-Reply-To: <1376213559.79.0.641042949327.issue18652@psf.upfronthosting.co.za>
Message-ID: <1376214790.2672.6.camel@fsol>


Antoine Pitrou added the comment:

> How large will be a C implementation of this one-line function?
> 
> I'm still -1 for polluting the itertools module with trivial
> combinations of existing functions.

The solution is to move the current itertools to _itertools and have a
companion itertools.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18652>
_______________________________________

From report at bugs.python.org  Sun Aug 11 12:02:47 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 11 Aug 2013 10:02:47 +0000
Subject: [issue18705] Fix arround 100 typos/spelling mistakes
In-Reply-To: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>
Message-ID: <1376215367.33.0.248319445414.issue18705@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks for the patch.

I don't think there's a strict policy about using American spellings in the source;  I think spellings like 'behaviour' and 'grey' should be left alone.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18705>
_______________________________________

From report at bugs.python.org  Sun Aug 11 12:07:04 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Aug 2013 10:07:04 +0000
Subject: [issue18663] In unittest.TestCase.assertAlmostEqual doc specify the
	delta description
In-Reply-To: <1375725190.79.0.442588525807.issue18663@psf.upfronthosting.co.za>
Message-ID: <3cCbT35LCdz7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset e0f86c3b3685 by Ezio Melotti in branch '3.3':
#18663: document that assertAlmostEqual also works when the values are equal and add tests.
http://hg.python.org/cpython/rev/e0f86c3b3685

New changeset eeda59e08c83 by Ezio Melotti in branch 'default':
#18663: merge with 3.3.
http://hg.python.org/cpython/rev/eeda59e08c83

New changeset 9ddc63c039ba by Ezio Melotti in branch '2.7':
#18663: document that assertAlmostEqual also works when the values are equal and add tests.
http://hg.python.org/cpython/rev/9ddc63c039ba

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18663>
_______________________________________

From report at bugs.python.org  Sun Aug 11 12:07:53 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Aug 2013 10:07:53 +0000
Subject: [issue18663] In unittest.TestCase.assertAlmostEqual doc specify the
	delta description
In-Reply-To: <1375725190.79.0.442588525807.issue18663@psf.upfronthosting.co.za>
Message-ID: <1376215673.1.0.934338068343.issue18663@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18663>
_______________________________________

From report at bugs.python.org  Sun Aug 11 12:15:13 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Sun, 11 Aug 2013 10:15:13 +0000
Subject: [issue18705] Fix arround 100 typos/spelling mistakes
In-Reply-To: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>
Message-ID: <1376216113.88.0.282176089216.issue18705@psf.upfronthosting.co.za>


F?vry Thibault added the comment:

> I don't think there's a strict policy about using American spellings in the source;  I think spellings like 'behaviour' and 'grey' should be left alone.

I didn't really know whether to change them or not and did not find an answer in the devguide (Might be worth documenting it ?) so I decided to change it :/.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18705>
_______________________________________

From report at bugs.python.org  Sun Aug 11 12:19:28 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Aug 2013 10:19:28 +0000
Subject: [issue18705] Fix arround 100 typos/spelling mistakes
In-Reply-To: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>
Message-ID: <1376216368.16.0.0904511250454.issue18705@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Both AE and BE are OK, as long as each document is internally consistent.  For new documents I think AE is preferred, but not forced.

----------
nosy: +ezio.melotti
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18705>
_______________________________________

From report at bugs.python.org  Sun Aug 11 12:23:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Aug 2013 10:23:45 +0000
Subject: [issue18706] test failure in test_codeccallbacks
In-Reply-To: <1376179395.42.0.0457635695026.issue18706@psf.upfronthosting.co.za>
Message-ID: <1376216625.51.0.146165859806.issue18706@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps `del sys.modules['module']` should remove all 'module.submodule' from sys.modules. Or perhaps `import module.submodule` should ensure that 'module' is in sys.modules and has the 'submodule' attribute.

Ezio, seems you forgot to attach a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18706>
_______________________________________

From report at bugs.python.org  Sun Aug 11 12:24:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Aug 2013 10:24:25 +0000
Subject: [issue18706] test failure in test_codeccallbacks
In-Reply-To: <1376179395.42.0.0457635695026.issue18706@psf.upfronthosting.co.za>
Message-ID: <1376216665.33.0.177452166393.issue18706@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file31230/issue18706.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18706>
_______________________________________

From report at bugs.python.org  Sun Aug 11 12:26:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Aug 2013 10:26:46 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
	iterable)
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1376216806.49.0.107152948334.issue18652@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Looks as too much work for too small gain (and I'm suppose the total gain is negative if we count all costs).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18652>
_______________________________________

From report at bugs.python.org  Sun Aug 11 13:05:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Aug 2013 11:05:22 +0000
Subject: [issue18706] test failure in test_codeccallbacks
In-Reply-To: <1376179395.42.0.0457635695026.issue18706@psf.upfronthosting.co.za>
Message-ID: <1376219122.65.0.194541853084.issue18706@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

My preference goes to Serhiy's fix for test_imp.
Note that the import machinery oddity would deserve fixing too (in a separate issue perhaps ?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18706>
_______________________________________

From report at bugs.python.org  Sun Aug 11 13:11:50 2013
From: report at bugs.python.org (Robin Schreiber)
Date: Sun, 11 Aug 2013 11:11:50 +0000
Subject: [issue15787] PEP 3121, 384 Refactoring
In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za>
Message-ID: <1376219510.56.0.196070734349.issue15787@psf.upfronthosting.co.za>


Robin Schreiber added the comment:

I have in fact used abitype.py to produce all of my PEP 384 patches, however it failed to work correctly in like 50% of all cases, and I had to complete the rest of the patch by hand.I thought about correcting the abitype.py throughout the GSOC, but I happened to find it easier to simply do the missing steps by hand. (I don't know If the script has been fixed up to this point though).
In any case, it might also be interesting for external extension module developers to make use of a fully working version of this script, so they can make their modules PEP 384 compliant without investing too much time.
One has to keep in mind however that almost any script will fail to work by itself, once we run into problems like refcounting or concurrency when applying the patch to a module.

I will have some free time throughout next week and will start to correct the patches for the xx modules (as Alex proposed), and continue from there to all the other patches I have submitted a year ago.

I am deeply sorry that I have not continued my work on this project earlier, however I dramatically underestimated the amount if work related to university, etc... I still feel obliged to complete all these patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15787>
_______________________________________

From report at bugs.python.org  Sun Aug 11 14:04:35 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 11 Aug 2013 12:04:35 +0000
Subject: [issue18708] Change required in python 3.4 interpretor .
In-Reply-To: <1376203636.29.0.712075241068.issue18708@psf.upfronthosting.co.za>
Message-ID: <1376222675.67.0.543978222489.issue18708@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Unlike C, Python doesn't have any 'character' type:  the elements of a string are simply 1-character strings.  The two quote styles are mostly interchangeable:  again, unlike C, there's no particular meaning attached to the use of single quotes or double quotes.

So you'd be asking for 1-character strings to be represented using single quotes and multi-character strings to be representing using double quotes.  That doesn't seem like a particularly useful distinction.  Worse, it might even be misleading, since it would suggest a C-like distinction between characters and strings.

As to which file:  you're looking for the implementation of str.__repr__, which is in the unicode_repr function in Objects/unicodeobject.c.  The logic for choosing which style of quote to use is about 50 lines into that function (line 12128 at revision eeda59e08c83).

Closing this as rejected.

----------
nosy: +mark.dickinson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18708>
_______________________________________

From report at bugs.python.org  Sun Aug 11 14:25:35 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Sun, 11 Aug 2013 12:25:35 +0000
Subject: [issue18705] Fix arround 100 typos/spelling mistakes
In-Reply-To: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>
Message-ID: <1376223935.22.0.0347936115552.issue18705@psf.upfronthosting.co.za>


F?vry Thibault added the comment:

Updated the patch to no longer change BE to AE and fixed two mistakes in my correction.

----------
Added file: http://bugs.python.org/file31231/spelling_Lib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18705>
_______________________________________

From report at bugs.python.org  Sun Aug 11 14:26:48 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Sun, 11 Aug 2013 12:26:48 +0000
Subject: [issue18705] Fix typos/spelling mistakes in Lib/*.py files
In-Reply-To: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>
Message-ID: <1376224008.41.0.307606098658.issue18705@psf.upfronthosting.co.za>


Changes by F?vry Thibault <thibaultfevry at gmail.com>:


----------
title: Fix arround 100 typos/spelling mistakes -> Fix typos/spelling mistakes in Lib/*.py files

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18705>
_______________________________________

From report at bugs.python.org  Sun Aug 11 14:31:55 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 11 Aug 2013 12:31:55 +0000
Subject: [issue18705] Fix typos/spelling mistakes in Lib/*.py files
In-Reply-To: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>
Message-ID: <1376224315.01.0.452021467955.issue18705@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks for the update.  All the changes in the updated patch look good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18705>
_______________________________________

From report at bugs.python.org  Sun Aug 11 14:37:10 2013
From: report at bugs.python.org (Robin Schreiber)
Date: Sun, 11 Aug 2013 12:37:10 +0000
Subject: [issue15849] PEP 3121, 384 Refactoring applied to xx module
In-Reply-To: <1346596353.57.0.974507844943.issue15849@psf.upfronthosting.co.za>
Message-ID: <1376224630.02.0.458660909151.issue15849@psf.upfronthosting.co.za>


Robin Schreiber added the comment:

I absolutely agree on mentioning the member names in the comments. :-)

In the example Martin gave in his PEP 3121, the PyInit does not perform any INCREFs on the Variables that are referenced from inside the module state.
He therefore left out m_free completely as there was nothing to DECREF within the module state.
Back when I did my GSoC together with Martin, we decided that the Module state itself can be considered a valid container object, an therefore has to INCREF and in the end of its lifecycle (that is within m_free) also DECREF every object reference it holds. I therefore decided to include that into every module I refactored, and consequently also the xxmodule.

I was also thinking about redefining the macro of xx_state_global with a NULL check, however this would lead either to a redundant call of PyState_FindModule (Which may lead to unnecessary performance degregation as xx_state_global is used quite frequently in some parts of the respective module) or I had to find some awkward way to store the result o f FindModule in some local variable exapnded by the macro, which I would not consider a good idea. Instead Martin and I were thinking of including a NULL safe variant of xx_state_global only in CPython Debug Builds. What do you think about that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15849>
_______________________________________

From report at bugs.python.org  Sun Aug 11 14:42:00 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 11 Aug 2013 12:42:00 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1376224920.61.0.509238578305.issue18693@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Ethan, as Ned said (and I think you got this answer in the list before), the real feature cutoff is Beta 1. So we have time until the end of November. Note that even new PEPs (like the statistics one) can go in before that. Even after beta, things that appear to be bugs (like this issue) can usually be fixed before the RCs come. So there is no time pressure whatsoever.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Sun Aug 11 17:38:10 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Aug 2013 15:38:10 +0000
Subject: [issue18706] test failure in test_codeccallbacks
In-Reply-To: <1376179395.42.0.0457635695026.issue18706@psf.upfronthosting.co.za>
Message-ID: <1376235490.74.0.16001577756.issue18706@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> My preference goes to Serhiy's fix for test_imp.

Fair enough.  Serhiy do you want to commit your fix?

> Note that the import machinery oddity would deserve fixing too
> (in a separate issue perhaps ?).

This should be a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18706>
_______________________________________

From report at bugs.python.org  Sun Aug 11 17:53:23 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 11 Aug 2013 15:53:23 +0000
Subject: [issue18304] ElementTree gets awkward to use if there is an xmlns
In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za>
Message-ID: <1376236403.79.0.981155716557.issue18304@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

FWIW, lxml.etree supports wildcards like '{*}tag' in searches, and this is otherwise quite rarely a problem in practice.

I'm -1 on the proposed feature and wouldn't mind rejecting this all together. (At least change the title to something more appropriate.)

----------
components: +Library (Lib), XML -Extension Modules
nosy: +eli.bendersky, scoder
versions: +Python 3.4 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18304>
_______________________________________

From report at bugs.python.org  Sun Aug 11 17:59:15 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 11 Aug 2013 15:59:15 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1376236755.65.0.803470692518.issue18647@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

I think you're probably right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18647>
_______________________________________

From report at bugs.python.org  Sun Aug 11 18:00:13 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 11 Aug 2013 16:00:13 +0000
Subject: [issue18670] Using read_mime_types function from mimetypes module
	gives resource warning
In-Reply-To: <1375803104.23.0.740839065527.issue18670@psf.upfronthosting.co.za>
Message-ID: <1376236813.1.0.155180547756.issue18670@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Attached the second patch to use addCleanup rather than tear down method. Also, I added the non-existent file case.

----------
Added file: http://bugs.python.org/file31232/fix_resource_warning_read_mime_types_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18670>
_______________________________________

From report at bugs.python.org  Sun Aug 11 18:05:44 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 11 Aug 2013 16:05:44 +0000
Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags
	and seaches
In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za>
Message-ID: <1376237144.12.0.850568693422.issue18304@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I was planning to look more closely at the namespace support in ET at some point, but haven't found the time yet.

[changing the title to be more helpful]

----------
title: ElementTree gets awkward to use if there is an xmlns -> ElementTree -- provide a way to ignore namespace in tags and seaches

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18304>
_______________________________________

From report at bugs.python.org  Sun Aug 11 18:12:16 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 11 Aug 2013 16:12:16 +0000
Subject: [issue18268] ElementTree.fromstring non-deterministically gives
	unicode text data
In-Reply-To: <1371676914.3.0.530507394222.issue18268@psf.upfronthosting.co.za>
Message-ID: <1376237536.78.0.746438710797.issue18268@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Rejecting this ticket was the right thing to do. It's not a bug but a feature. In Python 2.x, ElementTree returns any text content that can correctly be represented as an ASCII encoded string in the native Py2.x string type (i.e. 'str'). Only non-ASCII strings are returned as unicode values. So it's actually completely deterministic and predictable behaviour. Amongst other things, it saves memory.

Note that in Python 2.x, ASCII-only str values are compatible with unicode values and get promoted to unicode at need. If you want to make sure you always use unicode values, you can call "unicode(text)" on whatever you get back, but in practice, it's really not a problem.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18268>
_______________________________________

From report at bugs.python.org  Sun Aug 11 18:17:22 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 11 Aug 2013 16:17:22 +0000
Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags
	and seaches
In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za>
Message-ID: <1376237842.14.0.105465889257.issue18304@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

There's also the QName class which can be used to split qualified tag names. And it's pretty trivial to pre-process the entire tree by stripping all namespaces from it the intention is really to do namespace agnostic processing. However, in my experience, most people who want to do that haven't actually understood namespaces (although, admittedly, sometimes it's those who designed the XML format who didn't understand namespaces ...).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18304>
_______________________________________

From report at bugs.python.org  Sun Aug 11 18:20:07 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Aug 2013 16:20:07 +0000
Subject: [issue18670] Using read_mime_types function from mimetypes module
	gives resource warning
In-Reply-To: <1375803104.23.0.740839065527.issue18670@psf.upfronthosting.co.za>
Message-ID: <1376238007.35.0.0754193956437.issue18670@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18670>
_______________________________________

From report at bugs.python.org  Sun Aug 11 18:30:21 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 11 Aug 2013 16:30:21 +0000
Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output
In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>
Message-ID: <1376238621.61.0.742683972156.issue14465@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Just to reiterate this point, lxml.etree supports a "pretty_print" flag in its tostring() function and ElementTree.write(). It would thus make sense to support the same thing in ET.

http://lxml.de/api.html#serialisation

For completeness, the current signature looks like this:

def tostring(element_or_tree, *, encoding=None, method="xml",
             xml_declaration=None, pretty_print=False,
             with_tail=True, standalone=None, doctype=None,
             exclusive=False, with_comments=True,
             inclusive_ns_prefixes=None):

(The last three options are for C14N serialisation.)

----------
nosy: +scoder
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14465>
_______________________________________

From report at bugs.python.org  Sun Aug 11 19:14:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Aug 2013 17:14:23 +0000
Subject: [issue18681] typo in imp.reload
In-Reply-To: <1375932142.75.0.662721125733.issue18681@psf.upfronthosting.co.za>
Message-ID: <3cCmy66WlvzRMX@mail.python.org>


Roundup Robot added the comment:

New changeset dab790a17c4d by Serhiy Storchaka in branch '3.3':
Issue #18706: Fix a test for issue #18681 so it no longer breaks test_codeccallbacks*.
http://hg.python.org/cpython/rev/dab790a17c4d

New changeset 1f4aed2c914c by Serhiy Storchaka in branch 'default':
Issue #18706: Fix a test for issue #18681 so it no longer breaks test_codeccallbacks*.
http://hg.python.org/cpython/rev/1f4aed2c914c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18681>
_______________________________________

From report at bugs.python.org  Sun Aug 11 19:14:24 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Aug 2013 17:14:24 +0000
Subject: [issue18706] test failure in test_codeccallbacks
In-Reply-To: <1376179395.42.0.0457635695026.issue18706@psf.upfronthosting.co.za>
Message-ID: <3cCmy76TcHzRMX@mail.python.org>


Roundup Robot added the comment:

New changeset dab790a17c4d by Serhiy Storchaka in branch '3.3':
Issue #18706: Fix a test for issue #18681 so it no longer breaks test_codeccallbacks*.
http://hg.python.org/cpython/rev/dab790a17c4d

New changeset 1f4aed2c914c by Serhiy Storchaka in branch 'default':
Issue #18706: Fix a test for issue #18681 so it no longer breaks test_codeccallbacks*.
http://hg.python.org/cpython/rev/1f4aed2c914c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18706>
_______________________________________

From report at bugs.python.org  Sun Aug 11 19:40:56 2013
From: report at bugs.python.org (Seydou Dia)
Date: Sun, 11 Aug 2013 17:40:56 +0000
Subject: [issue18578] Rename and document test.bytecode_helper as
	test.support.bytecode_helper
In-Reply-To: <1375014946.89.0.0130176350727.issue18578@psf.upfronthosting.co.za>
Message-ID: <1376242856.46.0.017799608356.issue18578@psf.upfronthosting.co.za>


Seydou Dia added the comment:

I am working on a patch.

----------
nosy: +seydou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18578>
_______________________________________

From report at bugs.python.org  Sun Aug 11 19:41:00 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 11 Aug 2013 17:41:00 +0000
Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags
	and seaches
In-Reply-To: <1376237842.14.0.105465889257.issue18304@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda_v5spqHCtRTWywqDnB9JoOd+=2cDv7MMFPMgarfUSqOg@mail.gmail.com>


Eli Bendersky added the comment:

> (although, admittedly, sometimes it's those who designed the XML format
who didn't understand >namespaces ...).

I fully concur. The design of XML, in general, is not the best
demonstration of aesthetics in programming. But namespaces always seem to
me to be one further step in the WTF direction. This is precisely why I
didn't reject this issue right away: perhaps it's not a bad idea to provide
Python programmers with *some* way to ease namespace-related tasks (even if
they go against the questionable design principles behind XML).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18304>
_______________________________________

From report at bugs.python.org  Sun Aug 11 19:56:38 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 11 Aug 2013 17:56:38 +0000
Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output
In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>
Message-ID: <1376243798.92.0.505510694612.issue14465@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14465>
_______________________________________

From report at bugs.python.org  Sun Aug 11 20:22:05 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 11 Aug 2013 18:22:05 +0000
Subject: [issue18702] Report skipped tests as skipped
In-Reply-To: <1376132966.91.0.713996712724.issue18702@psf.upfronthosting.co.za>
Message-ID: <1376245325.09.0.785348034541.issue18702@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The patch applies cleanly on my 3.4 Win 7, fresh debug build. Somewhat fortuitously, as it turns out, I have not downloaded the files needed for ssl support. For each modified file, I ran
python_d -m test -v test_xxx

test test_nntplib crashed -- Traceback (most recent call last):
  File "F:\Python\dev\py34\lib\test\regrtest.py", line 1298, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "F:\Python\dev\py34\lib\importlib\__init__.py", line 93, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1613, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1594, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1561, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 607, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1056, in load_module
  File "<frozen importlib._bootstrap>", line 926, in load_module
  File "<frozen importlib._bootstrap>", line 274, in _call_with_frames_removed
  File "F:\Python\dev\py34\lib\test\test_nntplib.py", line 305, in <module>
    class NetworkedNNTP_SSLTests(NetworkedNNTPTests):
  File "F:\Python\dev\py34\lib\test\test_nntplib.py", line 315, in NetworkedNNTP_SSLTests
    NNTP_CLASS = nntplib.NNTP_SSL
AttributeError: 'module' object has no attribute 'NNTP_SSL'

I do not understand the frozen importlib stuff, but nntplib._have_ssl is False, so the line asking for the non-existent attribute should not be executed.

The problem is that changing a guard from 'if hasattr' to the decorator is a *semantic change* in that it allows execution of the guarded statement. Skips only skip function calling. For a function statement, creating a function object from the compiled code object and binding a name is trivial. Not calling the function is the important part. For a class with code other than function definitions, the difference is crucial, as the above shows.

The general solution is to put class code inside a function so it is only executed later, as part of the test process, rather than during inport.
    @classmethod
    def setUpClass(cls):
        cls.NNTP_CLASS = nntplib.NNTP_SSL

In this case, you could instead guard it with 'if _have_ssl', but since this assignment is the only thing being tested by this test case, it should be inside a method anyway.

I suggest that you review your patch for other changed classes that might have class-level code that could fail with the change to the skip decorator.

Here is similar problem: trying to subclass a class that does not exist.
test test_socketserver crashed
  File "F:\Python\dev\py34\lib\test\test_socketserver.py", line 50, in <module>
    socketserver.UnixStreamServer):
AttributeError: 'module' object has no attribute 'UnixStreamServer'

class ForkingUnixStreamServer(socketserver.ForkingMixIn,
                              socketserver.UnixStreamServer): pass

I think you have to go back to 'if HAVE_UNIX_SOCKETS:' for this. Or re-factor somehow.

---
I cannot help wondering whether test_math.xxx.test_exceptions should still be (normally) disabled. I sent Mark Dickinson a separate note.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18702>
_______________________________________

From report at bugs.python.org  Sun Aug 11 21:15:44 2013
From: report at bugs.python.org (Seydou Dia)
Date: Sun, 11 Aug 2013 19:15:44 +0000
Subject: [issue18576] Rename and document test.script_helper as
	test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1376248544.45.0.601105354669.issue18576@psf.upfronthosting.co.za>


Seydou Dia added the comment:

Since I am already on bugs.python.org/issue18578 I will tackle this issue, if you don't mind.

----------
nosy: +seydou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________

From report at bugs.python.org  Sun Aug 11 21:43:03 2013
From: report at bugs.python.org (Ben Hoyt)
Date: Sun, 11 Aug 2013 19:43:03 +0000
Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, 
	creates wrong mappings
In-Reply-To: <1340813009.36.0.80214060404.issue15207@psf.upfronthosting.co.za>
Message-ID: <1376250183.46.0.275892523503.issue15207@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Thanks, Tim! Works for me! A couple of code review comments:

1) On 2.7, guess_type(s)[0] is a byte string as usual if the type doesn't exist in the registry, but it's a unicode string if it came from the registry. Seems like it should be a byte string in all cases (the mime type can only be ASCII char). I would say .encode('ascii') and if it raises UnicodeError, ignore that key.

2) Would 'subkeyname[0] == "."' be better as subkeyname.startswith(".")? More idiomatic, and won't bomb out if subkeyname is zero length (though that probably can't happen). Relatedly, "not subkeyname.startswith()" with an early-continue would avoid an indent and is what the rest of the code does.

3) I believe the default_encoding variable is not needed anymore. That was used in the old registry code.

4) Super-minor: "raises EnvironmentError" would be the Pythonic way to say "throws EnvironmentError".

5) Would it be worth adding a test for 'foo.png' as well, as that was another super-common type that was wrong?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15207>
_______________________________________

From report at bugs.python.org  Sun Aug 11 22:12:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Aug 2013 20:12:33 +0000
Subject: [issue16968] Fix test discovery for test_concurrent_futures.py
In-Reply-To: <1358201974.23.0.0352259739582.issue16968@psf.upfronthosting.co.za>
Message-ID: <1376251953.45.0.412136910919.issue16968@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think this problem deserves a discussion on Python-Dev: http://comments.gmane.org/gmane.comp.python.devel/141068 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16968>
_______________________________________

From report at bugs.python.org  Sun Aug 11 22:14:57 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 11 Aug 2013 20:14:57 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1373400107.5.0.285657244525.issue18416@psf.upfronthosting.co.za>
Message-ID: <1376252097.88.0.507920141253.issue18416@psf.upfronthosting.co.za>


Brett Cannon added the comment:

To answer Eric's question: yes.

Since no one seems to be screaming that sys.path be the only place to have the concept of a relative path, then let's use only absolute paths except in sys.path for ''.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18416>
_______________________________________

From report at bugs.python.org  Sun Aug 11 23:42:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Aug 2013 21:42:29 +0000
Subject: [issue18702] Report skipped tests as skipped
In-Reply-To: <1376132966.91.0.713996712724.issue18702@psf.upfronthosting.co.za>
Message-ID: <1376257349.13.0.227243418359.issue18702@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Ezio and Terry for review. Here is updated patch. Problems with class initialization solved. I have made a lot of other changes especially in test_os.py and test_posix.py.

----------
Added file: http://bugs.python.org/file31233/skip_tests_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18702>
_______________________________________

From report at bugs.python.org  Mon Aug 12 00:34:04 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 11 Aug 2013 22:34:04 +0000
Subject: [issue18702] Report skipped tests as skipped
In-Reply-To: <1376132966.91.0.713996712724.issue18702@psf.upfronthosting.co.za>
Message-ID: <1376260444.88.0.737948103542.issue18702@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Applies and runs (with text_posix entirely skipped).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18702>
_______________________________________

From report at bugs.python.org  Mon Aug 12 00:44:11 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Aug 2013 22:44:11 +0000
Subject: [issue12645] test.support. import_fresh_module - incorrect doc
In-Reply-To: <1311789815.76.0.639942891335.issue12645@psf.upfronthosting.co.za>
Message-ID: <3cCwGf56PgzSYy@mail.python.org>


Roundup Robot added the comment:

New changeset edaf44136d32 by Eli Bendersky in branch '3.3':
Issue #12645: Clarify and reformat the documentation of import_fresh_module
http://hg.python.org/cpython/rev/edaf44136d32

New changeset d8000009ef0e by Eli Bendersky in branch 'default':
Close #12645: Clarify and reformat the documentation of import_fresh_module
http://hg.python.org/cpython/rev/d8000009ef0e

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12645>
_______________________________________

From report at bugs.python.org  Mon Aug 12 01:10:58 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 11 Aug 2013 23:10:58 +0000
Subject: [issue16799] start using argparse.Namespace in regrtest
In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za>
Message-ID: <1376262658.87.0.996863044691.issue16799@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Chris, I was reading through regrtest.py for other reasons and stumbled upon the pointer to this issue. Would you like to update your patch? I will review it.

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16799>
_______________________________________

From report at bugs.python.org  Mon Aug 12 02:05:23 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 12 Aug 2013 00:05:23 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1376265923.48.0.766350477264.issue18693@psf.upfronthosting.co.za>


Ethan Furman added the comment:

So what do we want Enum's __dir__ to report?

Normally we see things like __eq__, __dict__, __getnewargs__, etc.

For IntEnum there would be __abs__, __floor__, __div__, etc.

Do we want to worry about those kinds of differences?  I think we do.

And if we do, then we are looking at removing items to make our custom __dir__, and with each release we would have to revisit the blacklist of items we don't want (the tests would catch that for us, but it would still be effort to update the code).

What if we took what object.__dir__ gave us, then added the Enum members while removing the private, er, non-public data structures?

In other words, this dir in EnumMeta:

    def __dir__(cls):
        items = set(super().__dir__())
        disgard = set([m for m in items if _is_sunder(m)])
        members = set(cls.__members__)
        return sorted((items | members) ^ disgard)

with this Enum:

>>> class Color(enum.Enum):
...  RED = 1
...  BLUE = 2
...  GREEN = 3
... 

gives us this result:

>>> dir(Color)
['BLUE', 'GREEN', 'RED', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getnewargs__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', 'name', 'value']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Mon Aug 12 03:08:13 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Aug 2013 01:08:13 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
	descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1376269693.42.0.78023004733.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file31234/1f8979a8c2c5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Mon Aug 12 03:10:10 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Aug 2013 01:10:10 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
	descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1376269810.57.0.0425471938689.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file31234/1f8979a8c2c5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Mon Aug 12 03:11:00 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Aug 2013 01:11:00 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
	descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1376269860.72.0.632415164585.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file31235/e4e6f45668c7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Mon Aug 12 03:16:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Aug 2013 01:16:32 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
	descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1376270192.5.0.568445705584.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file31058/c066794c85cd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Mon Aug 12 03:19:13 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Aug 2013 01:19:13 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
	descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1376270353.47.0.282234385603.issue18571@psf.upfronthosting.co.za>


STINNER Victor added the comment:

+    if (make_inheritable(py_fds_to_keep) < 0)
+        goto error;
+    /* errpipe_write is part of py_fds_to_keep. It must be closed at
+       exec(), but kept open in the child process until exec() is called. */
+    if (_Py_set_inheritable((int)errpipe_write, 0, NULL) < 0)
+        goto error;

make_inheritable() should ignore errpipe_write, instead of changing twice the inheritable flag of errpipe_write.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Mon Aug 12 04:23:44 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 12 Aug 2013 02:23:44 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1373400107.5.0.285657244525.issue18416@psf.upfronthosting.co.za>
Message-ID: <1376274224.39.0.660037013063.issue18416@psf.upfronthosting.co.za>


Madison May added the comment:

> I'm currently leaning towards having sys.path_importer_cache store 
> the actual directory name.

Exactly what I meant by "Creating a new entry in sys.path_importer_cache after changing directories and importing a new module", but expressed much more succinctly :)  Good to see we're on pretty much the same page.


Here's a (very) preliminary patch for the issue that stores the directory name as a key in sys.path_importer_cache and ensures module.__file__ is an absolute path. 

I've also modified test_path_importer_cache_empty_string in test_importlib/import_/test_path.py to use os.getcwd() instead of os.curdir as the key for sys.path_importer_cache.

Finally, I've added a test to test_import.py that tests that module.__file__ is equivalent to os.path.abspath(module.__file__).

Look it over when you get a chance and let me know what you would change.  Thanks...

----------
keywords: +patch
Added file: http://bugs.python.org/file31236/Issue18416.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18416>
_______________________________________

From report at bugs.python.org  Mon Aug 12 06:06:43 2013
From: report at bugs.python.org (Bryce Nesbitt)
Date: Mon, 12 Aug 2013 04:06:43 +0000
Subject: [issue18304] ElementTree gets awkward to use if there is an xmlns
In-Reply-To: <1376236403.79.0.981155716557.issue18304@psf.upfronthosting.co.za>
Message-ID: <CAC9LFPemN-OY007sNYAaj4AOyOj-1RC7GMf3ndv_COzM39tJ8Q@mail.gmail.com>


Bryce Nesbitt added the comment:

The mere existence of popular solutions like
'item.tag.split("}")[1][0:]' argues something is wrong.  What could
lmxl do to make this cleaner (even if the ticket proposal is junk).

----------
title: ElementTree -- provide a way to ignore namespace in tags and seaches -> ElementTree gets awkward to use if there is an xmlns

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18304>
_______________________________________

From report at bugs.python.org  Mon Aug 12 06:21:23 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 12 Aug 2013 04:21:23 +0000
Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags
	and seaches
In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za>
Message-ID: <1376281283.4.0.794899634525.issue18304@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Please leave the title as it is now.

----------
title: ElementTree gets awkward to use if there is an xmlns -> ElementTree -- provide a way to ignore namespace in tags and seaches

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18304>
_______________________________________

From report at bugs.python.org  Mon Aug 12 06:27:21 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Aug 2013 04:27:21 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1376281641.98.0.15313942567.issue16038@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I suppose this is fine for 2.7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Mon Aug 12 06:32:57 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Aug 2013 04:32:57 +0000
Subject: [issue18660] os.read behavior on Linux
In-Reply-To: <1375692451.71.0.0379690285011.issue18660@psf.upfronthosting.co.za>
Message-ID: <1376281977.05.0.541092141896.issue18660@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Can you please explain what the bug is in Python; that is, what exactly was wrong with os.read?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18660>
_______________________________________

From report at bugs.python.org  Mon Aug 12 06:34:27 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 12 Aug 2013 04:34:27 +0000
Subject: [issue18304] ElementTree -- provide a way to ignore namespace in tags
	and seaches
In-Reply-To: <1372218497.28.0.26294900817.issue18304@psf.upfronthosting.co.za>
Message-ID: <1376282067.66.0.210422265341.issue18304@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

As I already suggested for lxml, you can use the QName class to process qualified names, e.g.

    QName(some_element.tag).localname

Or even just

    QName(some_element).localname

It appears that ElementTree doesn't support this. It lists the QName type as "opaque". However, it does provide a "text" attribute that contains the qualified tag name.

http://docs.python.org/2/library/xml.etree.elementtree.html#xml.etree.ElementTree.QName

Here is the corresponding documentation from lxml:

http://lxml.de/api/lxml.etree.QName-class.html

QName instances in lxml provide the properties "localname", "namespace" and "text".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18304>
_______________________________________

From report at bugs.python.org  Mon Aug 12 06:51:13 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Aug 2013 04:51:13 +0000
Subject: [issue18660] os.read behavior on Linux
In-Reply-To: <1375692451.71.0.0379690285011.issue18660@psf.upfronthosting.co.za>
Message-ID: <1376283073.75.0.743798705668.issue18660@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

This is not a Python bug. Linux is just not accepting "0" as a valid size argument to read(). You don't see this using libc.read because you don't check errno. Just don't call os.read() if size == 0.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18660>
_______________________________________

From report at bugs.python.org  Mon Aug 12 06:53:22 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Aug 2013 04:53:22 +0000
Subject: [issue18644] Got ResourceWarning: unclosed file when using test
	function from formatter module
In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za>
Message-ID: <1376283202.36.0.159523598326.issue18644@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Please wrap the "businesss" part of the test function in a try... finally. Otherwise the patch looks good.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18644>
_______________________________________

From report at bugs.python.org  Mon Aug 12 06:57:17 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 12 Aug 2013 04:57:17 +0000
Subject: [issue18702] Report skipped tests as skipped
In-Reply-To: <1376132966.91.0.713996712724.issue18702@psf.upfronthosting.co.za>
Message-ID: <1376283437.11.0.288352352627.issue18702@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

I read the patch. It looks good.

Anyway, I have two questions:

1. I saw 3 variants of writing description for skipping test descriptor:

requires os.mkfifo

test needs socket.inet_pton()

needs os.read

Which one is the preferred way to go? "requires" or "test needs" or "needs"? Or it does not matter?

2. I saw 2 variants of writing the function name required for running the test.

test needs socket.inet_pton()

test needs socket.inet_pton

Which one is the preferred way to go? With or without parentheses? Or it does not matter?

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18702>
_______________________________________

From report at bugs.python.org  Mon Aug 12 07:50:01 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Aug 2013 05:50:01 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a traceback
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1376286601.44.0.566710731019.issue16396@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Smells like a new feature to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Mon Aug 12 08:11:17 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 12 Aug 2013 06:11:17 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1376287877.52.0.357178476984.issue18693@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Huh.  I just checked `help(Color)` on my proposed __dir__ and got the two-line, rather useless, response.  Perhaps help() is broken with all custom __dir__s.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Mon Aug 12 09:18:27 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 12 Aug 2013 07:18:27 +0000
Subject: [issue18644] Got ResourceWarning: unclosed file when using test
	function from formatter module
In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za>
Message-ID: <1376291907.31.0.621832693615.issue18644@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Thanks, Benjamin, for reviewing my patch.

Attached the fourth patch to wrap the "business" part inside the try ... finally.

----------
Added file: http://bugs.python.org/file31237/formatter_fix_resource_warning_v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18644>
_______________________________________

From report at bugs.python.org  Mon Aug 12 09:32:11 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Aug 2013 07:32:11 +0000
Subject: [issue18644] Got ResourceWarning: unclosed file when using test
	function from formatter module
In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za>
Message-ID: <1376292731.48.0.288423161847.issue18644@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

That will fail if fp is not assigned before an exception is raised. I mostly mean the part starting with the for loop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18644>
_______________________________________

From report at bugs.python.org  Mon Aug 12 10:15:54 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 12 Aug 2013 08:15:54 +0000
Subject: [issue18644] Got ResourceWarning: unclosed file when using test
	function from formatter module
In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za>
Message-ID: <1376295354.07.0.582254094913.issue18644@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Ah, sorry about that.

Attached the fifth patch to only wrap "for loop" section inside the try... finally.

----------
Added file: http://bugs.python.org/file31238/formatter_fix_resource_warning_v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18644>
_______________________________________

From report at bugs.python.org  Mon Aug 12 11:21:06 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Aug 2013 09:21:06 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376299266.28.0.996817159396.issue18606@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

About the implementation of sum: it's worth noting that the algorithm you're using for floats depends on correct rounding of addition and subtraction, and that that's not guaranteed.  See the existing test (testFsum) in test_math for more information, and note that that test is skipped on machines that don't do correct rounding.

This isn't an uncommon problem:  last time I looked, most 32-bit Linux systems had problems with double rounding, thanks to evaluating first to 64-bit precision using the x87 FPU, and then rounding to 53-bit precision as usual.  (Python builds on 64-bit Linux tend to use the SSE2 instructions in preference to the x87, so don't suffer from this problem.)

Steven: any thoughts about how to deal with this?  Options are (1) just ignore the problem and hope no-one runs into it, (2) document it / warn about it, (3) try to fix it.  Fixing it would be reasonably easy for a C implementation (with access to the FPU control word, in the same way that our float<->string conversion already does), but not so easy in Python without switching algorithm altogether.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Aug 12 11:29:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Aug 2013 09:29:21 +0000
Subject: [issue18702] Report skipped tests as skipped
In-Reply-To: <1376132966.91.0.713996712724.issue18702@psf.upfronthosting.co.za>
Message-ID: <1376299761.75.0.0774924053884.issue18702@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Which one is the preferred way to go? "requires" or "test needs" or "needs"? Or it does not matter?

I used the wording which used in other skips in the same file or in similar skips in other files. If it matters I will correct messages.

> Which one is the preferred way to go? With or without parentheses? Or it does not matter?

Thank you for note. I will add missed parentheses to function names.

There are existing skip messages which uses function names without parentheses. I left them untouched (the patch already is a large enough).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18702>
_______________________________________

From report at bugs.python.org  Mon Aug 12 11:35:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Aug 2013 09:35:06 +0000
Subject: [issue16799] start using argparse.Namespace in regrtest
In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za>
Message-ID: <1376300106.54.0.0884265711713.issue16799@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue17974.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16799>
_______________________________________

From report at bugs.python.org  Mon Aug 12 11:46:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Aug 2013 09:46:08 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1376300768.07.0.842060998741.issue16038@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Error message "got more than %d bytes" is misleading because in most cases (except storlines()) we read not bytes but a text string.

There are 4 changes in the ftplib module but only one of them covered by test.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Mon Aug 12 12:32:04 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Aug 2013 10:32:04 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376303524.96.0.421655446674.issue18606@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

>From the code:

    # Also, like all dunder methods, we should call
    # __float__ on the class, not the instance.

Why?  I've never encountered this recommendation before.  x.__float__() would be clearer, IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Aug 12 12:53:17 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Aug 2013 10:53:17 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376304797.89.0.80372483375.issue18606@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Why?  I've never encountered this recommendation before.  x.__float__() > would be clearer, IMO.

Hmm;  it would be better if I engaged by brain before commenting.  I guess the point is that type(x).__float__(x) better matches the behaviour of the builtin float:


>>> class A:
...     def __float__(self): return 42.0
... 
>>> a = A()
>>> a.__float__ = lambda: 1729.0
>>> 
>>> float(a)
42.0
>>> a.__float__()
1729.0
>>> type(a).__float__(a)
42.0


When you get around to tests, it would be nice to have a test for this behaviour, just so that someone who comes along and wonders the code is written this way gets an immediate test failure when they try to incorrectly "simplify" it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Aug 12 12:55:03 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Aug 2013 10:55:03 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376304903.57.0.217483806377.issue18606@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

(We don't seem to care too much about the distinction in general, though:  there are a good few places in the std. lib. where obj.__index__() is used instead of the more correct type(obj).__index__(obj).)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Aug 12 13:21:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 11:21:33 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1376306493.92.0.62013150729.issue3526@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

PEP 445 allows you to customize the Python memory allocators, which is a better solution than shipping several ones with Python ;-)

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Mon Aug 12 13:22:20 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 12 Aug 2013 11:22:20 +0000
Subject: [issue18394] cgi.FieldStorage triggers ResourceWarning sometimes
In-Reply-To: <1373190601.25.0.575768158618.issue18394@psf.upfronthosting.co.za>
Message-ID: <1376306540.5.0.50590461443.issue18394@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

It happens because if the length of data is more than 1000:

    def __write(self, line):
        """line is always bytes, not string"""
        if self.__file is not None:
            if self.__file.tell() + len(line) > 1000:
                self.file = self.make_file()
                data = self.__file.getvalue()
                self.file.write(data)
                self.__file = None
        ......

it will create a temporary file.

Attached the patch to close the temporary file in the destructor method.

About the 1000 number, should we put it in constant? Why 1000? This number is so random. For now, I just leave it as it is.

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file31239/fix_resource_warning_in_test_cgi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18394>
_______________________________________

From report at bugs.python.org  Mon Aug 12 13:25:08 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 12 Aug 2013 11:25:08 +0000
Subject: [issue18700] test_cgi raises ResourceWarning
In-Reply-To: <1376101556.78.0.0722365020142.issue18700@psf.upfronthosting.co.za>
Message-ID: <1376306708.48.0.792872264044.issue18700@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Superseded by bug #18394.

Should we close this one by marking it as duplicate?

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18700>
_______________________________________

From report at bugs.python.org  Mon Aug 12 13:25:49 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 11:25:49 +0000
Subject: [issue12075] python3.2 memory leak when reloading class with
	attributes
In-Reply-To: <1305357392.12.0.709817768407.issue12075@psf.upfronthosting.co.za>
Message-ID: <1376306749.48.0.559661155714.issue12075@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yes, __del__ will interfere with garbage collection before Python 3.4. This is pretty much expected (and is fixed in Python 3.4, but won't be backported).

----------
nosy: +pitrou
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12075>
_______________________________________

From report at bugs.python.org  Mon Aug 12 13:25:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 11:25:53 +0000
Subject: [issue12075] python3.2 memory leak when reloading class with
	attributes
In-Reply-To: <1305357392.12.0.709817768407.issue12075@psf.upfronthosting.co.za>
Message-ID: <1376306753.65.0.24024296657.issue12075@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution: wont fix -> out of date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12075>
_______________________________________

From report at bugs.python.org  Mon Aug 12 13:26:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 11:26:45 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
	locals and globals when they are not wanted
Message-ID: <1376306805.17.0.499204188054.issue1565525@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> We need maybe an helper to clear all frames referenced by a traceback?

Yes. Something in the traceback module would be fine.

----------
components: +Library (Lib) -Interpreter Core
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Mon Aug 12 13:32:52 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 12 Aug 2013 11:32:52 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
	subjectAltNames general names (CVE-2013-4073)
Message-ID: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Ryan Sleevi of the Google Chrome Security Team has informed us that Python's SSL module doesn't handle NULL bytes inside subjectAltNames general names. It's related to Ruby's CVE-2013-4073 http://www.ruby-lang.org/en/news/2013/06/27/hostname-check-bypassing-vulnerability-in-openssl-client-cve-2013-4073/

Although Python uses a slightly different OpenSSL API to parse a X.509 certificate and turn its fields into a dictionary, our implementation eventually uses an OpenSSL function that fails to handle NULL bytes. This could lead to a breach when an application uses ssl.match_hostname() to match the hostname againt the certificate's subjectAltName's dNSName general names.

When the Ruby issues was announced publicly I already suspected that our code may suffer from the same issue. But I was unable to generate a X.509 certificate with a NULL byte in its X509v3 subjectAltName extension, only in subject and issuer. OpenSSL's config file format just didn't support NULL bytes. But Our code handled the NULL byte in subject in issuer just fine so I gave up. In the light of the bug report I went a different path and eventually I came up with a malicious certificate that showed the reported bug.

----------
components: Extension Modules
messages: 194944
nosy: christian.heimes
priority: critical
severity: normal
stage: patch review
status: open
title: SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4073)
type: security
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Mon Aug 12 13:34:13 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 12 Aug 2013 11:34:13 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
	subjectAltNames general names (CVE-2013-4073)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376307253.51.0.181471302294.issue18709@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Demo certificate:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, ST=Oregon, L=Beaverton, O=Python Software Foundation, OU=Python Core Development, CN=null.python.org\x00example.org/emailAddress=python-dev at python.org
        Validity
            Not Before: Aug  7 13:11:52 2013 GMT
            Not After : Aug  7 13:12:52 2013 GMT
        Subject: C=US, ST=Oregon, L=Beaverton, O=Python Software Foundation, OU=Python Core Development, CN=null.python.org\x00example.org/emailAddress=python-dev at python.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b5:ea:ed:c9:fb:46:7d:6f:3b:76:80:dd:3a:f3:
                    03:94:0b:a7:a6:db:ec:1d:df:ff:23:74:08:9d:97:
                    16:3f:a3:a4:7b:3e:1b:0e:96:59:25:03:a7:26:e2:
                    88:a9:cf:79:cd:f7:04:56:b0:ab:79:32:6e:59:c1:
                    32:30:54:eb:58:a8:cb:91:f0:42:a5:64:27:cb:d4:
                    56:31:88:52:ad:cf:bd:7f:f0:06:64:1f:cc:27:b8:
                    a3:8b:8c:f3:d8:29:1f:25:0b:f5:46:06:1b:ca:02:
                    45:ad:7b:76:0a:9c:bf:bb:b9:ae:0d:16:ab:60:75:
                    ae:06:3e:9c:7c:31:dc:92:2f:29:1a:e0:4b:0c:91:
                    90:6c:e9:37:c5:90:d7:2a:d7:97:15:a3:80:8f:5d:
                    7b:49:8f:54:30:d4:97:2c:1c:5b:37:b5:ab:69:30:
                    68:43:d3:33:78:4b:02:60:f5:3c:44:80:a1:8f:e7:
                    f0:0f:d1:5e:87:9e:46:cf:62:fc:f9:bf:0c:65:12:
                    f1:93:c8:35:79:3f:c8:ec:ec:47:f5:ef:be:44:d5:
                    ae:82:1e:2d:9a:9f:98:5a:67:65:e1:74:70:7c:cb:
                    d3:c2:ce:0e:45:49:27:dc:e3:2d:d4:fb:48:0e:2f:
                    9e:77:b8:14:46:c0:c4:36:ca:02:ae:6a:91:8c:da:
                    2f:85
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                88:5A:55:C0:52:FF:61:CD:52:A3:35:0F:EA:5A:9C:24:38:22:F7:5C
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Subject Alternative Name:
                *************************************************************
                WARNING: The values for DNS, email and URI are WRONG. OpenSSL
                         doesn't print the text after a NULL byte.
                *************************************************************
                DNS:altnull.python.org, email:null at python.org, URI:http://null.python.org, IP Address:192.0.2.1, IP Address:2001:DB8:0:0:0:0:0:1
    Signature Algorithm: sha1WithRSAEncryption
         ac:4f:45:ef:7d:49:a8:21:70:8e:88:59:3e:d4:36:42:70:f5:
         a3:bd:8b:d7:a8:d0:58:f6:31:4a:b1:a4:a6:dd:6f:d9:e8:44:
         3c:b6:0a:71:d6:7f:b1:08:61:9d:60:ce:75:cf:77:0c:d2:37:
         86:02:8d:5e:5d:f9:0f:71:b4:16:a8:c1:3d:23:1c:f1:11:b3:
         56:6e:ca:d0:8d:34:94:e6:87:2a:99:f2:ae:ae:cc:c2:e8:86:
         de:08:a8:7f:c5:05:fa:6f:81:a7:82:e6:d0:53:9d:34:f4:ac:
         3e:40:fe:89:57:7a:29:a4:91:7e:0b:c6:51:31:e5:10:2f:a4:
         60:76:cd:95:51:1a:be:8b:a1:b0:fd:ad:52:bd:d7:1b:87:60:
         d2:31:c7:17:c4:18:4f:2d:08:25:a3:a7:4f:b7:92:ca:e2:f5:
         25:f1:54:75:81:9d:b3:3d:61:a2:f7:da:ed:e1:c6:6f:2c:60:
         1f:d8:6f:c5:92:05:ab:c9:09:62:49:a9:14:ad:55:11:cc:d6:
         4a:19:94:99:97:37:1d:81:5f:8b:cf:a3:a8:96:44:51:08:3d:
         0b:05:65:12:eb:b6:70:80:88:48:72:4f:c6:c2:da:cf:cd:8e:
         5b:ba:97:2f:60:b4:96:56:49:5e:3a:43:76:63:04:be:2a:f6:
         c1:ca:a9:94

The correct values are:

(('DNS', 'altnull.python.org\x00example.com'),
 ('email', 'null at python.org\x00user at example.org'),
 ('URI', 'http://null.python.org\x00http://example.org'),
 ('IP Address', '192.0.2.1'),
 ('IP Address', '2001:DB8:0:0:0:0:0:1\n'))

----------
Added file: http://bugs.python.org/file31240/nullbytecert.pem

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Mon Aug 12 13:34:31 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 12 Aug 2013 11:34:31 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
	subjectAltNames general names (CVE-2013-4073)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376307271.89.0.560038295317.issue18709@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31241/CVE-2013-4073_py34.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Mon Aug 12 13:34:49 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 12 Aug 2013 11:34:49 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
	subjectAltNames general names (CVE-2013-4073)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376307289.91.0.0872595645645.issue18709@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


Added file: http://bugs.python.org/file31242/CVE-2013-4073_py33.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Mon Aug 12 13:35:06 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 12 Aug 2013 11:35:06 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
	subjectAltNames general names (CVE-2013-4073)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376307306.2.0.182411252933.issue18709@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


Added file: http://bugs.python.org/file31243/CVE-2013-4073_py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Mon Aug 12 13:37:39 2013
From: report at bugs.python.org (Martijn Pieters)
Date: Mon, 12 Aug 2013 11:37:39 +0000
Subject: [issue18644] Got ResourceWarning: unclosed file when using test
	function from formatter module
In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za>
Message-ID: <1376307459.28.0.156812088992.issue18644@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

> The formatter module was deprecated? When?

It wasn't, that's the point I am raising. The `formatter` module was exclusively used by the `htmllib` module, I am surprised the `formatter` module wasn't part of that deprecation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18644>
_______________________________________

From report at bugs.python.org  Mon Aug 12 13:42:31 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Aug 2013 11:42:31 +0000
Subject: [issue18644] Got ResourceWarning: unclosed file when using test
	function from formatter module
In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za>
Message-ID: <1376307751.48.0.735613715404.issue18644@psf.upfronthosting.co.za>


R. David Murray added the comment:

Pydoc uses DumbWriter.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18644>
_______________________________________

From report at bugs.python.org  Mon Aug 12 14:11:20 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Aug 2013 12:11:20 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a traceback
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1376309480.35.0.803170349404.issue16396@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Even if the patch is applied only on 3.4, I would still like to see the ValueError turned into ImportError for 2.7/3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Mon Aug 12 14:40:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 12:40:41 +0000
Subject: [issue18710] Add PyState_GetModuleAttr
Message-ID: <1376311241.36.0.528101018546.issue18710@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Attached patch adds PyState_GetModuleAttr() and converts the _csv module to use it (as an example).

As you can see, the _csv module grows a little but it now has proper error handling (previously, it didn't check for PyState_FindModule() returning NULL).

(A few lines would be removed if we added PyErr_FormatV as well...)

----------
components: Extension Modules, Interpreter Core
files: getmodattr.patch
keywords: patch
messages: 194949
nosy: eli.bendersky, loewis, ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Add PyState_GetModuleAttr
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31244/getmodattr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18710>
_______________________________________

From report at bugs.python.org  Mon Aug 12 14:47:57 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 12 Aug 2013 12:47:57 +0000
Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not
	match IDNA prefix
In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za>
Message-ID: <1376311677.06.0.356846809399.issue17997@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Ryan Sleevi of the Google Chrome Security Team has informed us about another issue that is caused by our failure to implement RFC 6125 wildcard matching rules. RFC 6125 allows only one wildcard in the left-most fragment of a hostname. For security reasons matching rules like *.*.com should be not supported.

For wildcards in internationalized domain names I have followed  	the piece of advice "In the face of ambiguity, refuse the temptation to guess.". A substring wildcard does no longer match an IDN A-label fragment. '*' still matches a full punycode fragment but 'x*' no longer matches 'xn--foo'. I copied the idea from Chrome's matching code:

http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/x509_certificate.cc?revision=212341#l640

        // * must not match a substring of an IDN A label; just a whole fragment.
        if (reference_host.starts_with("xn--") &&
        !(pattern_begin.empty() && pattern_end.empty()))
        continue;

The relevant RFC section for the patch are

  http://tools.ietf.org/html/rfc6125#section-6.4.3
  http://tools.ietf.org/html/rfc2818#section-3.1
  http://tools.ietf.org/html/rfc2459#section-4.2.1.7
  http://tools.ietf.org/html/rfc5280#section-7

----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.2
Added file: http://bugs.python.org/file31245/match_hostname_RFC6125.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17997>
_______________________________________

From report at bugs.python.org  Mon Aug 12 14:47:59 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 12 Aug 2013 12:47:59 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1376311679.76.0.00533308624673.issue18693@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Ethan, please revert your commit first. I liked the previous dir. The current one is useless.

I think you may be right about help, but I didn't dig deep enough to be sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Mon Aug 12 14:50:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 12:50:04 +0000
Subject: [issue18711] Add PyErr_FormatV
Message-ID: <1376311803.97.0.992272560955.issue18711@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

PyErr_FormatV can be useful to write third-party helper functions. Patch attached.

----------
components: Interpreter Core
files: pyerr_formatv.patch
keywords: patch
messages: 194952
nosy: pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Add PyErr_FormatV
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31246/pyerr_formatv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18711>
_______________________________________

From report at bugs.python.org  Mon Aug 12 14:50:28 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Aug 2013 12:50:28 +0000
Subject: [issue18710] Add PyState_GetModuleAttr
In-Reply-To: <1376311241.36.0.528101018546.issue18710@psf.upfronthosting.co.za>
Message-ID: <1376311828.36.0.77818361864.issue18710@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I don't understand your change. Why do we need to change the _csv module and why storing module global variables in the module dict is better than storing them in a simple C structure?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18710>
_______________________________________

From report at bugs.python.org  Mon Aug 12 14:51:27 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 12 Aug 2013 12:51:27 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1376311887.67.0.261455356095.issue18693@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Mon Aug 12 14:51:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 12:51:43 +0000
Subject: [issue18710] Add PyState_GetModuleAttr
In-Reply-To: <1376311828.36.0.77818361864.issue18710@psf.upfronthosting.co.za>
Message-ID: <1502198225.57987303.1376311897170.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> I don't understand your change. Why do we need to change the _csv
> module and why storing module global variables in the module dict is
> better than storing them in a simple C structure?

I won't repeat what was already said in the python-dev thread:
http://mail.python.org/pipermail/python-dev/2013-August/127862.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18710>
_______________________________________

From report at bugs.python.org  Mon Aug 12 14:53:21 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Aug 2013 12:53:21 +0000
Subject: [issue18711] Add PyErr_FormatV
In-Reply-To: <1376311803.97.0.992272560955.issue18711@psf.upfronthosting.co.za>
Message-ID: <1376312001.43.0.0374054972639.issue18711@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18711>
_______________________________________

From report at bugs.python.org  Mon Aug 12 14:55:21 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 12 Aug 2013 12:55:21 +0000
Subject: [issue18710] Add PyState_GetModuleAttr
In-Reply-To: <1376311241.36.0.528101018546.issue18710@psf.upfronthosting.co.za>
Message-ID: <1376312121.03.0.933477407569.issue18710@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The patch contains the new function and a patch for the CSV module. How about you split it up across two patches: one for the new feature and one for the CSV module? It makes review easier.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18710>
_______________________________________

From report at bugs.python.org  Mon Aug 12 14:56:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 12:56:51 +0000
Subject: [issue18710] Add PyState_GetModuleAttr
In-Reply-To: <1376311241.36.0.528101018546.issue18710@psf.upfronthosting.co.za>
Message-ID: <1376312211.29.0.873138819992.issue18710@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Bundling the two was aimed at showcasing the effect the new function can have. The function itself is trivial, there's not much point in reviewing it alone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18710>
_______________________________________

From report at bugs.python.org  Mon Aug 12 15:01:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Aug 2013 13:01:31 +0000
Subject: [issue18710] Add PyState_GetModuleAttr
In-Reply-To: <1376311241.36.0.528101018546.issue18710@psf.upfronthosting.co.za>
Message-ID: <1376312491.98.0.263740078555.issue18710@psf.upfronthosting.co.za>


STINNER Victor added the comment:

+PyObject *
+PyState_GetModuleAttr(struct PyModuleDef *def,
+                      const char *name,
+                      PyObject *restrict_type)

When the char* type is used, the function has usually the suffix String. I prefer the PyIdentifier API because it avoids to create a temporary Python Unicode object.

It's the first type that I see a function getting an attribute which also checks for its type. I don't know if the check should be done in PyState_GetModuleAttr() or in the _csv module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18710>
_______________________________________

From report at bugs.python.org  Mon Aug 12 15:02:36 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Aug 2013 13:02:36 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
	subjectAltNames general names (CVE-2013-4073)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376312556.79.0.20746742448.issue18709@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Does it really make sense to allow to open a certificate containing a NUL byte in its name? How does OpenSSL and other projects handle this case?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Mon Aug 12 15:08:07 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 12 Aug 2013 13:08:07 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
	subjectAltNames general names (CVE-2013-4073)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376312887.03.0.216500033573.issue18709@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Mon Aug 12 15:14:14 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 12 Aug 2013 13:14:14 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
	subjectAltNames general names (CVE-2013-4073)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376313254.64.0.104436386224.issue18709@psf.upfronthosting.co.za>


Christian Heimes added the comment:

OpenSSL's print() functions fail to handle the NULL byte in subjectAltName (SAN) general names as they use strlen() or printf() functions with "%s" format char. The subject and issuer elements with NULL bytes are handled correctly by OpenSSL.

wget and curl combine CN / SAN parsing and hostname matching in one function. Both report an error when they see a NULL byte in a dNSName (strlen(dNSName) != lengtt of ASN1_STRING).

Python has separate functions for retrieving the X.509 information and matching a hostname against CN / SAN. I like to keep it that way and just for our parsing code in this bug. Latter ssl.match_hostname() can check for NULL bytes and raise an exception, but that's a different issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Mon Aug 12 15:27:38 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 12 Aug 2013 13:27:38 +0000
Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not
	match IDNA prefix
In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za>
Message-ID: <1376314058.1.0.759041237145.issue17997@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17997>
_______________________________________

From report at bugs.python.org  Mon Aug 12 15:51:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 13:51:16 +0000
Subject: [issue18710] Add PyState_GetModuleAttr
In-Reply-To: <1376312491.98.0.263740078555.issue18710@psf.upfronthosting.co.za>
Message-ID: <679873878.58089234.1376315470377.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> When the char* type is used, the function has usually the suffix
> String. I prefer the PyIdentifier API because it avoids to create a
> temporary Python Unicode object.

This is a convenience API, not a performance "optimization".

> It's the first type that I see a function getting an attribute which
> also checks for its type. I don't know if the check should be done
> in PyState_GetModuleAttr() or in the _csv module.

The aim is to help writing extension modules, which is why the type
check is done inside the helper function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18710>
_______________________________________

From report at bugs.python.org  Mon Aug 12 15:51:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Aug 2013 13:51:48 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <3cDJPw0VQNz7Lkj@mail.python.org>


Roundup Robot added the comment:

New changeset 39697dcd97e3 by Ethan Furman in branch 'default':
Issue 18693: Put custom __dir__ back in place.  Will instead look at fixing `help()`.
http://hg.python.org/cpython/rev/39697dcd97e3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Mon Aug 12 15:55:27 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 12 Aug 2013 13:55:27 +0000
Subject: [issue18710] Add PyState_GetModuleAttr
In-Reply-To: <1376311241.36.0.528101018546.issue18710@psf.upfronthosting.co.za>
Message-ID: <1376315727.21.0.914891851376.issue18710@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

The patched code looks better than the original one in several respects, but I think it raises some questions.

I agree with Victor that the type-checking API is unnatural, but I also think there may be a deeper issue hiding behind. You felt compelled to add the type-checking to provide some level of safety to the C code - but is it enough? Previously, the only way to add a dialect was through register_dialect that does type checking to make sure it gets a legit dialect object. Now, the _dialects dict is directly accessible to Python code and it can add arbitrary objects to it (both as keys and as values). Does this mean that the C code now has to do type checking in all internal code that accesses _dialects? I haven't had time to find a crasher example, but it's plausible that it's possible to crash the interpreter now by assigning un-expected stuff to members of _dialects.

Maybe it's not a problem in practice for _csv but something worth thinking about if we're going to switch other methods to this approach.

Also, the problem with http://mail.python.org/pipermail/python-dev/2013-August/127862.html does not go away with this patch, as expected. However, it's a step in the right direction in case we do have multiple instances of the extension module alive at the same time in the future. Although then it would be interesting to consider how to find the actually correct module instance from internal functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18710>
_______________________________________

From report at bugs.python.org  Mon Aug 12 16:00:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 14:00:18 +0000
Subject: [issue18710] Add PyState_GetModuleAttr
In-Reply-To: <1376311241.36.0.528101018546.issue18710@psf.upfronthosting.co.za>
Message-ID: <1376316018.51.0.588335277736.issue18710@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Previously, the only way to add a dialect was through register_dialect that does
> type checking to make sure it gets a legit dialect object. Now, the _dialects dict is 
> directly accessible to Python code and it can add arbitrary objects to it (both as
> keys and as values). Does this mean that the C code now has to do type checking in all 
> internal code that accesses _dialects?

You are right, I forgot about that part. That will make the patch significantly more complicated.

> However, it's a step in the right direction in case we do have multiple instances of
> the extension module alive at the same time in the future. Although then it would be
> interesting to consider how to find the actually correct module instance from internal 
> functions.

This sounds basically impossible (which is why we *can't* have multiple instances of an extension module alive in a single interpreter :-)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18710>
_______________________________________

From report at bugs.python.org  Mon Aug 12 16:07:46 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 12 Aug 2013 14:07:46 +0000
Subject: [issue18710] Add PyState_GetModuleAttr
In-Reply-To: <1376316018.51.0.588335277736.issue18710@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda_XonAh2XAe0rQii-1_SHUkTOo+8PwWwHpX50MtgBesuA@mail.gmail.com>


Eli Bendersky added the comment:

> Previously, the only way to add a dialect was through register_dialect
that does

>  > type checking to make sure it gets a legit dialect object. Now, the
> _dialects dict is
> > directly accessible to Python code and it can add arbitrary objects to
> it (both as
> > keys and as values). Does this mean that the C code now has to do type
> checking in all
> > internal code that accesses _dialects?
>
> You are right, I forgot about that part. That will make the patch
> significantly more complicated.
>

:-/

Turns out there's real merit in having a clear dividing line between the
safe world of Python and unsafe world of C. Within the C code, some
invariants are assumed to be correct (and can be efficiently assert()-ed) -
this makes the code simpler and more performant.

> > However, it's a step in the right direction in case we do have multiple
> instances of
> > the extension module alive at the same time in the future. Although then
> it would be
> > interesting to consider how to find the actually correct module instance
> from internal
> > functions.
>
> This sounds basically impossible (which is why we *can't* have multiple
> instances of an extension module alive in a single interpreter :-)).
>

Well, it surely isn't possible without significant code rewriting. But I
can envision carrying such "state" around in extension-specific objects.
Although it's not entirely clear whether the memory cost is justified.

But without it, it's not clear to me how we plan to have multiple living
extension modules at all. Perhaps this is a discussion outside this
specific issue though (maybe for the PEP Stefan writes)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18710>
_______________________________________

From report at bugs.python.org  Mon Aug 12 16:08:35 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Aug 2013 14:08:35 +0000
Subject: [issue18710] Add PyState_GetModuleAttr
In-Reply-To: <1376316018.51.0.588335277736.issue18710@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eiS70NkqsOOOTfCfAFUwgpSa41=QWOWpqd7LCfxqbkRg@mail.gmail.com>


Nick Coghlan added the comment:

Breaking the 1:1 interpreter <-> extension module mapping involves
adding custom types to sys.modules rather than module objects. Making
that work sensibly will involve larger changes to the extension
initialisation APIs. import-sig already has plans for this :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18710>
_______________________________________

From report at bugs.python.org  Mon Aug 12 16:09:38 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Aug 2013 14:09:38 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
Message-ID: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

Nitpick: the pure Python version of operator.index (new in Python 3.4, introduced in issue #16694) doesn't match the C version, in that it looks up __index__ on the object rather than the class.


iwasawa:cpython mdickinson$ ./python.exe
Python 3.4.0a1+ (default:9e61563edb67+, Aug 12 2013, 14:45:12) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from test import support
>>> py_operator = support.import_fresh_module('operator', blocked=['_operator'])
>>> c_operator = support.import_fresh_module('operator', fresh=['_operator'])
>>> class A(int): pass
... 
>>> a = A(42); a.__index__ = lambda: 1729
>>> 
>>> py_operator.index(a)
1729
>>> c_operator.index(a)
42

----------
components: Extension Modules
messages: 194966
nosy: mark.dickinson, zach.ware
priority: normal
severity: normal
status: open
title: Pure Python operator.index doesn't match the C version.
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Mon Aug 12 16:43:22 2013
From: report at bugs.python.org (Louis Riviere)
Date: Mon, 12 Aug 2013 14:43:22 +0000
Subject: [issue18660] os.read behavior on Linux
In-Reply-To: <1375692451.71.0.0379690285011.issue18660@psf.upfronthosting.co.za>
Message-ID: <1376318602.15.0.733146532292.issue18660@psf.upfronthosting.co.za>


Louis Riviere added the comment:

Thanks Benjamin !
I should have known that "Python doesn't break things" :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18660>
_______________________________________

From report at bugs.python.org  Mon Aug 12 17:19:34 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Aug 2013 15:19:34 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
	appropriate
Message-ID: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

One problem with Unicode in 3.x is that surrogateescape isn't normally enabled on stdin and stdout. This means the following code will fail with UnicodeEncodeError in the presence of invalid filesystem metadata:

    print(os.listdir())

We don't really want to enable surrogateescape on sys.stdin or sys.stdout unilaterally, as it increases the chance of data corruption errors when the filesystem encoding and the IO encodings don't match.

Last night, Toshio and I thought of a possible solution: enable surrogateescape by default for sys.stdin and sys.stdout on non-Windows systems if (and only if) they're using the same codec as that returned by sys.getfilesystemencoding() (allowing for codec aliases rather than doing a simple string comparison)

This means that for full UTF-8 systems (which includes most modern Linux installations), roundtripping will be enabled by default between the standard streams and OS facing APIs, while systems where the encodings don't match will still fail noisily.

A more general alternative is also possible: default to errors='surrogatescape' for *any* text stream that uses the filesystem encoding. It's primarily the standard streams we're interested in fixing, though.

----------
messages: 194968
nosy: abadger1999, benjamin.peterson, ezio.melotti, haypo, lemburg, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Enable surrogateescape on stdin and stdout when appropriate
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Mon Aug 12 17:38:56 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Aug 2013 15:38:56 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
	appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1376321936.66.0.266177255433.issue18713@psf.upfronthosting.co.za>


R. David Murray added the comment:

My gut reaction to this is that it feels dangerous.  That doesn't mean my gut is right, I'm just reporting my reaction :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Mon Aug 12 17:45:47 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Aug 2013 15:45:47 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
	appropriate
In-Reply-To: <1376321936.66.0.266177255433.issue18713@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eFY19Az6f6e=eNBTh8+WTgaVttu7HNDN7MRHVUyGb1Hw@mail.gmail.com>


Nick Coghlan added the comment:

Everything about surrogateescape is dangerous - we're trying to work
around the presence of bad data by at least allowing it to be
tunnelled through Python code without corrupting it further :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Mon Aug 12 18:15:11 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 Aug 2013 16:15:11 +0000
Subject: [issue18367] See if a venv setup can be used for devinabox for
	coverage
In-Reply-To: <1373051739.1.0.739747420449.issue18367@psf.upfronthosting.co.za>
Message-ID: <1376324111.52.0.44775000624.issue18367@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18367>
_______________________________________

From report at bugs.python.org  Mon Aug 12 18:15:34 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 Aug 2013 16:15:34 +0000
Subject: [issue18451] Omit test files in devinabox coverage run
In-Reply-To: <1373815169.93.0.694766443004.issue18451@psf.upfronthosting.co.za>
Message-ID: <1376324134.84.0.431593364616.issue18451@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18451>
_______________________________________

From report at bugs.python.org  Mon Aug 12 19:16:05 2013
From: report at bugs.python.org (Derek Wilson)
Date: Mon, 12 Aug 2013 17:16:05 +0000
Subject: [issue18689] add argument for formatter to logging.Handler and
	subclasses in logging module
In-Reply-To: <1375992937.35.0.58426954587.issue18689@psf.upfronthosting.co.za>
Message-ID: <1376327765.17.0.481681682107.issue18689@psf.upfronthosting.co.za>


Derek Wilson added the comment:

dictConfig and fileConfig are nice for static needs, but when I want to quickly enable a complex (but not complicated) logging flow I find it just as tedious as the current situation with the direct API.

> ... as at the very least every handler would need to be changed to accommodate the new kwarg

Adding a keyword only argument to the base handler and the other handler classes is a nearly trivial change in terms of lines and complexity of the code.

> Also, this isn't going to work for third-party handlers which are out there already, since they won't necessarily recognise a new kwarg.

I don't see that as a problem. If 3rd party handlers are intelligent then they will include **kargs in their __init__ and pass that forward to the initialization of their parent. If they haven't done so then nothing changes for them and they just support exactly the same features they supported previously.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18689>
_______________________________________

From report at bugs.python.org  Mon Aug 12 19:19:41 2013
From: report at bugs.python.org (Seydou Dia)
Date: Mon, 12 Aug 2013 17:19:41 +0000
Subject: [issue18578] Rename and document test.bytecode_helper as
	test.support.bytecode_helper
In-Reply-To: <1375014946.89.0.0130176350727.issue18578@psf.upfronthosting.co.za>
Message-ID: <1376327981.54.0.789112803512.issue18578@psf.upfronthosting.co.za>


Seydou Dia added the comment:

I have a hard time figuring out what exactly BytecodeTestCase methods actually do. Thus the documentation is not probably accurate.

----------
keywords: +patch
Added file: http://bugs.python.org/file31247/issue-18578.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18578>
_______________________________________

From report at bugs.python.org  Mon Aug 12 19:29:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Aug 2013 17:29:21 +0000
Subject: [issue18598] Importlib, more verbosity please
In-Reply-To: <1375180244.43.0.821767780261.issue18598@psf.upfronthosting.co.za>
Message-ID: <3cDPDw29mlzMnM@mail.python.org>


Roundup Robot added the comment:

New changeset 2294594fbe6c by Brett Cannon in branch 'default':
Closes issue #18598: Have the exception message for
http://hg.python.org/cpython/rev/2294594fbe6c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18598>
_______________________________________

From report at bugs.python.org  Mon Aug 12 19:29:45 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 Aug 2013 17:29:45 +0000
Subject: [issue18598] Importlib, more verbosity please
In-Reply-To: <1375180244.43.0.821767780261.issue18598@psf.upfronthosting.co.za>
Message-ID: <1376328585.34.0.824339812145.issue18598@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18598>
_______________________________________

From report at bugs.python.org  Mon Aug 12 19:48:11 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 Aug 2013 17:48:11 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
	ancillary data
In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>
Message-ID: <1376329691.75.0.681801388754.issue12837@psf.upfronthosting.co.za>


Brett Cannon added the comment:

This is still a warning and so I'm still looking for a solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12837>
_______________________________________

From report at bugs.python.org  Mon Aug 12 19:50:03 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Aug 2013 17:50:03 +0000
Subject: [issue18667] missing HAVE_FCHOWNAT
In-Reply-To: <1375772087.0.0.361755653525.issue18667@psf.upfronthosting.co.za>
Message-ID: <3cDPhp3CyGzSVJ@mail.python.org>


Roundup Robot added the comment:

New changeset a89226508a04 by Larry Hastings in branch '3.3':
Issue #18667: Add missing "HAVE_FCHOWNAT" symbol to posix._have_functions.
http://hg.python.org/cpython/rev/a89226508a04

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18667>
_______________________________________

From report at bugs.python.org  Mon Aug 12 19:53:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Aug 2013 17:53:36 +0000
Subject: [issue18667] missing HAVE_FCHOWNAT
In-Reply-To: <1375772087.0.0.361755653525.issue18667@psf.upfronthosting.co.za>
Message-ID: <3cDPmw2KblzSVJ@mail.python.org>


Roundup Robot added the comment:

New changeset 92de1a5dc3ea by Larry Hastings in branch 'default':
Issue #18667: Add missing "HAVE_FCHOWNAT" symbol to posix._have_functions.
http://hg.python.org/cpython/rev/92de1a5dc3ea

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18667>
_______________________________________

From report at bugs.python.org  Mon Aug 12 19:55:12 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 12 Aug 2013 17:55:12 +0000
Subject: [issue18667] missing HAVE_FCHOWNAT
In-Reply-To: <1375772087.0.0.361755653525.issue18667@psf.upfronthosting.co.za>
Message-ID: <1376330112.72.0.873805577777.issue18667@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Fixed in 3.3 and trunk.  Thanks for the report!

----------
assignee:  -> larry
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18667>
_______________________________________

From report at bugs.python.org  Mon Aug 12 20:02:57 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 12 Aug 2013 18:02:57 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1373400107.5.0.285657244525.issue18416@psf.upfronthosting.co.za>
Message-ID: <1376330577.04.0.163017270954.issue18416@psf.upfronthosting.co.za>


Madison May added the comment:

Here's a minor revision to that patch removing an unnecessary @skip_if_dont_write_bytecode decorator from the test I added to test_import.py.  

No docs changes are included in the current patch -- I'm guessing this should probably wait until we have all the other details ironed out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18416>
_______________________________________

From report at bugs.python.org  Mon Aug 12 20:03:57 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 12 Aug 2013 18:03:57 +0000
Subject: [issue18416] Move to absolute file paths for module.__file__
In-Reply-To: <1373400107.5.0.285657244525.issue18416@psf.upfronthosting.co.za>
Message-ID: <1376330637.22.0.591534805358.issue18416@psf.upfronthosting.co.za>


Changes by Madison May <madison.may at students.olin.edu>:


Added file: http://bugs.python.org/file31248/Issue18416_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18416>
_______________________________________

From report at bugs.python.org  Mon Aug 12 20:13:49 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 12 Aug 2013 18:13:49 +0000
Subject: [issue18700] test_cgi raises ResourceWarning
In-Reply-To: <1376101556.78.0.0722365020142.issue18700@psf.upfronthosting.co.za>
Message-ID: <1376331229.56.0.577403646138.issue18700@psf.upfronthosting.co.za>


Madison May added the comment:

Good catch, Vajrasky.  I'll close the issue and add my brief report to bug #18394.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18700>
_______________________________________

From report at bugs.python.org  Mon Aug 12 20:16:30 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 12 Aug 2013 18:16:30 +0000
Subject: [issue18394] cgi.FieldStorage triggers ResourceWarning sometimes
In-Reply-To: <1373190601.25.0.575768158618.issue18394@psf.upfronthosting.co.za>
Message-ID: <1376331390.18.0.16540433723.issue18394@psf.upfronthosting.co.za>


Madison May added the comment:

I ran into a similar issue (see #18700) with test_cgi.

``/home/mmay/cpython/Lib/test/test_cgi.py:276: ResourceWarning: unclosed file <_io.BufferedRandom name=3>``

----------
nosy: +madison.may

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18394>
_______________________________________

From report at bugs.python.org  Mon Aug 12 20:23:30 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 18:23:30 +0000
Subject: [issue1666318] shutil.copytree doesn't give control over directory
	permissions
Message-ID: <1376331810.61.0.397578268054.issue1666318@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Hey Catherine,
Do you want to update your patch to include Vajrasky's suggestion?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1666318>
_______________________________________

From report at bugs.python.org  Mon Aug 12 20:26:21 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 12 Aug 2013 18:26:21 +0000
Subject: [issue18694] getxattr on Linux ZFS native filesystem happily returns
	partial values
In-Reply-To: <1376024133.74.0.379846700659.issue18694@psf.upfronthosting.co.za>
Message-ID: <1376331981.37.0.77382384395.issue18694@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Attached is an updated patch, this time for 3.3.  (So I'm guessing we won't get a "review" link.)  It incorporates Benjamin's two comments.

----------
Added file: http://bugs.python.org/file31249/larry.setxattr.zfs.3.3.patch.1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18694>
_______________________________________

From report at bugs.python.org  Mon Aug 12 20:37:18 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Aug 2013 18:37:18 +0000
Subject: [issue18694] getxattr on Linux ZFS native filesystem happily returns
	partial values
In-Reply-To: <1376024133.74.0.379846700659.issue18694@psf.upfronthosting.co.za>
Message-ID: <1376332638.27.0.348060704505.issue18694@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Okay. Hopefully, we can kill that thing one day...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18694>
_______________________________________

From report at bugs.python.org  Mon Aug 12 20:40:22 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 12 Aug 2013 18:40:22 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <CAHVvXxRQvmJUwY5EtzfxZt=O6oyHMOEDbHQLmpVVGAkh+poG_g@mail.gmail.com>
Message-ID: <52092C0D.3080609@pearwood.info>


Steven D'Aprano added the comment:

On 09/08/13 21:49, Oscar Benjamin wrote:

> I think that the argument `m` to variance, pvariance, stdev and pstdev
> should be renamed to `mu` for pvariance/pstdev and `xbar` for
> variance/stdev. The doc-strings should carefully distinguish that `mu`
> is the true/population mean and `xbar` is the estimated/sample mean
> and refer to this difference between the function variants.

Good thinking, and I agree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Aug 12 20:58:20 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Aug 2013 18:58:20 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a traceback
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1376333900.08.0.636671996971.issue16396@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

My sense on the issue is that wintypes was added to the library and was never intended to raise a ValueError on import. By that logic, the behavior is a bug, not a new feature. I agree with Ezio that raising a ValueError on import is a bug. And since the patch not only addresses the ValueError on import, but simply addresses the underlying cause, it seems to me the most obvious solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:05:21 2013
From: report at bugs.python.org (Kevin Jing Qiu)
Date: Mon, 12 Aug 2013 19:05:21 +0000
Subject: [issue18714] Add tests for pdb.find_function
Message-ID: <1376334321.42.0.844383208785.issue18714@psf.upfronthosting.co.za>


New submission from Kevin Jing Qiu:

PyConCA 2013 sprint task

----------
components: Tests
messages: 194986
nosy: Kevin.Jing.Qiu
priority: normal
severity: normal
status: open
title: Add tests for pdb.find_function
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18714>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:15:30 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 19:15:30 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za>
Message-ID: <1376334930.45.0.390640010918.issue18585@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Updated patch renaming summarize() to shorten(), and adding docs and a fix for a nit reported by Vajrasky.

----------
Added file: http://bugs.python.org/file31250/shorten.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18585>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:15:32 2013
From: report at bugs.python.org (Seydou Dia)
Date: Mon, 12 Aug 2013 19:15:32 +0000
Subject: [issue18715] Tests fail when run with coverage
Message-ID: <1376334932.92.0.162234474623.issue18715@psf.upfronthosting.co.za>


New submission from Seydou Dia:

When I run the tests suit with coverage (e.g, ./python COVERAGEDIR run --pylib Lib/test/regrtest.py test_frame), the following tests fails:

 * test_frame
 * test_xml_etree
 * test_threading_local
 * test_super
 * test_importlib

 The tracebacks are available here : http://pastebin.com/j6ScCibV

----------
components: Tests
messages: 194988
nosy: seydou
priority: normal
severity: normal
status: open
title: Tests fail when run with coverage
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18715>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:15:50 2013
From: report at bugs.python.org (Kevin Jing Qiu)
Date: Mon, 12 Aug 2013 19:15:50 +0000
Subject: [issue18714] Add tests for pdb.find_function
In-Reply-To: <1376334321.42.0.844383208785.issue18714@psf.upfronthosting.co.za>
Message-ID: <1376334950.32.0.571443251401.issue18714@psf.upfronthosting.co.za>


Changes by Kevin Jing Qiu <kevin.jing.qiu at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31251/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18714>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:16:08 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 Aug 2013 19:16:08 +0000
Subject: [issue18716] Deprecate the formatter module
Message-ID: <1376334968.93.0.863346638514.issue18716@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Turns out the formatter module isn't really used by anyone. Pydoc uses it, but it could easily use textwrap. Searching on Github shows a usage by someone who simply re-exposes it as part of their own public API but has no actual usage themselves (https://github.com/search?q=%22import+formatter%22&ref=searchresults&type=Code and https://github.com/search?q=%22from+formatter%22&type=Code&ref=searchresults) . A Google search only turns up references in books (https://www.google.ca/search?{google:acceptedSuggestion}oq=%22import+formatter%22&{google:instantFieldTrialGroupParameter}sourceid=chrome&ie=UTF-8&q=%22import+formatter%22&qscrl=1#bav=on.2,or.r_cp.r_qf.&fp=7bfd11bde90d01cb&q=%22import+formatter%22+OR+%22from+formatter%22&qscrl=1).

The attached patch deprecated formatter for removal in Python 3.6.

----------
components: Library (Lib)
files: deprecate_formatter.diff
keywords: patch
messages: 194989
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Deprecate the formatter module
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31252/deprecate_formatter.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18716>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:19:11 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Aug 2013 19:19:11 +0000
Subject: [issue18707] the readme should also talk about how to build doc.
In-Reply-To: <1376203024.02.0.197448582438.issue18707@psf.upfronthosting.co.za>
Message-ID: <1376335151.13.0.340350163214.issue18707@psf.upfronthosting.co.za>


?ric Araujo added the comment:

There is a README in the Doc directory.  Wouldn?t it be enough to point to that file from the main README?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18707>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:20:00 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 12 Aug 2013 19:20:00 +0000
Subject: [issue18694] getxattr on Linux ZFS native filesystem happily returns
	partial values
In-Reply-To: <1376024133.74.0.379846700659.issue18694@psf.upfronthosting.co.za>
Message-ID: <1376335200.31.0.468678269608.issue18694@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Kill what thing?  The review link?  I love that thing?

Anyway, we did get a review link, hoopla!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18694>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:20:18 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 12 Aug 2013 19:20:18 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1376299266.28.0.996817159396.issue18606@psf.upfronthosting.co.za>
Message-ID: <5209356C.3010902@pearwood.info>


Steven D'Aprano added the comment:

On 12/08/13 19:21, Mark Dickinson wrote:

> About the implementation of sum: it's worth noting that the algorithm you're using for floats depends on correct rounding of addition and subtraction, and that that's not guaranteed.
[...]
> Steven: any thoughts about how to deal with this?  Options are (1) just ignore the problem and hope no-one runs into it, (2) document it / warn about it, (3) try to fix it.  Fixing it would be reasonably easy for a C implementation (with access to the FPU control word, in the same way that our float<->string conversion already does), but not so easy in Python without switching algorithm altogether.

Document it and hope :-)

add_partial is no longer documented as a public function, so I'm open to switching algorithms in the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:23:36 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 Aug 2013 19:23:36 +0000
Subject: [issue18716] Deprecate the formatter module
In-Reply-To: <1376334968.93.0.863346638514.issue18716@psf.upfronthosting.co.za>
Message-ID: <1376335416.14.0.228767578789.issue18716@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18716>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:28:20 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Aug 2013 19:28:20 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376335700.53.0.762851518285.issue18606@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Okay, that works.  I agree that not documenting add_partial is probably a good plan.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:30:23 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 12 Aug 2013 19:30:23 +0000
Subject: [issue18689] add argument for formatter to logging.Handler and
	subclasses in logging module
In-Reply-To: <1375992937.35.0.58426954587.issue18689@psf.upfronthosting.co.za>
Message-ID: <1376335823.99.0.925159374513.issue18689@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

> If 3rd party handlers are intelligent

It's not an ideal world. Sorry, but I think this change is too invasive to consider. I can't believe this change is really needed - logging has been around since 2002 and this has never been raised before.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18689>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:33:50 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Aug 2013 19:33:50 +0000
Subject: [issue18716] Deprecate the formatter module
In-Reply-To: <1376334968.93.0.863346638514.issue18716@psf.upfronthosting.co.za>
Message-ID: <1376336030.92.0.641766929729.issue18716@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18716>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:35:06 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 12 Aug 2013 19:35:06 +0000
Subject: [issue18716] Deprecate the formatter module
In-Reply-To: <1376334968.93.0.863346638514.issue18716@psf.upfronthosting.co.za>
Message-ID: <1376336106.38.0.968837280786.issue18716@psf.upfronthosting.co.za>


Larry Hastings added the comment:

+1

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18716>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:36:55 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Mon, 12 Aug 2013 19:36:55 +0000
Subject: [issue18717] test for request.urlretrieve
Message-ID: <1376336214.18.0.793709816185.issue18717@psf.upfronthosting.co.za>


New submission from Muhammad Jehanzeb:

As part of pyconca sprints, this is my first patch for urlcleanup test

----------
components: Tests
files: test_urllib.py
messages: 194996
nosy: mjehanzeb
priority: normal
severity: normal
status: open
title: test for request.urlretrieve
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31253/test_urllib.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18717>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:38:21 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Aug 2013 19:38:21 +0000
Subject: [issue18717] test for request.urlretrieve
In-Reply-To: <1376336214.18.0.793709816185.issue18717@psf.upfronthosting.co.za>
Message-ID: <1376336301.58.0.0701855611441.issue18717@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks for your contribution.  Can you submit this as a diff?

----------
nosy: +ezio.melotti
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18717>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:41:18 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Aug 2013 19:41:18 +0000
Subject: [issue16799] start using argparse.Namespace in regrtest
In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za>
Message-ID: <1376336478.05.0.394143996938.issue16799@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a preliminary patch which get rids of _convert_namespace_to_getopt() and directly uses a Namespace object. Unfortunately it breaks tests because test_regrtest depends on implementation details of the regrtest module and uses _convert_namespace_to_getopt(). If the proposed patch is good enough I will try to write suitable tests.

----------
Added file: http://bugs.python.org/file31254/regrtest_argparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16799>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:43:21 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Mon, 12 Aug 2013 19:43:21 +0000
Subject: [issue18717] test for request.urlretrieve
In-Reply-To: <1376336214.18.0.793709816185.issue18717@psf.upfronthosting.co.za>
Message-ID: <1376336601.83.0.52421424553.issue18717@psf.upfronthosting.co.za>


Muhammad Jehanzeb added the comment:

the patch fie

----------
keywords: +patch
Added file: http://bugs.python.org/file31255/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18717>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:43:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Aug 2013 19:43:38 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376336618.2.0.937383921981.issue18712@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

We can use type(a).__index__(a). Should we also correct the documentation for operator.index() and operator.length_hint()?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:43:42 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Mon, 12 Aug 2013 19:43:42 +0000
Subject: [issue18717] test for request.urlretrieve
In-Reply-To: <1376336214.18.0.793709816185.issue18717@psf.upfronthosting.co.za>
Message-ID: <1376336622.09.0.271182740478.issue18717@psf.upfronthosting.co.za>


Changes by Muhammad Jehanzeb <mjehanzeb at gmail.com>:


Removed file: http://bugs.python.org/file31253/test_urllib.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18717>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:51:22 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Aug 2013 19:51:22 +0000
Subject: [issue17701] Improving strftime documentation
In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>
Message-ID: <3cDSNn3Hs4zSdF@mail.python.org>


Roundup Robot added the comment:

New changeset adbc9789a5e4 by David Wolever in branch '2.7':
Issue #17701: Improving strftime documentation
http://hg.python.org/cpython/rev/adbc9789a5e4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17701>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:51:57 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Aug 2013 19:51:57 +0000
Subject: [issue18707] the readme should also talk about how to build doc.
In-Reply-To: <1376203024.02.0.197448582438.issue18707@psf.upfronthosting.co.za>
Message-ID: <1376337117.37.0.771687784681.issue18707@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

+1

----------
type:  -> enhancement
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18707>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:58:22 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Mon, 12 Aug 2013 19:58:22 +0000
Subject: [issue18717] test for request.urlretrieve
In-Reply-To: <1376336214.18.0.793709816185.issue18717@psf.upfronthosting.co.za>
Message-ID: <1376337502.95.0.324374593644.issue18717@psf.upfronthosting.co.za>


Muhammad Jehanzeb added the comment:

included issue# in the patch file

----------
Added file: http://bugs.python.org/file31256/issue18717.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18717>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:58:48 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Mon, 12 Aug 2013 19:58:48 +0000
Subject: [issue18717] test for request.urlretrieve
In-Reply-To: <1376336214.18.0.793709816185.issue18717@psf.upfronthosting.co.za>
Message-ID: <1376337528.86.0.253217401596.issue18717@psf.upfronthosting.co.za>


Changes by Muhammad Jehanzeb <mjehanzeb at gmail.com>:


Removed file: http://bugs.python.org/file31255/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18717>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:58:58 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 12 Aug 2013 19:58:58 +0000
Subject: [issue18699] What is Future.running() for in PEP 3148 /
	concurrent.futures.Future?
In-Reply-To: <1376092118.24.0.585945689562.issue18699@psf.upfronthosting.co.za>
Message-ID: <1376337538.51.0.0252768752694.issue18699@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18699>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:59:21 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Mon, 12 Aug 2013 19:59:21 +0000
Subject: [issue18717] test for request.urlretrieve
In-Reply-To: <1376336214.18.0.793709816185.issue18717@psf.upfronthosting.co.za>
Message-ID: <1376337561.83.0.842746974828.issue18717@psf.upfronthosting.co.za>


Changes by Muhammad Jehanzeb <mjehanzeb at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18717>
_______________________________________

From report at bugs.python.org  Mon Aug 12 21:59:50 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Mon, 12 Aug 2013 19:59:50 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <5209356C.3010902@pearwood.info>
Message-ID: <CAHVvXxTKjU8P3aK=t-hQntym8-1XxJZHkO-T_aW75zDkwsKsLQ@mail.gmail.com>


Oscar Benjamin added the comment:

On 12 August 2013 20:20, Steven D'Aprano <report at bugs.python.org> wrote:
> On 12/08/13 19:21, Mark Dickinson wrote:
>> About the implementation of sum:
> add_partial is no longer documented as a public function, so I'm open to switching algorithms in the future.

Along similar lines it might be good to remove the doc-test for using
decimal.ROUND_DOWN. I can't see any good reason for anyone to want
that behaviour when e.g. computing the mean() whereas I can see
reasons for wanting to reduce rounding error for decimal in
statistics.sum. It might be a good idea not to tie yourself to the
guarantee implied by that test.

I tried an alternative implementation of sum() that can also reduce
rounding error with decimals but it failed that test (by making the
result more accurate). Here's the sum() I wrote:

def sum(data, start=0):

    if not isinstance(start, numbers.Number):
        raise TypeError('sum only accepts numbers')

    inexact_types = (float, complex, decimal.Decimal)
    def isexact(num):
        return not isinstance(num, inexact_types)

    if isexact(start):
        exact_total, inexact_total = start, 0
    else:
        exact_total, inexact_total = 0, start

    carrybits = 0

    for x in data:
        if isexact(x):
            exact_total = exact_total + x
        else:
            new_inexact_total = inexact_total + (x + carrybits)
            carrybits = -(((new_inexact_total - inexact_total) - x) - carrybits)
            inexact_total = new_inexact_total

    return (exact_total + inexact_total) + carrybits

It is more accurate for e.g. the following:
    nums = [decimal.Decimal(10 ** n) for n in range(50)]
    nums += [-n for n in reversed(nums)]
    assert sum(nums) == 0

However there will also be other situations where it is less accurate such as
    print(sum([-1e30, +1e60, 1, 3, -1e60, 1e30]))
so it may not be suitable as-is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:05:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 20:05:22 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za>
Message-ID: <1376337922.76.0.824696773103.issue18585@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Updated patch addressing Ezio's comments.

----------
Added file: http://bugs.python.org/file31257/shorten2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18585>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:15:07 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Aug 2013 20:15:07 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376338507.54.0.677344808609.issue18712@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Yes, I think it would make sense to fix the docs as well, at least for Python 3.4.  Probably not worth it for the maintenance releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:15:15 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Aug 2013 20:15:15 +0000
Subject: [issue18715] Tests fail when run with coverage
In-Reply-To: <1376334932.92.0.162234474623.issue18715@psf.upfronthosting.co.za>
Message-ID: <1376338515.37.0.920073728686.issue18715@psf.upfronthosting.co.za>


Ned Deily added the comment:

Please upload the test results as file attachment(s) to this issue.  Files stored elsewhere may disappear.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18715>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:15:50 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 12 Aug 2013 20:15:50 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
In-Reply-To: <1375885327.18.0.790620363467.issue18677@psf.upfronthosting.co.za>
Message-ID: <1376338550.25.0.267178999588.issue18677@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18677>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:29:36 2013
From: report at bugs.python.org (David Wolever)
Date: Mon, 12 Aug 2013 20:29:36 +0000
Subject: [issue18718] datetime documentation contradictory on leap second
	support
Message-ID: <1376339376.74.0.0279691228671.issue18718@psf.upfronthosting.co.za>


New submission from David Wolever:

The documentation for the `%S` formatter suggests that it supports leap seconds, but the footnote contradicts that:

> The range really is 0 to 61; according to the Posix standard this
> accounts for leap seconds and the (very rare) double leap seconds.
> The time module may produce and does accept leap seconds since it is
> based on the Posix standard, but the datetime module does not accept
> leap seconds in strptime() input nor will it produce them in
> strftime() output.

I propose that the documentation be updated to mirror the 3.X documentation: no leap second in the example and a footnote which makes note of that and suggests using the time module.

----------
assignee: wolever
messages: 195008
nosy: wolever
priority: normal
severity: normal
status: open
title: datetime documentation contradictory on leap second support
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18718>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:33:24 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Aug 2013 20:33:24 +0000
Subject: [issue18719] Remove false optimizaton for equality comparison of
	hashed strings
Message-ID: <1376339604.75.0.978082056671.issue18719@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
components: Interpreter Core
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Remove false optimizaton for equality comparison of hashed strings
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18719>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:33:34 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 12 Aug 2013 20:33:34 +0000
Subject: [issue16799] start using argparse.Namespace in regrtest
In-Reply-To: <1376336478.05.0.394143996938.issue16799@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda88q+hy8n=nUMP_vMCsAFwvDFOiHYALVpbpYqdnnff4Nw@mail.gmail.com>


Eli Bendersky added the comment:

On Mon, Aug 12, 2013 at 12:41 PM, Serhiy Storchaka
<report at bugs.python.org>wrote:

>
> Serhiy Storchaka added the comment:
>
> Here is a preliminary patch which get rids of
> _convert_namespace_to_getopt() and directly uses a Namespace object.
> Unfortunately it breaks tests because test_regrtest depends on
> implementation details of the regrtest module and uses
> _convert_namespace_to_getopt(). If the proposed patch is good enough I will
> try to write suitable tests.
>

If test_regrtest is the only test broken by this, it doesn't like a major
problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16799>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:37:45 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 12 Aug 2013 20:37:45 +0000
Subject: [issue16799] start using argparse.Namespace in regrtest
In-Reply-To: <CAF-Rda88q+hy8n=nUMP_vMCsAFwvDFOiHYALVpbpYqdnnff4Nw@mail.gmail.com>
Message-ID: <CAF-Rda84i_wF3k_MpH4hKm9ttN9ewEDLCd4cHHg3uaSMKHDtyw@mail.gmail.com>


Eli Bendersky added the comment:

On Mon, Aug 12, 2013 at 1:33 PM, Eli Bendersky <report at bugs.python.org>wrote:

>
> Eli Bendersky added the comment:
>
> On Mon, Aug 12, 2013 at 12:41 PM, Serhiy Storchaka
> <report at bugs.python.org>wrote:
>
> >
> > Serhiy Storchaka added the comment:
> >
> > Here is a preliminary patch which get rids of
> > _convert_namespace_to_getopt() and directly uses a Namespace object.
> > Unfortunately it breaks tests because test_regrtest depends on
> > implementation details of the regrtest module and uses
> > _convert_namespace_to_getopt(). If the proposed patch is good enough I
> will
> > try to write suitable tests.
> >
>
> If test_regrtest is the only test broken by this, it doesn't like a major
> problem.
>

Something is wrong with the part of my brain that deals with grammar today;
sorry! What I mean to say, in case it's not obvious - is that if this
change breaks no tests except the one that specifically tests regrtest
itself, I don't think there's a reason to worry. test_regrtest can (and
should) be changed not to rely on internals of the module-under-test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16799>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:38:03 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Aug 2013 20:38:03 +0000
Subject: [issue18719] Remove false optimizaton for equality comparison of
	hashed strings
Message-ID: <1376339883.0.0.783356566828.issue18719@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

This code is only run when the kinds, lengths, and hashes match.  So, the probability of the strings being equal is VERY high.  Accordingly, there is no benefit to an earlier out test to see if the first characters differ.

There is a modest benefit to comparing one-character strings, but that comes at the expense of of testing all other string lengths.

This code is on the critical path for dicts and sets, so we don't want to slow it down with false optimizations or optimizations of special cases that come at the expense of the common, general case.

----------
keywords: +patch
Added file: http://bugs.python.org/file31258/eq_optimization.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18719>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:39:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Aug 2013 20:39:19 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za>
Message-ID: <3cDTS65KD8zT0R@mail.python.org>


Roundup Robot added the comment:

New changeset c27ec198d3d1 by Antoine Pitrou in branch 'default':
Issue #18585: Add :func:`textwrap.shorten` to collapse and truncate a piece of text to a given length.
http://hg.python.org/cpython/rev/c27ec198d3d1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18585>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:39:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 20:39:48 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za>
Message-ID: <1376339988.43.0.446396203643.issue18585@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, I've committed after having addressed (most of) RDM's comments.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18585>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:40:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 20:40:22 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za>
Message-ID: <1376340022.12.0.104479238984.issue18585@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18585>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:41:20 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 20:41:20 +0000
Subject: [issue18719] Remove false optimizaton for equality comparison of
	hashed strings
In-Reply-To: <1376339883.0.0.783356566828.issue18719@psf.upfronthosting.co.za>
Message-ID: <1376340080.6.0.369581791452.issue18719@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18719>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:43:16 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 12 Aug 2013 20:43:16 +0000
Subject: [issue18719] Remove false optimizaton for equality comparison of
	hashed strings
In-Reply-To: <1376339883.0.0.783356566828.issue18719@psf.upfronthosting.co.za>
Message-ID: <1376340196.09.0.956449132338.issue18719@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

does this show demonstrable results (in either direction) on stringbench or the benchmarks repo?

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18719>
_______________________________________

From report at bugs.python.org  Mon Aug 12 22:57:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Aug 2013 20:57:31 +0000
Subject: [issue18719] Remove false optimizaton for equality comparison of
	hashed strings
In-Reply-To: <1376339883.0.0.783356566828.issue18719@psf.upfronthosting.co.za>
Message-ID: <1376341051.35.0.41710486892.issue18719@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also issues #16286 and #17628.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18719>
_______________________________________

From report at bugs.python.org  Mon Aug 12 23:05:35 2013
From: report at bugs.python.org (Tim Golden)
Date: Mon, 12 Aug 2013 21:05:35 +0000
Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, 
	creates wrong mappings
In-Reply-To: <1376250183.46.0.275892523503.issue15207@psf.upfronthosting.co.za>
Message-ID: <52094E0D.4000405@timgolden.me.uk>


Tim Golden added the comment:

Thanks for the review, Ben. Updated patches attached.

1 & 3) default_encoding -- Your two points appear to contradict each 
other slightly. What's in the updated patches is: 3.x has no encoding 
(because everything's unicode end-to-end); 2.7 attempts to apply the 
default encoding -- which is probably ascii -- to the extension and the 
mimetype and continues on error. I'm not 100% sure about this because it 
seems possible if unlikely to have a non-ascii extension / mimetype, but 
this seems like the best compromise (and is no worse than what was there 
before). Does that seem to fit the bill?

2) subkeyname[0] -- done

4) "throws EnvironmentError" -- done

5) test for .png -- done

----------
Added file: http://bugs.python.org/file31259/issue15207.27.2.patch
Added file: http://bugs.python.org/file31260/issue15207.33.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15207>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/mimetypes.rst b/Doc/library/mimetypes.rst
--- a/Doc/library/mimetypes.rst
+++ b/Doc/library/mimetypes.rst
@@ -85,6 +85,9 @@
    :const:`knownfiles` takes precedence over those named before it.  Calling
    :func:`init` repeatedly is allowed.
 
+   Specifying an empty list for *files* will prevent the system defaults from
+   being applied: only the well-known values will be present from a built-in list.
+
    .. versionchanged:: 2.7
       Previously, Windows registry settings were ignored.
 
diff --git a/Lib/mimetypes.py b/Lib/mimetypes.py
--- a/Lib/mimetypes.py
+++ b/Lib/mimetypes.py
@@ -254,23 +254,26 @@
                 i += 1
 
         default_encoding = sys.getdefaultencoding()
-        with _winreg.OpenKey(_winreg.HKEY_CLASSES_ROOT,
-                             r'MIME\Database\Content Type') as mimedb:
-            for ctype in enum_types(mimedb):
+        with _winreg.OpenKey(_winreg.HKEY_CLASSES_ROOT, '') as hkcr:
+            for subkeyname in enum_types(hkcr):
                 try:
-                    with _winreg.OpenKey(mimedb, ctype) as key:
-                        suffix, datatype = _winreg.QueryValueEx(key,
-                                                                'Extension')
+                    with _winreg.OpenKey(hkcr, subkeyname) as subkey:
+                        # Only check file extensions
+                        if not subkeyname.startswith("."):
+                            continue
+                        # raises EnvironmentError if no 'Content Type' value
+                        mimetype, datatype = _winreg.QueryValueEx(
+                            subkey, 'Content Type')
+                        if datatype != _winreg.REG_SZ:
+                            continue
+                        try:
+                            mimetype = mimetype.encode(default_encoding)
+                            subkeyname = subkeyname.encode(default_encoding)
+                        except UnicodeEncodeError:
+                            continue
+                        self.add_type(mimetype, subkeyname, strict)
                 except EnvironmentError:
                     continue
-                if datatype != _winreg.REG_SZ:
-                    continue
-                try:
-                    suffix = suffix.encode(default_encoding) # omit in 3.x!
-                except UnicodeEncodeError:
-                    continue
-                self.add_type(ctype, suffix, strict)
-
 
 def guess_type(url, strict=True):
     """Guess the type of a file based on its URL.
diff --git a/Lib/test/test_mimetypes.py b/Lib/test/test_mimetypes.py
--- a/Lib/test/test_mimetypes.py
+++ b/Lib/test/test_mimetypes.py
@@ -85,6 +85,8 @@
         # Use file types that should *always* exist:
         eq = self.assertEqual
         eq(self.db.guess_type("foo.txt"), ("text/plain", None))
+        eq(self.db.guess_type("image.jpg"), ("image/jpeg", None))
+        eq(self.db.guess_type("image.png"), ("image/png", None))
 
 def test_main():
     test_support.run_unittest(MimeTypesTestCase,
-------------- next part --------------
diff --git a/Doc/library/mimetypes.rst b/Doc/library/mimetypes.rst
--- a/Doc/library/mimetypes.rst
+++ b/Doc/library/mimetypes.rst
@@ -85,6 +85,9 @@
    :const:`knownfiles` takes precedence over those named before it.  Calling
    :func:`init` repeatedly is allowed.
 
+   Specifying an empty list for *files* will prevent the system defaults from
+   being applied: only the well-known values will be present from a built-in list.
+
    .. versionchanged:: 3.2
       Previously, Windows registry settings were ignored.
 
diff --git a/Lib/mimetypes.py b/Lib/mimetypes.py
--- a/Lib/mimetypes.py
+++ b/Lib/mimetypes.py
@@ -249,19 +249,21 @@
                     yield ctype
                 i += 1
 
-        with _winreg.OpenKey(_winreg.HKEY_CLASSES_ROOT,
-                             r'MIME\Database\Content Type') as mimedb:
-            for ctype in enum_types(mimedb):
+        with _winreg.OpenKey(_winreg.HKEY_CLASSES_ROOT, '') as hkcr:
+            for subkeyname in enum_types(hkcr):
                 try:
-                    with _winreg.OpenKey(mimedb, ctype) as key:
-                        suffix, datatype = _winreg.QueryValueEx(key,
-                                                                'Extension')
+                    with _winreg.OpenKey(hkcr, subkeyname) as subkey:
+                        # Only check file extensions
+                        if not subkeyname.startswith("."):
+                            continue
+                        # raises EnvironmentError if no 'Content Type' value
+                        mimetype, datatype = _winreg.QueryValueEx(
+                            subkey, 'Content Type')
+                        if datatype != _winreg.REG_SZ:
+                            continue
+                        self.add_type(mimetype, subkeyname, strict)
                 except EnvironmentError:
                     continue
-                if datatype != _winreg.REG_SZ:
-                    continue
-                self.add_type(ctype, suffix, strict)
-
 
 def guess_type(url, strict=True):
     """Guess the type of a file based on its URL.
diff --git a/Lib/test/test_mimetypes.py b/Lib/test/test_mimetypes.py
--- a/Lib/test/test_mimetypes.py
+++ b/Lib/test/test_mimetypes.py
@@ -98,7 +98,8 @@
         # Use file types that should *always* exist:
         eq = self.assertEqual
         eq(self.db.guess_type("foo.txt"), ("text/plain", None))
-
+        eq(self.db.guess_type("image.jpg"), ("image/jpeg", None))
+        eq(self.db.guess_type("image.png"), ("image/png", None))
 
 def test_main():
     support.run_unittest(MimeTypesTestCase,

From report at bugs.python.org  Mon Aug 12 23:09:34 2013
From: report at bugs.python.org (David Wolever)
Date: Mon, 12 Aug 2013 21:09:34 +0000
Subject: [issue18718] datetime documentation contradictory on leap second
	support
In-Reply-To: <1376339376.74.0.0279691228671.issue18718@psf.upfronthosting.co.za>
Message-ID: <1376341774.49.0.783760491297.issue18718@psf.upfronthosting.co.za>


David Wolever added the comment:

Here's the relevant diff. Will commit on a +1.

diff --git a/Doc/library/datetime.rst b/Doc/library/datetime.rst
--- a/Doc/library/datetime.rst
+++ b/Doc/library/datetime.rst
@@ -1664,7 +1664,7 @@
 | ``%M``    | Minute as a zero-padded        | 00, 01, ..., 59        |       |
 |           | decimal number.                |                        |       |
 +-----------+--------------------------------+------------------------+-------+
-| ``%S``    | Second as a zero-padded        | 00, 01, ..., 61        | \(3)  |
+| ``%S``    | Second as a zero-padded        | 00, 01, ..., 59        | \(3)  |
 |           | decimal number.                |                        |       |
 +-----------+--------------------------------+------------------------+-------+
 | ``%f``    | Microsecond as a decimal       | 000000, 000001, ...,   | \(4)  |
@@ -1728,12 +1728,8 @@
    the output hour field if the ``%I`` directive is used to parse the hour.
 
 (3)
-   The range really is ``0`` to ``61``; according to the Posix standard this
-   accounts for leap seconds and the (very rare) double leap seconds.
-   The :mod:`time` module may produce and does accept leap seconds since
-   it is based on the Posix standard, but the :mod:`datetime` module
-   does not accept leap seconds in :meth:`strptime` input nor will it
-   produce them in :func:`strftime` output.
+   Unlike the :mod:`time` module, the :mod:`datetime` module does not support
+   leap seconds.
 
 (4)
    ``%f`` is an extension to the set of format characters in the C standard

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18718>
_______________________________________

From report at bugs.python.org  Mon Aug 12 23:10:49 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 12 Aug 2013 21:10:49 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
Message-ID: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

As part of original plan and since issue #18264 has been resolved, it's time to dust off some old patches I have for the socket.* module. The socket.AF_* and socket.SOCK_* constants are good candidates for IntEnum conversion.

I'm attaching an initial patch that handles socket.AF_* (as a proof-of-concept; socket.SOCK_* should get identical treatment); it only touches Lib/socket.py and all regrtest tests pass without changes. Result:

>>> import socket
>>> socket.AF_INET
<AddressFamily.AF_INET: 2>
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.family
<AddressFamily.AF_INET: 2>
>>> '{}'.format(s.family)
'AddressFamily.AF_INET'

The code in the patch is pretty well commented, and I also want to point out a couple of decision points that came up:

1. The underlying socketmodule.c has no idea of IntEnums, and neither IMHO it should. These constants are essentially one-way, going from Python into C. They are only exposed back through read-only accessors (e.g. s.family above), at which point the Python code can wrap them back into the enum. The alternative, making socketmodule.c use enums is probably way more complicated than really necessary.
2. As a followup to (1), the constants are actually wrapped into an IntEnum at the Python level and exposed back to the user. My hacking of globals() there may be a bit rough - suggestions for a better way are welcome.
3. A bunch of AF_* constants exported by Python built on my x64 Ubuntu are not documented in socket.rst; I'm still wrapping them all in enums; I basically went over all PyModule_AddIntMacro(m, AF_*) in PyInit__socket.

PTAL

----------
assignee: eli.bendersky
components: Library (Lib)
files: socket-intenum-af.1.patch
keywords: patch
messages: 195018
nosy: barry, eli.bendersky, ethan.furman, gvanrossum, ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Switch suitable constants in the socket module to IntEnum
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31261/socket-intenum-af.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Mon Aug 12 23:15:52 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Aug 2013 21:15:52 +0000
Subject: [issue17701] Improving strftime documentation
In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>
Message-ID: <3cDVGH4HCzzMnM@mail.python.org>


Roundup Robot added the comment:

New changeset 1d4b02d8fa8a by David Wolever in branch '3.3':
Issue #17701: Improving strftime documentation.
http://hg.python.org/cpython/rev/1d4b02d8fa8a

New changeset ab550dac6209 by David Wolever in branch 'default':
Merge issue #17701: Improving strftime documentation.
http://hg.python.org/cpython/rev/ab550dac6209

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17701>
_______________________________________

From report at bugs.python.org  Mon Aug 12 23:22:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Aug 2013 21:22:11 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za>
Message-ID: <1376342531.01.0.377875701825.issue18585@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What about a multiline summarize? The textwrap module is designed to work with multiline text.

Let we want wrap 'Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.' in 40 column and shorten it to three lines:

Lorem ipsum dolor sit amet, consectetur
adipisicing elit, sed do eiusmod tempor
incididunt ut labore et dolore (...)

For this we need to add two arguments for TextWrapper: max_lines and placeholder. Then shorten() will be just fill() with max_lines=1.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18585>
_______________________________________

From report at bugs.python.org  Mon Aug 12 23:23:46 2013
From: report at bugs.python.org (David Wolever)
Date: Mon, 12 Aug 2013 21:23:46 +0000
Subject: [issue17701] Improving strftime documentation
In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>
Message-ID: <1376342626.76.0.537594762375.issue17701@psf.upfronthosting.co.za>


David Wolever added the comment:

Done, pushed to 2.7, 3.3, default.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17701>
_______________________________________

From report at bugs.python.org  Mon Aug 12 23:38:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Aug 2013 21:38:42 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376343522.93.0.852453697808.issue18720@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Mon Aug 12 23:42:59 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Aug 2013 21:42:59 +0000
Subject: [issue18694] getxattr on Linux ZFS native filesystem happily returns
	partial values
In-Reply-To: <1376332638.27.0.348060704505.issue18694@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o8MGAc-wfNgHtStUs6iBemxApouUcni9maO3VFz07Bb+Q@mail.gmail.com>


Benjamin Peterson added the comment:

No, this extra code you're adding. :)

2013/8/12 Benjamin Peterson <report at bugs.python.org>:
>
> Benjamin Peterson added the comment:
>
> Okay. Hopefully, we can kill that thing one day...
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue18694>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18694>
_______________________________________

From report at bugs.python.org  Mon Aug 12 23:43:36 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Mon, 12 Aug 2013 21:43:36 +0000
Subject: [issue18721] test for FTP cwd function
Message-ID: <1376343816.8.0.615732489322.issue18721@psf.upfronthosting.co.za>


New submission from Muhammad Jehanzeb:

Test coverage for cwd function of ftplib directory.

----------
components: Tests
messages: 195023
nosy: mjehanzeb
priority: normal
severity: normal
status: open
title: test for FTP cwd function
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18721>
_______________________________________

From report at bugs.python.org  Mon Aug 12 23:46:13 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 21:46:13 +0000
Subject: [issue18722] Remove uses of the register keyword
Message-ID: <1376343971.9.0.52964508892.issue18722@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Attached patch removes all uses of the C "register" keyword in the CPython sources.

----------
components: Interpreter Core
files: remove_register.patch
keywords: patch
messages: 195024
nosy: pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Remove uses of the register keyword
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31262/remove_register.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18722>
_______________________________________

From report at bugs.python.org  Mon Aug 12 23:46:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 21:46:47 +0000
Subject: [issue18722] Remove uses of the register keyword
In-Reply-To: <1376343971.9.0.52964508892.issue18722@psf.upfronthosting.co.za>
Message-ID: <1376344007.56.0.944089169127.issue18722@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The benchmark suite doesn't show any significant speedup or slowdown generally:

Report on Linux fsol 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:17:05 UTC 2013 x86_64 x86_64
Total CPU cores: 4

### django_v2 ###
Min: 0.672909 -> 0.659464: 1.02x faster
Avg: 0.673821 -> 0.660258: 1.02x faster
Significant (t=32.72)
Stddev: 0.00071 -> 0.00060: 1.1869x smaller

### fastunpickle ###
Min: 0.578535 -> 0.593218: 1.03x slower
Avg: 0.578700 -> 0.593440: 1.03x slower
Significant (t=-185.83)
Stddev: 0.00011 -> 0.00014: 1.1950x larger

### float ###
Min: 0.309679 -> 0.302615: 1.02x faster
Avg: 0.312457 -> 0.304713: 1.03x faster
Significant (t=4.33)
Stddev: 0.00326 -> 0.00232: 1.4039x smaller

### go ###
Min: 0.602035 -> 0.578129: 1.04x faster
Avg: 0.604634 -> 0.581584: 1.04x faster
Significant (t=12.50)
Stddev: 0.00253 -> 0.00325: 1.2855x larger

### nqueens ###
Min: 0.309602 -> 0.316767: 1.02x slower
Avg: 0.310222 -> 0.317734: 1.02x slower
Significant (t=-21.22)
Stddev: 0.00057 -> 0.00055: 1.0295x smaller

### richards ###
Min: 0.184306 -> 0.178887: 1.03x faster
Avg: 0.184969 -> 0.180215: 1.03x faster
Significant (t=8.40)
Stddev: 0.00076 -> 0.00101: 1.3380x larger

### silent_logging ###
Min: 0.080233 -> 0.073160: 1.10x faster
Avg: 0.080594 -> 0.073170: 1.10x faster
Significant (t=69.28)
Stddev: 0.00024 -> 0.00001: 21.7820x smaller

### threaded_count ###
Min: 0.234882 -> 0.226954: 1.03x faster
Avg: 0.241049 -> 0.231458: 1.04x faster
Significant (t=3.04)
Stddev: 0.00567 -> 0.00420: 1.3519x smaller

### unpack_sequence ###
Min: 0.000046 -> 0.000048: 1.05x slower
Avg: 0.000046 -> 0.000049: 1.06x slower
Significant (t=-299.85)
Stddev: 0.00000 -> 0.00000: 1.0256x larger

The following not significant results are hidden, use -v to show them:
call_method, call_method_slots, call_method_unknown, call_simple, chaos, fannkuch, fastpickle, formatted_logging, iterative_count, json_dump_v2, json_load, meteor_contest, nbody, normal_startup, pathlib, pidigits, raytrace, regex_compile, regex_effbot, regex_v8, simple_logging, spectral_norm, startup_nosite, telco.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18722>
_______________________________________

From report at bugs.python.org  Mon Aug 12 23:47:04 2013
From: report at bugs.python.org (Felix Crux)
Date: Mon, 12 Aug 2013 21:47:04 +0000
Subject: [issue18680] JSONDecoder should document that it raises a ValueError
	for malformed data
In-Reply-To: <1375913191.45.0.0174536581066.issue18680@psf.upfronthosting.co.za>
Message-ID: <1376344024.97.0.67779187711.issue18680@psf.upfronthosting.co.za>


Felix Crux added the comment:

Working with wolever on the process, generated the attached patch.

----------
keywords: +patch
nosy: +felixc, wolever
Added file: http://bugs.python.org/file31263/18680.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18680>
_______________________________________

From report at bugs.python.org  Mon Aug 12 23:55:41 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 12 Aug 2013 21:55:41 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376344541.69.0.0716314639147.issue18720@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Attaching updated patch answering Ethan's review. Also added a tiny sanity test that makes sure that AF_INET is indeed an enum. A more comprehensive test probably won't hurt for the final patch.

----------
Added file: http://bugs.python.org/file31264/socket-intenum-af.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Mon Aug 12 23:59:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 21:59:22 +0000
Subject: [issue18722] Remove uses of the register keyword
In-Reply-To: <1376343971.9.0.52964508892.issue18722@psf.upfronthosting.co.za>
Message-ID: <1376344762.05.0.0191611071641.issue18722@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +mark.dickinson, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18722>
_______________________________________

From report at bugs.python.org  Tue Aug 13 00:00:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 22:00:51 +0000
Subject: [issue18722] Remove uses of the register keyword
In-Reply-To: <1376343971.9.0.52964508892.issue18722@psf.upfronthosting.co.za>
Message-ID: <1376344851.26.0.0890221551897.issue18722@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(amusingly, the two Python executables generated by gcc - with or without register - have exactly the same size, although their md5 hashes differ)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18722>
_______________________________________

From report at bugs.python.org  Tue Aug 13 00:05:08 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Aug 2013 22:05:08 +0000
Subject: [issue18722] Remove uses of the register keyword
In-Reply-To: <1376343971.9.0.52964508892.issue18722@psf.upfronthosting.co.za>
Message-ID: <1376345108.67.0.677813398915.issue18722@psf.upfronthosting.co.za>


STINNER Victor added the comment:

+1 for removal of the register keyword.

I hope that nowadays, no compiler needs register hint to be able to optimize correctly a function. GCC knows better than me which variables must be "optimized".

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18722>
_______________________________________

From report at bugs.python.org  Tue Aug 13 00:09:53 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Mon, 12 Aug 2013 22:09:53 +0000
Subject: [issue18721] test for FTP cwd function
In-Reply-To: <1376343816.8.0.615732489322.issue18721@psf.upfronthosting.co.za>
Message-ID: <1376345393.65.0.624819140733.issue18721@psf.upfronthosting.co.za>


Changes by Muhammad Jehanzeb <mjehanzeb at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31265/issue18721.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18721>
_______________________________________

From report at bugs.python.org  Tue Aug 13 00:10:26 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Mon, 12 Aug 2013 22:10:26 +0000
Subject: [issue18721] test for FTP cwd function
In-Reply-To: <1376343816.8.0.615732489322.issue18721@psf.upfronthosting.co.za>
Message-ID: <1376345426.03.0.948636934682.issue18721@psf.upfronthosting.co.za>


Changes by Muhammad Jehanzeb <mjehanzeb at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18721>
_______________________________________

From report at bugs.python.org  Tue Aug 13 00:11:54 2013
From: report at bugs.python.org (Eric Snow)
Date: Mon, 12 Aug 2013 22:11:54 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1376345514.24.0.0482640488447.issue5516@psf.upfronthosting.co.za>


Eric Snow added the comment:

This bit me today (under 2.7).

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Tue Aug 13 00:13:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Aug 2013 22:13:38 +0000
Subject: [issue18680] JSONDecoder should document that it raises a ValueError
	for malformed data
In-Reply-To: <1375913191.45.0.0174536581066.issue18680@psf.upfronthosting.co.za>
Message-ID: <3cDWXy0G5zzMfc@mail.python.org>


Roundup Robot added the comment:

New changeset f11683963558 by Felix Crux in branch 'default':
Documenting that json.load may raise a ValueError.
http://hg.python.org/cpython/rev/f11683963558

New changeset 905fad4cb40a by Felix Crux in branch 'default':
Documenting that json.load may raise a ValueError.
http://hg.python.org/cpython/rev/905fad4cb40a

New changeset 7ba77d77b499 by Felix Crux in branch 'default':
Documenting that json.load may raise a ValueError.
http://hg.python.org/cpython/rev/7ba77d77b499

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18680>
_______________________________________

From report at bugs.python.org  Tue Aug 13 00:15:21 2013
From: report at bugs.python.org (David Wolever)
Date: Mon, 12 Aug 2013 22:15:21 +0000
Subject: [issue18680] JSONDecoder should document that it raises a ValueError
	for malformed data
In-Reply-To: <1375913191.45.0.0174536581066.issue18680@psf.upfronthosting.co.za>
Message-ID: <1376345721.93.0.430548784982.issue18680@psf.upfronthosting.co.za>


Changes by David Wolever <david at wolever.net>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18680>
_______________________________________

From report at bugs.python.org  Tue Aug 13 00:23:39 2013
From: report at bugs.python.org (Ben Hoyt)
Date: Mon, 12 Aug 2013 22:23:39 +0000
Subject: [issue15207] mimetypes.read_windows_registry() uses the wrong regkey, 
	creates wrong mappings
In-Reply-To: <1340813009.36.0.80214060404.issue15207@psf.upfronthosting.co.za>
Message-ID: <1376346219.33.0.533472139068.issue15207@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

All looks great. I like what you've done with default_encoding now. Thanks, Tim (and Dave for the original report).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15207>
_______________________________________

From report at bugs.python.org  Tue Aug 13 00:28:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Aug 2013 22:28:26 +0000
Subject: [issue18680] JSONDecoder should document that it raises a ValueError
	for malformed data
In-Reply-To: <1375913191.45.0.0174536581066.issue18680@psf.upfronthosting.co.za>
Message-ID: <3cDWt20t6NzRk2@mail.python.org>


Roundup Robot added the comment:

New changeset f8cf0f997dfa by Felix Crux in branch '3.3':
Documenting that json.load may raise a ValueError.
http://hg.python.org/cpython/rev/f8cf0f997dfa

New changeset 524693d62093 by Felix Crux in branch '2.7':
Documenting that json.load may raise a ValueError.
http://hg.python.org/cpython/rev/524693d62093

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18680>
_______________________________________

From report at bugs.python.org  Tue Aug 13 00:51:54 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 12 Aug 2013 22:51:54 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1376347914.41.0.606908135425.issue5516@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Eric,

Could you share details of your use-case?  My experience with subclassing from basic python types including date/time has been mostly negative.  The problem is that when I subclass, I want to inherit the rich set of operations such as +, -, *, etc., and add a few methods of my own.  After that, I want to always use instances of my subclass instead of the stdlib one.  This does not work because adding instances of my subclass returns an instance of the superclass unless I override __add__ explicitly. (See   #2267.)  This kills all benefits of subclassing as compared to containment.

These days I try to stay away from subclassing date/time, int/float, or anything like that and thus have little incentive to resolve this issue.  And it does not look like we have a workable solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Tue Aug 13 01:06:05 2013
From: report at bugs.python.org (Eric Snow)
Date: Mon, 12 Aug 2013 23:06:05 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1376348765.29.0.519131041598.issue5516@psf.upfronthosting.co.za>


Eric Snow added the comment:

I'm doing some string-based serialization of datetimes and need to be able to specify the type somewhat declaratively.  So I'm using a datetime subclass.  This is more or less the code I'm using:


class Timestamp(datetime.datetime):

    def __new__(cls, raw_value, *args, **kwargs):
        if not args and not kwargs:
            return cls.fromtimestamp(int(raw_value))
        else:
            return super(Timestamp, cls).__new__(cls, raw_value,
                                                 *args, **kwargs)

    def __str__(self):
        return str(int(time.mktime(self.timetuple())))


Incidently, the whole equality testing thing didn't actually cause a problem.  It was comparing against the result of `datetime.utcnow()` which has microseconds (and my Timestamp instance didn't).  Clearing out the microseconds resolved the failure so I wasn't actually bitten by this issue after all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5516>
_______________________________________

From report at bugs.python.org  Tue Aug 13 01:20:51 2013
From: report at bugs.python.org (Phil Webster)
Date: Mon, 12 Aug 2013 23:20:51 +0000
Subject: [issue18583] Idle: enhance FormatParagraph
In-Reply-To: <1375065577.4.0.851490009653.issue18583@psf.upfronthosting.co.za>
Message-ID: <1376349651.66.0.0872350340889.issue18583@psf.upfronthosting.co.za>


Phil Webster added the comment:

I've attached a patch that attempts to address the issues above. For the tests, I made some changes because the cursor doesn't end in exactly the same spot with line endings.

Here's a quick summary of the changes:
1. Removed format_paragraph and format_comment methods because all text is treated the same and formatted in the event method. (The formatting code could be pulled out of the format_event method if needed.)

2. Added find_string_indices method to see if cursor is in string using the text widget's string tag. If the cursor is in a string, only the string lines are formatted. Before, if code immediately preceded or followed the string at the same indentation level, it was treated as part of the same paragraph.

3. If the text to be formatted ends with a triple quoted string on its own line (such as a docstring), the formatting code leaves the line alone.

4. If selection contains multiple paragraphs (separated by blank lines), it can format each one. Previously, only the first paragraph was formatted.

Once I have some feedback, I can thoroughly check all of the tests and make sure that we're getting the expected behavior.

----------
keywords: +patch
Added file: http://bugs.python.org/file31266/18583enhancefp1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18583>
_______________________________________

From report at bugs.python.org  Tue Aug 13 01:49:32 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 12 Aug 2013 23:49:32 +0000
Subject: [issue18707] the readme should also talk about how to build doc.
In-Reply-To: <1376203024.02.0.197448582438.issue18707@psf.upfronthosting.co.za>
Message-ID: <1376351372.75.0.884650947879.issue18707@psf.upfronthosting.co.za>


Madison May added the comment:

Here's a patch that adds a short sentence to the README's `Documentation` section that refers readers to the Doc/README.txt file.

----------
nosy: +madison.may
Added file: http://bugs.python.org/file31267/README_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18707>
_______________________________________

From report at bugs.python.org  Tue Aug 13 02:31:33 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Aug 2013 00:31:33 +0000
Subject: [issue18707] the readme should also talk about how to build doc.
In-Reply-To: <1376203024.02.0.197448582438.issue18707@psf.upfronthosting.co.za>
Message-ID: <1376353893.84.0.0281378431546.issue18707@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thanks for the patch!  One thing: Doc/README.txt does not actually mention how to contribute to the doc, does it?  Maybe the main README should link to the devguide instead of or in addition to Doc/README.txt

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18707>
_______________________________________

From report at bugs.python.org  Tue Aug 13 03:25:47 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 13 Aug 2013 01:25:47 +0000
Subject: [issue18707] the readme should also talk about how to build doc.
In-Reply-To: <1376203024.02.0.197448582438.issue18707@psf.upfronthosting.co.za>
Message-ID: <1376357147.4.0.495829108723.issue18707@psf.upfronthosting.co.za>


Madison May added the comment:

Good point, ?ric.

It refers readers to the bug tracker, the Sphinx bug tracker, and docs at python.org in the `Contributing` section, but a link to the devguide would probably be more useful.  I've tweaked the patch a bit to reflect this.

----------
Added file: http://bugs.python.org/file31268/README_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18707>
_______________________________________

From report at bugs.python.org  Tue Aug 13 03:28:50 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Aug 2013 01:28:50 +0000
Subject: [issue18719] Remove false optimizaton for equality comparison of
	hashed strings
In-Reply-To: <1376339883.0.0.783356566828.issue18719@psf.upfronthosting.co.za>
Message-ID: <1376357330.7.0.618391391852.issue18719@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Profiling the test suite shows that the short-cut branch NEVER gets taken.
There are no cases where the string lengths, kinds, and 64-bit hashes match, but the stings themselves are a mismatch.  The whole theory behind this optimization is invalid.  The first characters always match, so you don't need to test for them.

Alex, these things are very difficult to measure because the cost of a 100% predictable branch is also zero in a tight benchmark.  The negative effects of useless tests are subtle and indirect (i.e. blowing other useful things out of the branch prediction table).

Victor, thanks for link to 17628.  I will look at that further, but at first glance it looks like you're introducing a big wall of code right in the middle of a critical loop in code the is supposed to be in-lined.  It too smells of a false optimization and places far too much hope that memcmp, case-statements, and whatnot will behave awesomely will all compilers.

Unless you object, I'm going to go ahead and remove the bogus test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18719>
_______________________________________

From report at bugs.python.org  Tue Aug 13 03:28:57 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 13 Aug 2013 01:28:57 +0000
Subject: [issue18707] the readme should also talk about how to build doc.
In-Reply-To: <1376203024.02.0.197448582438.issue18707@psf.upfronthosting.co.za>
Message-ID: <1376357337.17.0.894442766358.issue18707@psf.upfronthosting.co.za>


Madison May added the comment:

Or perhaps with an alternate wording: README_v4.diff

----------
Added file: http://bugs.python.org/file31269/README_v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18707>
_______________________________________

From report at bugs.python.org  Tue Aug 13 03:31:18 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 13 Aug 2013 01:31:18 +0000
Subject: [issue18719] Remove false optimizaton for equality comparison of
	hashed strings
In-Reply-To: <1376339883.0.0.783356566828.issue18719@psf.upfronthosting.co.za>
Message-ID: <1376357478.31.0.107985283649.issue18719@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

The statistic that htis is *never* hit across a large python program is great evidence that this isn't useful. +1 on removing from me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18719>
_______________________________________

From report at bugs.python.org  Tue Aug 13 04:08:10 2013
From: report at bugs.python.org (R. Jayakrishnan)
Date: Tue, 13 Aug 2013 02:08:10 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1376359690.63.0.958391816491.issue18704@psf.upfronthosting.co.za>


Changes by R. Jayakrishnan <raajjya at gmail.com>:


----------
nosy: +philwebster

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Tue Aug 13 04:10:05 2013
From: report at bugs.python.org (R. Jayakrishnan)
Date: Tue, 13 Aug 2013 02:10:05 +0000
Subject: [issue18583] Idle: enhance FormatParagraph
In-Reply-To: <1375065577.4.0.851490009653.issue18583@psf.upfronthosting.co.za>
Message-ID: <1376359805.7.0.846483503175.issue18583@psf.upfronthosting.co.za>


Changes by R. Jayakrishnan <raajjya at gmail.com>:


----------
nosy: +JayKrish

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18583>
_______________________________________

From report at bugs.python.org  Tue Aug 13 05:05:11 2013
From: report at bugs.python.org (Arun Babu Neelicattu)
Date: Tue, 13 Aug 2013 03:05:11 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
	subjectAltNames general names (CVE-2013-4073)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376363111.08.0.502117870405.issue18709@psf.upfronthosting.co.za>


Arun Babu Neelicattu added the comment:

This issue has been assigned CVE-2013-4238 [1].

Please use CVE-2013-4238 for this issue in Python for patches and references.

[1] http://www.openwall.com/lists/oss-security/2013/08/13/2

----------
nosy: +abn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Tue Aug 13 05:46:44 2013
From: report at bugs.python.org (Ben Darnell)
Date: Tue, 13 Aug 2013 03:46:44 +0000
Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not
	match IDNA prefix
In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za>
Message-ID: <1376365604.47.0.106654363056.issue17997@psf.upfronthosting.co.za>


Changes by Ben Darnell <ben.darnell at gmail.com>:


----------
nosy: +Ben.Darnell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17997>
_______________________________________

From report at bugs.python.org  Tue Aug 13 07:24:30 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Aug 2013 05:24:30 +0000
Subject: [issue18719] Remove false optimizaton for equality comparison of
	hashed strings
In-Reply-To: <1376339883.0.0.783356566828.issue18719@psf.upfronthosting.co.za>
Message-ID: <1376371470.56.0.1154650564.issue18719@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18719>
_______________________________________

From report at bugs.python.org  Tue Aug 13 07:26:06 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Aug 2013 05:26:06 +0000
Subject: [issue18719] Remove false optimizaton for equality comparison of
	hashed strings
In-Reply-To: <1376339883.0.0.783356566828.issue18719@psf.upfronthosting.co.za>
Message-ID: <1376371566.79.0.881827123259.issue18719@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file31270/27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18719>
_______________________________________

From report at bugs.python.org  Tue Aug 13 07:27:42 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 13 Aug 2013 05:27:42 +0000
Subject: [issue18721] test for FTP cwd function
In-Reply-To: <1376343816.8.0.615732489322.issue18721@psf.upfronthosting.co.za>
Message-ID: <1376371662.63.0.419016950709.issue18721@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Fixed in
6816ae6c49ce (2.7)
68b599740aa0 (3.3)
f8942b8e6774 (tip)

----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18721>
_______________________________________

From report at bugs.python.org  Tue Aug 13 08:26:52 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 13 Aug 2013 06:26:52 +0000
Subject: [issue18723] shorten function of textwrap module is susceptible to
	non-normalized whitespaces
Message-ID: <1376375212.1.0.637444277248.issue18723@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In shorten function of textwrap module, the placeholder becomes a hole where we can inject non-normalized whitespaces to the text.

>>> text = "Hello there, how are you this fine day? I'm glad to hear it!"
>>> from textwrap import shorten
>>> shorten(text, 40, placeholder="              ")
'Hello there, how are you'

We normalize the only-whitespaces placeholder.

But....

>>> shorten(text, 17, placeholder="  \n\t(...)  \n\t[...]  \n\t")
'(...)  \n\t[...]'
>>> shorten(text, 40, placeholder="  \n\t(...)  \n\t[...]  \n\t")
'Hello there, how  \n\t(...)  \n\t[...]'

Attached the patch to normalize the non-normalized whitespaces in placeholder.

----------
components: Library (Lib)
files: fix_for_non_normalized_whitespaces_in_placeholder.patch
keywords: patch
messages: 195045
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: shorten function of textwrap module is susceptible to non-normalized whitespaces
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31271/fix_for_non_normalized_whitespaces_in_placeholder.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18723>
_______________________________________

From report at bugs.python.org  Tue Aug 13 08:44:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Aug 2013 06:44:06 +0000
Subject: [issue18723] shorten function of textwrap module is susceptible to
	non-normalized whitespaces
In-Reply-To: <1376375212.1.0.637444277248.issue18723@psf.upfronthosting.co.za>
Message-ID: <1376376246.35.0.945771166187.issue18723@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm not convinced this is a bug. The whitespace right-stripping is more of an implementation detail. You can really put what you want inside the placeholder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18723>
_______________________________________

From report at bugs.python.org  Tue Aug 13 08:54:54 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 13 Aug 2013 06:54:54 +0000
Subject: [issue18723] shorten function of textwrap module is susceptible to
	non-normalized whitespaces
In-Reply-To: <1376375212.1.0.637444277248.issue18723@psf.upfronthosting.co.za>
Message-ID: <1376376894.49.0.0758221580227.issue18723@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Okay, nevermind about non-normalized whitespaces in placeholder, but what about this case?

>>> text = "Hello there, how are you this fine day? I'm glad to hear it!"
>>> from textwrap import shorten
>>> shorten(text, 10, placeholder="     ")
'Hello'
>>> shorten(text, 9, placeholder="     ")
''
>>> len('Hello')
5

Isn't that weird?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18723>
_______________________________________

From report at bugs.python.org  Tue Aug 13 09:08:31 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Aug 2013 07:08:31 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1376377711.81.0.0878460606445.issue18704@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

-1 on giving PEP 8 any more weight than it already has.

Automated PEP 8 checker tools do away the human commen sense component (the foolish consistency quote is in PEP 8 for a reason).

Another downside is that rigid adherence to PEP 8 tends to focus beginners on the least important aspects of code quality.  We would be much better-off with integration of PyFlakes or a similar tool that focus on actual semantic errors in the code.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Tue Aug 13 09:08:41 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Aug 2013 07:08:41 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1376377721.01.0.513783136755.issue18704@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
versions:  -Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Tue Aug 13 09:42:27 2013
From: report at bugs.python.org (Susan Tan)
Date: Tue, 13 Aug 2013 07:42:27 +0000
Subject: [issue18724] Typo in docs.python.org: smtplib python2.7
Message-ID: <1376379747.75.0.914823707462.issue18724@psf.upfronthosting.co.za>


New submission from Susan Tan:

http://docs.python.org/2.7/library/smtplib.html#smtplib.SMTPException 

"exception smtplib.SMTPException
The base exception class for all the other excpetions provided by this module."

The word "exceptions" is spelled incorrectly in the in "other excpetions".

----------
assignee: docs at python
components: Documentation
messages: 195049
nosy: Susan, docs at python
priority: normal
severity: normal
status: open
title: Typo in docs.python.org: smtplib python2.7
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18724>
_______________________________________

From report at bugs.python.org  Tue Aug 13 09:49:17 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Aug 2013 07:49:17 +0000
Subject: [issue18722] Remove uses of the register keyword
In-Reply-To: <1376343971.9.0.52964508892.issue18722@psf.upfronthosting.co.za>
Message-ID: <1376380157.39.0.33994218759.issue18722@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18722>
_______________________________________

From report at bugs.python.org  Tue Aug 13 10:16:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Aug 2013 08:16:21 +0000
Subject: [issue18724] Typo in docs.python.org: smtplib python2.7
In-Reply-To: <1376379747.75.0.914823707462.issue18724@psf.upfronthosting.co.za>
Message-ID: <3cDmwP05mbzSKq@mail.python.org>


Roundup Robot added the comment:

New changeset bd030e70cecb by Ned Deily in branch '2.7':
Issue 18724: Fix typo noticed by Susan Tan.
http://hg.python.org/cpython/rev/bd030e70cecb

New changeset 76d71bc949b6 by Ned Deily in branch '3.3':
Issue 18724: Fix typo noticed by Susan Tan.
http://hg.python.org/cpython/rev/76d71bc949b6

New changeset 8dccd3b51711 by Ned Deily in branch 'default':
Issue 18724: Fix typo noticed by Susan Tan.
http://hg.python.org/cpython/rev/8dccd3b51711

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18724>
_______________________________________

From report at bugs.python.org  Tue Aug 13 10:17:20 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 13 Aug 2013 08:17:20 +0000
Subject: [issue18724] Typo in docs.python.org: smtplib python2.7
In-Reply-To: <1376379747.75.0.914823707462.issue18724@psf.upfronthosting.co.za>
Message-ID: <1376381840.16.0.448509144653.issue18724@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report!

----------
nosy: +ned.deily
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: enhancement -> 
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18724>
_______________________________________

From report at bugs.python.org  Tue Aug 13 10:24:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Aug 2013 08:24:05 +0000
Subject: [issue18722] Remove uses of the register keyword
In-Reply-To: <1376343971.9.0.52964508892.issue18722@psf.upfronthosting.co.za>
Message-ID: <1376382245.01.0.0879901468962.issue18722@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> have exactly the same size

Binaries contain paddings.

> although their md5 hashes differ

Timestamps.

I'm interesting if someone builds CPython with more simple compilers (i.e. PCC [1]).

[1] http://en.wikipedia.org/wiki/Portable_C_Compiler

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18722>
_______________________________________

From report at bugs.python.org  Tue Aug 13 10:29:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Aug 2013 08:29:12 +0000
Subject: [issue18722] Remove uses of the register keyword
In-Reply-To: <1376382245.01.0.0879901468962.issue18722@psf.upfronthosting.co.za>
Message-ID: <1439007712.59561441.1376382546306.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Serhiy Storchaka added the comment:
> 
> > have exactly the same size
> 
> Binaries contain paddings.

I used the "size" command, which gives you the exact size of the various sections
(rather than the physical file size).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18722>
_______________________________________

From report at bugs.python.org  Tue Aug 13 10:34:30 2013
From: report at bugs.python.org (Robin Schreiber)
Date: Tue, 13 Aug 2013 08:34:30 +0000
Subject: [issue15849] PEP 3121, 384 Refactoring applied to xx module
In-Reply-To: <1346596353.57.0.974507844943.issue15849@psf.upfronthosting.co.za>
Message-ID: <1376382870.55.0.0981684837191.issue15849@psf.upfronthosting.co.za>


Robin Schreiber added the comment:

Updated the patch, corrected multiple syntax errors and missing INCREFS. Also added the comments that include the members names. I am yet undecided regarding the NULL-check for FindModule.

Apart from that I have tried to build some tests that prove that loading and unloading the module do not cause any memory leaks. This has turned up several problems: For one, the only possibility to check for the leaks that PEP 3121 tries to fix, is to run PyInit of the respective module multiple times. This is only possible if Py_finalize() has been called after the module has been imported beforehand. This means we can not test for these leaks from within Python, but need some C-Code that calls
Py_initialize(); ... import xx ... Py_finalize(); multiple times. The problem is that also the plain Py_initialize(); Py_finalize(); calls leak memory. Unfortunately the amount of objects that are leaked also seems to vary, so there is no constant factor that I can subtract to determine how much the imported module itself leaks.
So I am kind of on a dead end here. I could upload the tests scripts that I have written so far, if that helps.

----------
keywords: +patch
Added file: http://bugs.python.org/file31272/xxmodule_pep3121-384_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15849>
_______________________________________

From report at bugs.python.org  Tue Aug 13 10:56:55 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Aug 2013 08:56:55 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
	subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376384215.11.0.297863001806.issue18709@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks! The title now references the new CVE #.

----------
title: SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4073) -> SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Tue Aug 13 11:04:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Aug 2013 09:04:51 +0000
Subject: [issue15849] PEP 3121, 384 Refactoring applied to xx module
In-Reply-To: <1346596353.57.0.974507844943.issue15849@psf.upfronthosting.co.za>
Message-ID: <1376384691.24.0.303522762494.issue15849@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> In the example Martin gave in his PEP 3121, the PyInit does not perform any INCREFs on
> the Variables that are referenced from inside the module state.
> He therefore left out m_free completely as there was nothing to DECREF within the module
> state.
> Back when I did my GSoC together with Martin, we decided that the Module state itself can 
> be considered a valid container object, an therefore has to INCREF and in the end of its
> lifecycle (that is within m_free) also DECREF every object reference it holds. I therefore 
> decided to include that into every module I refactored, and consequently also the xxmodule.

I agree with that, but then PEP 3121's example code should be fixed.

> I am yet undecided regarding the NULL-check for FindModule.

Not checking for NULL makes it dangerous to implement unloading of extension modules: see issue18674.

If checking for NULL makes extension code too complicated, then please take a look at the helper API I've suggested in issue18710.

Also, it would be nice if you could also read the following python-dev thread, since it discusses concrete issues and possible solutions:
http://mail.python.org/pipermail/python-dev/2013-August/127862.html

> This means we can not test for these leaks from within Python, but need some C-Code

You can use _testcapi.run_in_subinterp() to run custom code in a sub-interpreter.

Here is an example of a non-leaking extension module, and then a (presumably) leaking one:

$ ./python -Xshowrefcount
Python 3.4.0a1+ (default:9e61563edb67, Aug 12 2013, 14:52:25) 
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import _testcapi
[64175 refs, 19937 blocks]
>>> _testcapi.run_in_subinterp("import resource")
0
[68839 refs, 20969 blocks]
>>> _testcapi.run_in_subinterp("import resource")
0
[68852 refs, 20980 blocks]
>>> _testcapi.run_in_subinterp("import resource")
0
[68850 refs, 20979 blocks]
>>> _testcapi.run_in_subinterp("import resource")
0
[68852 refs, 20980 blocks]
>>> _testcapi.run_in_subinterp("import resource")
0
[68850 refs, 20979 blocks]
>>> _testcapi.run_in_subinterp("import _socket")
0
[71840 refs, 22059 blocks]
>>> _testcapi.run_in_subinterp("import _socket")
0
[71911 refs, 22083 blocks]
>>> _testcapi.run_in_subinterp("import _socket")
0
[71981 refs, 22107 blocks]
>>> _testcapi.run_in_subinterp("import _socket")
0
[72051 refs, 22131 blocks]

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15849>
_______________________________________

From report at bugs.python.org  Tue Aug 13 11:10:05 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Aug 2013 09:10:05 +0000
Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not
	match IDNA prefix
In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za>
Message-ID: <1376385005.64.0.0769547542025.issue17997@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Affected versions:

- Python 3.2 (< 3.2.5)
- Python 3.3 (< 3.3.3)
- Python 3.4a1
- requests < 1.2.3
https://pypi.python.org/pypi/requests
- backports.ssl_match_hostname (<3.2a3)
https://pypi.python.org/pypi/backports.ssl_match_hostname/
- urllib3 < 1.6
https://github.com/shazow/urllib3
- bzr
- setuptools
- tornado
- pip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17997>
_______________________________________

From report at bugs.python.org  Tue Aug 13 11:12:42 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Aug 2013 09:12:42 +0000
Subject: [issue18723] shorten function of textwrap module is susceptible to
	non-normalized whitespaces
In-Reply-To: <1376375212.1.0.637444277248.issue18723@psf.upfronthosting.co.za>
Message-ID: <1376385162.61.0.658302507618.issue18723@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18723>
_______________________________________

From report at bugs.python.org  Tue Aug 13 11:23:09 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Aug 2013 09:23:09 +0000
Subject: [issue18723] shorten function of textwrap module is susceptible to
	non-normalized whitespaces
In-Reply-To: <1376375212.1.0.637444277248.issue18723@psf.upfronthosting.co.za>
Message-ID: <1376385789.43.0.741569862066.issue18723@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Isn't that weird?

Agreed, this one is a bug. The stripping in shorten() should be smarter, i.e. it should not affect the placeholder's own spaces.
Do you want to write a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18723>
_______________________________________

From report at bugs.python.org  Tue Aug 13 11:24:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Aug 2013 09:24:07 +0000
Subject: [issue18723] shorten function of textwrap module is susceptible to
	non-normalized whitespaces
In-Reply-To: <1376375212.1.0.637444277248.issue18723@psf.upfronthosting.co.za>
Message-ID: <1376385847.79.0.537169970384.issue18723@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Correcting myself:

> i.e. it should not affect the placeholder's own spaces.

... except for leading whitespace in case the placeholder ends up alone in the result.
i.e. shorten("somethingtoolong") should return "(...)", not " (...)".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18723>
_______________________________________

From report at bugs.python.org  Tue Aug 13 11:50:43 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Aug 2013 09:50:43 +0000
Subject: [issue14019] Unify tests for str.format and string.Formatter
In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za>
Message-ID: <1376387443.47.0.601488357601.issue14019@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I left a review on rietveld.

FWIW I think string_tests and related files should undergo a (major?) refactoring.  I worked with them a few times and it's a bit of a mess with all those base classes and mixins.  I also found some tests that weren't running because they were accidentally overridden by one of the subclasses, or other tests that were duplicated.  This is especially true on Python 3, where bytes and str share a smaller subset of features.

----------
nosy: +ezio.melotti
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14019>
_______________________________________

From report at bugs.python.org  Tue Aug 13 11:54:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Aug 2013 09:54:51 +0000
Subject: [issue18687] Lib/test/leakers/test_ctypes.py still mentions the need
	to update Misc/build.sh
In-Reply-To: <1375985116.56.0.149122259336.issue18687@psf.upfronthosting.co.za>
Message-ID: <3cDq631swqz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 49edf4cbc453 by Ezio Melotti in branch '2.7':
#18687: remove obsolete comment.  Patch by F?vry Thibault.
http://hg.python.org/cpython/rev/49edf4cbc453

New changeset 49fa63610c7f by Ezio Melotti in branch '3.3':
#18687: remove obsolete comment.  Patch by F?vry Thibault.
http://hg.python.org/cpython/rev/49fa63610c7f

New changeset 1ea89e5f40cf by Ezio Melotti in branch 'default':
#18687: merge with 3.3.
http://hg.python.org/cpython/rev/1ea89e5f40cf

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18687>
_______________________________________

From report at bugs.python.org  Tue Aug 13 11:55:50 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Aug 2013 09:55:50 +0000
Subject: [issue18687] Lib/test/leakers/test_ctypes.py still mentions the need
	to update Misc/build.sh
In-Reply-To: <1375985116.56.0.149122259336.issue18687@psf.upfronthosting.co.za>
Message-ID: <1376387750.47.0.377889726645.issue18687@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18687>
_______________________________________

From report at bugs.python.org  Tue Aug 13 11:58:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Aug 2013 09:58:05 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376387885.19.0.784578035384.issue18712@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch. Now the code of operator.index() becomes even more complicated. Perhaps you want suggest other wording for documentation?

Some code in stdlib (_pyio.py, bz2.py, connection.py) uses a.__index__() instead of type(a).__index__(a) (with replacing AttributeError to TypeError). Is it worth to change?

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file31273/operator_index.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Tue Aug 13 12:12:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Aug 2013 10:12:58 +0000
Subject: [issue18725] Multiline shortening
Message-ID: <1376388778.3.0.982069932509.issue18725@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Functions in the textwrap module works with multiline text except a newly added (in issue18585) the shorten() function. Wrapping and shortening a multiline text using existing textwrap function is not a trivial job.

I propose to add two new parameters to the TextWrap class and wrap() and fill() functions: max_lines and placeholder. If the max_lines argument is specified then wrapped text truncated to max_lines and the last line shortened to the width argument.

>>>print(textwrap('Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.', width=40, max_lines=3))
Lorem ipsum dolor sit amet, consectetur
adipisicing elit, sed do eiusmod tempor
incididunt ut labore et dolore (...)

The shorten() function then will be just a particular case of fill() with max_lines=1.

----------
components: Library (Lib)
messages: 195065
nosy: barry, ezio.melotti, georg.brandl, pitrou, python-dev, r.david.murray, serhiy.storchaka, stevenjd, vajrasky
priority: normal
severity: normal
status: open
title: Multiline shortening
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18725>
_______________________________________

From report at bugs.python.org  Tue Aug 13 12:15:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Aug 2013 10:15:19 +0000
Subject: [issue18725] Multiline shortening
In-Reply-To: <1376388778.3.0.982069932509.issue18725@psf.upfronthosting.co.za>
Message-ID: <1376388919.53.0.435463408284.issue18725@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Sounds like a reasonable enhancement to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18725>
_______________________________________

From report at bugs.python.org  Tue Aug 13 12:38:18 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Aug 2013 10:38:18 +0000
Subject: [issue18725] Multiline shortening
In-Reply-To: <1376388778.3.0.982069932509.issue18725@psf.upfronthosting.co.za>
Message-ID: <1376390298.93.0.483750219233.issue18725@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18725>
_______________________________________

From report at bugs.python.org  Tue Aug 13 13:05:29 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 13 Aug 2013 11:05:29 +0000
Subject: [issue18723] shorten function of textwrap module is susceptible to
	non-normalized whitespaces
In-Reply-To: <1376375212.1.0.637444277248.issue18723@psf.upfronthosting.co.za>
Message-ID: <1376391929.82.0.242451919967.issue18723@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

> Do you want to write a patch?
My pleasure.

Attached the second version of the patch to accomodate Pitrou's request.

----------
Added file: http://bugs.python.org/file31274/fix_for_non_normalized_whitespaces_in_placeholder_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18723>
_______________________________________

From report at bugs.python.org  Tue Aug 13 13:13:24 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 13 Aug 2013 11:13:24 +0000
Subject: [issue18694] getxattr on Linux ZFS native filesystem happily returns
	partial values
In-Reply-To: <1376024133.74.0.379846700659.issue18694@psf.upfronthosting.co.za>
Message-ID: <1376392404.74.0.368427035301.issue18694@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18694>
_______________________________________

From report at bugs.python.org  Tue Aug 13 13:18:04 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 13 Aug 2013 11:18:04 +0000
Subject: [issue18722] Remove uses of the register keyword
In-Reply-To: <1376343971.9.0.52964508892.issue18722@psf.upfronthosting.co.za>
Message-ID: <1376392684.51.0.651898270141.issue18722@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18722>
_______________________________________

From report at bugs.python.org  Tue Aug 13 13:18:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Aug 2013 11:18:14 +0000
Subject: [issue18726] json functions have too many positional parameters
Message-ID: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The json module functions have too many positional parameters:

dump() -- 11
dumps() -- 10
load() -- 9
loads() -- 8

In most time only small part of these options is specified so users call these functions with keyword arguments for all parameters except mandatory ones.

Even worse, the simplejson module (an ancestor and an alternative to standard json module) have a very similar interface but with difference sequences of parameters (the second parameter of loads() and the ninth parameter of dumps() in simplejson is encoding). So in any case portable application should specify all but basic arguments as keyword arguments. If json will incorporate some features from simplejson in future positions of new parameters will be different.

I propose to deprecate specifying all but mandatory parameters of json functions as positional arguments in 3.4 and then forbid it in 3.5.

I.e. dumps() should be implemented in 3.4 as:

def dumps(obj, *args, **kwargs):
    if args:
        warnings.warn("The positional arguments are deprecated.",
                     DeprecationWarning, stacklevel=2)
    return _dumps(obj, *args, **kwargs)

def _dumps(obj, skipkeys=False, ensure_ascii=True, check_circular=True,
        allow_nan=True, cls=None, indent=None, separators=None,
        default=None, sort_keys=False, **kwargs):
    ...

and in 3.5 as:

def dumps(obj, *, skipkeys=False, ensure_ascii=True, check_circular=True,
        allow_nan=True, cls=None, indent=None, separators=None,
        default=None, sort_keys=False, **kwargs):
    ...

----------
components: Library (Lib)
messages: 195068
nosy: bob.ippolito, ezio.melotti, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: json functions have too many positional parameters
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18726>
_______________________________________

From report at bugs.python.org  Tue Aug 13 13:22:17 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 13 Aug 2013 11:22:17 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
	subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376392937.26.0.789574123627.issue18709@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Tue Aug 13 14:10:09 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Aug 2013 12:10:09 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
	subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376395809.75.0.560018133699.issue18709@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Python 3.1 is affected, too. 3.1 will recieve security fixes until June 2014.

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Tue Aug 13 14:46:34 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Aug 2013 12:46:34 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1376397994.1.0.734096370181.issue18726@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is not what we use keyword only arguments for.  The standard practice in the stdlib is that arguments are arguments unless there is a good reason to make one keyword only.  So I'm -1 on this proposal.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18726>
_______________________________________

From report at bugs.python.org  Tue Aug 13 14:57:56 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Aug 2013 12:57:56 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1376398676.15.0.201440134877.issue18726@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Serhiy has a point though, I wouldn't want to see something like json.dumps(someobj, True, False, True, False).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18726>
_______________________________________

From report at bugs.python.org  Tue Aug 13 15:04:12 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Aug 2013 13:04:12 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1376399052.12.0.662856035713.issue18726@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ach.  I didn't read carefully enough (not awake yet, I guess).

Yes, boolean parameters are one of the things keyword only arguments are appropriate for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18726>
_______________________________________

From report at bugs.python.org  Tue Aug 13 15:19:47 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 13 Aug 2013 13:19:47 +0000
Subject: [issue18723] shorten function of textwrap module is susceptible to
	non-normalized whitespaces
In-Reply-To: <1376375212.1.0.637444277248.issue18723@psf.upfronthosting.co.za>
Message-ID: <1376399987.63.0.924906214697.issue18723@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Attached more refined patch. Removed unnecessary test. Added more robust test. Added shorten in __all__.

----------
Added file: http://bugs.python.org/file31275/fix_for_non_normalized_whitespaces_in_placeholder_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18723>
_______________________________________

From report at bugs.python.org  Tue Aug 13 15:21:33 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 13 Aug 2013 13:21:33 +0000
Subject: [issue18723] shorten function of textwrap module is susceptible to
	non-normalized whitespaces
In-Reply-To: <1376375212.1.0.637444277248.issue18723@psf.upfronthosting.co.za>
Message-ID: <1376400093.54.0.785768020695.issue18723@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file31275/fix_for_non_normalized_whitespaces_in_placeholder_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18723>
_______________________________________

From report at bugs.python.org  Tue Aug 13 15:22:45 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 13 Aug 2013 13:22:45 +0000
Subject: [issue18723] shorten function of textwrap module is susceptible to
	non-normalized whitespaces
In-Reply-To: <1376375212.1.0.637444277248.issue18723@psf.upfronthosting.co.za>
Message-ID: <1376400165.42.0.243626545469.issue18723@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file31276/fix_for_non_normalized_whitespaces_in_placeholder_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18723>
_______________________________________

From report at bugs.python.org  Tue Aug 13 15:30:04 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 13 Aug 2013 13:30:04 +0000
Subject: [issue18725] Multiline shortening
In-Reply-To: <1376388778.3.0.982069932509.issue18725@psf.upfronthosting.co.za>
Message-ID: <1376400604.3.0.366702618143.issue18725@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

What about newline keyword argument?

Are we forcing the newline to be '\n'? Alternate newlines will be useful for Windows platform ('\r\n') and HTML platform ('<br />').

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18725>
_______________________________________

From report at bugs.python.org  Tue Aug 13 15:31:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Aug 2013 13:31:22 +0000
Subject: [issue18394] cgi.FieldStorage triggers ResourceWarning sometimes
In-Reply-To: <1373190601.25.0.575768158618.issue18394@psf.upfronthosting.co.za>
Message-ID: <1376400682.33.0.0790483582706.issue18394@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18394>
_______________________________________

From report at bugs.python.org  Tue Aug 13 15:49:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Aug 2013 13:49:57 +0000
Subject: [issue18725] Multiline shortening
In-Reply-To: <1376388778.3.0.982069932509.issue18725@psf.upfronthosting.co.za>
Message-ID: <1376401797.16.0.995499085418.issue18725@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

fill(...) is just '\n'.join(wrap(...)). Directly use wrap() if you need nonstandard newlines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18725>
_______________________________________

From report at bugs.python.org  Tue Aug 13 16:39:33 2013
From: report at bugs.python.org (Gabi Davar)
Date: Tue, 13 Aug 2013 14:39:33 +0000
Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful
	on	Windows
In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za>
Message-ID: <1376404773.12.0.686971201641.issue14243@psf.upfronthosting.co.za>


Changes by Gabi Davar <grizzly.nyo at gmail.com>:


----------
nosy: +Gabi.Davar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14243>
_______________________________________

From report at bugs.python.org  Tue Aug 13 16:41:21 2013
From: report at bugs.python.org (Gabi Davar)
Date: Tue, 13 Aug 2013 14:41:21 +0000
Subject: [issue6875] add os.close() suggestion to mkstemp documentation
In-Reply-To: <1252583225.62.0.0154739326414.issue6875@psf.upfronthosting.co.za>
Message-ID: <1376404881.38.0.739212054854.issue6875@psf.upfronthosting.co.za>


Changes by Gabi Davar <grizzly.nyo at gmail.com>:


----------
nosy: +Gabi.Davar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6875>
_______________________________________

From report at bugs.python.org  Tue Aug 13 16:54:47 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Aug 2013 14:54:47 +0000
Subject: [issue14012] Misc tarfile fixes
In-Reply-To: <1329235837.42.0.144867770777.issue14012@psf.upfronthosting.co.za>
Message-ID: <1376405687.3.0.183362848083.issue14012@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thanks, LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14012>
_______________________________________

From report at bugs.python.org  Tue Aug 13 17:01:42 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Aug 2013 15:01:42 +0000
Subject: [issue18707] the readme should also talk about how to build doc.
In-Reply-To: <1376203024.02.0.197448582438.issue18707@psf.upfronthosting.co.za>
Message-ID: <1376406102.36.0.596722320683.issue18707@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Either one looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18707>
_______________________________________

From report at bugs.python.org  Tue Aug 13 17:03:58 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Aug 2013 15:03:58 +0000
Subject: [issue18703] To change the doc of html/faq/gui.html
In-Reply-To: <1376157675.52.0.120458668025.issue18703@psf.upfronthosting.co.za>
Message-ID: <1376406238.49.0.227473966604.issue18703@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Also, the GPLs allows commercial usage, so using ?LGPL? and ?commercial? to mean two different licensing cases is not quite right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18703>
_______________________________________

From report at bugs.python.org  Tue Aug 13 17:10:07 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 13 Aug 2013 15:10:07 +0000
Subject: [issue18723] shorten function of textwrap module is susceptible to
	non-normalized whitespaces
In-Reply-To: <1376375212.1.0.637444277248.issue18723@psf.upfronthosting.co.za>
Message-ID: <1376406607.27.0.119113399252.issue18723@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

I missed this case:

>>> from textwrap import shorten
>>> shorten('hell', 4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/sky/Code/python/programming_language/cpython/Lib/textwrap.py", line 386, in shorten
    return w.shorten(text, placeholder=placeholder)
  File "/home/sky/Code/python/programming_language/cpython/Lib/textwrap.py", line 322, in shorten
    raise ValueError("placeholder too large for max width")
ValueError: placeholder too large for max width

Also, in this patch, I removed the unnecessary stripping of the text part.

----------
Added file: http://bugs.python.org/file31277/fix_for_non_normalized_whitespaces_in_placeholder_v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18723>
_______________________________________

From report at bugs.python.org  Tue Aug 13 17:14:50 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 13 Aug 2013 15:14:50 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1376406890.37.0.237324048771.issue18726@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18726>
_______________________________________

From report at bugs.python.org  Tue Aug 13 17:34:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Aug 2013 15:34:16 +0000
Subject: [issue18723] shorten function of textwrap module is susceptible
	to	non-normalized whitespaces
In-Reply-To: <1376406607.27.0.119113399252.issue18723@psf.upfronthosting.co.za>
Message-ID: <518721548.60342855.1376408049657.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> I missed this case:
> 
> >>> from textwrap import shorten
> >>> shorten('hell', 4)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File
>   "/home/sky/Code/python/programming_language/cpython/Lib/textwrap.py",
>   line 386, in shorten
>     return w.shorten(text, placeholder=placeholder)
>   File
>   "/home/sky/Code/python/programming_language/cpython/Lib/textwrap.py",
>   line 322, in shorten
>     raise ValueError("placeholder too large for max width")
> ValueError: placeholder too large for max width

This is by design. Passing a placeholder larger than the width is a
programming error, regardless of whether the text is small enough.

----------
title: shorten function of textwrap module is susceptible to non-normalized whitespaces -> shorten function of textwrap module is susceptible to	non-normalized whitespaces

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18723>
_______________________________________

From report at bugs.python.org  Tue Aug 13 17:48:41 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 13 Aug 2013 15:48:41 +0000
Subject: [issue18723] shorten function of textwrap module is susceptible
	to	non-normalized whitespaces
In-Reply-To: <1376375212.1.0.637444277248.issue18723@psf.upfronthosting.co.za>
Message-ID: <1376408921.28.0.169676280671.issue18723@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Okay, attached the fifth version not to care about the case where text is smaller than the placeholder.

----------
Added file: http://bugs.python.org/file31278/fix_for_non_normalized_whitespaces_in_placeholder_v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18723>
_______________________________________

From report at bugs.python.org  Tue Aug 13 17:56:58 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 13 Aug 2013 15:56:58 +0000
Subject: [issue18579] Dereference after NULL check in listobject.c merge_hi()
In-Reply-To: <1375017605.96.0.0484069196925.issue18579@psf.upfronthosting.co.za>
Message-ID: <1376409418.11.0.709638221369.issue18579@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks! Your analysis is plausible. I have closed the issue as "false positive".

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18579>
_______________________________________

From report at bugs.python.org  Tue Aug 13 18:01:15 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Tue, 13 Aug 2013 16:01:15 +0000
Subject: [issue18727] test for writing dictionary rows to CSV
Message-ID: <1376409675.57.0.271656920796.issue18727@psf.upfronthosting.co.za>


New submission from Muhammad Jehanzeb:

Test for writing dictionary rows to further enhance the test coverage of CSV lib.

----------
components: Tests
messages: 195083
nosy: brett.cannon, mjehanzeb
priority: normal
severity: normal
status: open
title: test for writing dictionary rows to CSV
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18727>
_______________________________________

From report at bugs.python.org  Tue Aug 13 18:08:13 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Tue, 13 Aug 2013 16:08:13 +0000
Subject: [issue18727] test for writing dictionary rows to CSV
In-Reply-To: <1376409675.57.0.271656920796.issue18727@psf.upfronthosting.co.za>
Message-ID: <1376410093.0.0.0294543937906.issue18727@psf.upfronthosting.co.za>


Changes by Muhammad Jehanzeb <mjehanzeb at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31279/issue18727.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18727>
_______________________________________

From report at bugs.python.org  Tue Aug 13 18:08:27 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Aug 2013 16:08:27 +0000
Subject: [issue18722] Remove uses of the register keyword
In-Reply-To: <1376343971.9.0.52964508892.issue18722@psf.upfronthosting.co.za>
Message-ID: <1376410107.69.0.82370034238.issue18722@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1  The era of "register" has passed.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18722>
_______________________________________

From report at bugs.python.org  Tue Aug 13 18:34:55 2013
From: report at bugs.python.org (Alex Volkov)
Date: Tue, 13 Aug 2013 16:34:55 +0000
Subject: [issue18728] Increased test coverage for test_filecmp
Message-ID: <1376411694.99.0.620922615046.issue18728@psf.upfronthosting.co.za>


New submission from Alex Volkov:

I increased test coverage from 68% to 74% of filecmp.py by adding test cases in test_filecmp.py in functions phase2 & phase4 in dircmp class.

----------
components: Tests
files: test_filecmp.patch
keywords: patch
messages: 195085
nosy: Alex.Volkov
priority: normal
severity: normal
status: open
title: Increased test coverage for test_filecmp
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31280/test_filecmp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18728>
_______________________________________

From report at bugs.python.org  Tue Aug 13 18:35:48 2013
From: report at bugs.python.org (Seydou Dia)
Date: Tue, 13 Aug 2013 16:35:48 +0000
Subject: [issue18715] Tests fail when run with coverage
In-Reply-To: <1376334932.92.0.162234474623.issue18715@psf.upfronthosting.co.za>
Message-ID: <1376411748.65.0.278657767279.issue18715@psf.upfronthosting.co.za>


Seydou Dia added the comment:

The test results have been uploaded.

I forgot to mention in my previous comment the version of Coverage.py used:

changeset:   1463:2c5fb3a8b81c
tag:         tip
user:        Ned Batchelder <ned at nedbatchelder.com>
date:        Sun Jun 09 19:10:28 2013 -0400
summary:     Branch coverage improvement, fixes #90.  Bug #212 fixed on py2, but not py3

----------
Added file: http://bugs.python.org/file31281/tests.out

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18715>
_______________________________________

From report at bugs.python.org  Tue Aug 13 18:44:05 2013
From: report at bugs.python.org (Alex Volkov)
Date: Tue, 13 Aug 2013 16:44:05 +0000
Subject: [issue18728] Increased test coverage for filecmp.py
In-Reply-To: <1376411694.99.0.620922615046.issue18728@psf.upfronthosting.co.za>
Message-ID: <1376412245.08.0.472680800184.issue18728@psf.upfronthosting.co.za>


Changes by Alex Volkov <avolkov at gmail.com>:


----------
title: Increased test coverage for test_filecmp -> Increased test coverage for filecmp.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18728>
_______________________________________

From report at bugs.python.org  Tue Aug 13 20:04:44 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 18:04:44 +0000
Subject: [issue18722] Remove uses of the register keyword
In-Reply-To: <1376410107.69.0.82370034238.issue18722@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbguXL-Bry_nSmNSKMVcGdxeHsQnrpVeTKX5NkgPTgcCQ@mail.gmail.com>


STINNER Victor added the comment:

Is PCC used by any Linux or BSD distro? BSD prefers Clang.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18722>
_______________________________________

From report at bugs.python.org  Tue Aug 13 20:06:07 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 13 Aug 2013 18:06:07 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1376417167.18.0.918894809021.issue8713@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


Added file: http://bugs.python.org/file31282/4fc7c72b1c5d.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Tue Aug 13 20:07:52 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 13 Aug 2013 18:07:52 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1376417272.87.0.643335895011.issue8713@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

I have added documentation now so I think it is ready to merge (except for a change to Makefile).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Tue Aug 13 20:20:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Aug 2013 18:20:32 +0000
Subject: [issue18722] Remove uses of the register keyword
In-Reply-To: <1376343971.9.0.52964508892.issue18722@psf.upfronthosting.co.za>
Message-ID: <3cF2KW71FXzRSK@mail.python.org>


Roundup Robot added the comment:

New changeset e7f6cef7a4cc by Antoine Pitrou in branch 'default':
Issue #18722: Remove uses of the "register" keyword in C code.
http://hg.python.org/cpython/rev/e7f6cef7a4cc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18722>
_______________________________________

From report at bugs.python.org  Tue Aug 13 20:21:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Aug 2013 18:21:10 +0000
Subject: [issue18722] Remove uses of the register keyword
In-Reply-To: <1376343971.9.0.52964508892.issue18722@psf.upfronthosting.co.za>
Message-ID: <1376418070.37.0.078906103297.issue18722@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Committed. I don't think clang or MSVC would bother more than gcc does.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18722>
_______________________________________

From report at bugs.python.org  Tue Aug 13 20:24:06 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Aug 2013 18:24:06 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <3cF2Pd2v74z7Ljg@mail.python.org>


Roundup Robot added the comment:

New changeset 00bcf202cc3f by Antoine Pitrou in branch '2.7':
Add NEWS entry for 0f17aed78168 (issue #16248)
http://hg.python.org/cpython/rev/00bcf202cc3f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Tue Aug 13 20:24:47 2013
From: report at bugs.python.org (py.user)
Date: Tue, 13 Aug 2013 18:24:47 +0000
Subject: [issue18729] In unittest.TestLoader.discover doc select the name of
	load_tests function
Message-ID: <1376418287.73.0.835584535115.issue18729@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/library/unittest.html#unittest.TestLoader.discover
"If load_tests exists then discovery does not recurse into the package"

----------
assignee: docs at python
components: Documentation
files: issue.diff
keywords: patch
messages: 195092
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In unittest.TestLoader.discover doc select the name of load_tests function
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31283/issue.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18729>
_______________________________________

From report at bugs.python.org  Tue Aug 13 20:24:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 13 Aug 2013 18:24:57 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1376418297.22.0.174762372801.issue16248@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> That fix does work, but it should probably get a NEWS entry since it
> fixes a regression from 2.7.3 to 2.7.5.

Done, thank you?

> Also, I think the same fix should be backported to all three of 2.6,
> 3.1, and 3.2.

Benjamin and Barry will have to decide what to do for 2.6 and 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Tue Aug 13 20:54:49 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 13 Aug 2013 18:54:49 +0000
Subject: [issue18583] Idle: enhance FormatParagraph
In-Reply-To: <1375065577.4.0.851490009653.issue18583@psf.upfronthosting.co.za>
Message-ID: <1376420089.38.0.742761473728.issue18583@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Based on working with the #18226 patch, I now think that rewrapping partial lines is a bug. Although I removed some problematical tests, I think there is still one that verifies buggy behavior. The outline of steps (which necessarily omits some details) would then be:

1. Extract a list of complete lines (without \n) from the text widget. The only purpose of using selections rather than the cursor would be to get partial paragraphs or multiple paragraphs. (I had thought of deleting that idea, but if you have made it work, I will look at it.)

There are still details to work out. If the cursor is on a blank line, should we really search forward? Normally, sel.first would be moved back to the beginning of the line [you apparently have already done this] and sel.last to the end. But if a block selection ends at the beginning of a line, sel.last should not be moved.

2. Delete the common prefix from each line, including '#' for comment blocks. Do this and the following without the current repeating joining of and splitting into lines. It is all wasted motion.

3. Reformat into a new list of lines, now with \n.

4. Add back the common prefix (still a list of lines with \n).

5. Insert the lines (which already have \n) into the text widget, one at a time.

   One of the details I left out is consistently handling of \n for the last line, so that deletion from the text widget and inserting into the widget match. One of the 'features' of the current code is that it will handle paragraphs with a different indent on the first line. I am not sure it is needed, as it does not apply to comment and string blocks.

Steps 2,3,4 do not involve the text widget. I think that they should be performed in one or more non-widget functions so they can be separately tested. I would feel this way even if mock_tk.Text were complete enough to substitute for tkinter.Text in the method test. 

I have not looked at your patch much because I want to review and possibly edit and commit some of the other submitted test patches before working more on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18583>
_______________________________________

From report at bugs.python.org  Tue Aug 13 21:14:43 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 13 Aug 2013 19:14:43 +0000
Subject: [issue18090] dict_contains first argument declared register,
	and shouldn't be
In-Reply-To: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za>
Message-ID: <1376421283.11.0.204291741952.issue18090@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Closed as this is a subset of #18722.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18090>
_______________________________________

From report at bugs.python.org  Tue Aug 13 22:54:00 2013
From: report at bugs.python.org (Dan Loewenherz)
Date: Tue, 13 Aug 2013 20:54:00 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
	when not prepending with a period
Message-ID: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>


New submission from Dan Loewenherz:

Basically, when creating a NamedTemporaryFile, passing a value to the "suffix" parameter has no effect unless it's prepended with a period.

IMO, there are three options here...

1. Add a note in the documentation that this parameter only accepts period-prepended values (not ideal but better than the status quo).
2. Change the behavior to throw an exception when a non-period prepended value is provided (probably bad since it would break stuff).
3. Strip invalid values from this input and silently fail if the resulting string is of length 0 (might also break stuff).

----------
components: Library (Lib)
messages: 195097
nosy: dloewenherz
priority: normal
severity: normal
status: open
title: suffix parameter in NamedTemporaryFile silently fails when not prepending with a period
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18730>
_______________________________________

From report at bugs.python.org  Tue Aug 13 22:51:30 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 13 Aug 2013 20:51:30 +0000
Subject: [issue18718] datetime documentation contradictory on leap second
	support
In-Reply-To: <1376339376.74.0.0279691228671.issue18718@psf.upfronthosting.co.za>
Message-ID: <1376427090.44.0.670866469713.issue18718@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

+1

:-)

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18718>
_______________________________________

From report at bugs.python.org  Tue Aug 13 23:04:22 2013
From: report at bugs.python.org (Alex Volkov)
Date: Tue, 13 Aug 2013 21:04:22 +0000
Subject: [issue18731] Increased test coverage for uu and telnet
Message-ID: <1376427862.02.0.743044696464.issue18731@psf.upfronthosting.co.za>


Changes by Alex Volkov <avolkov at gmail.com>:


----------
components: Tests
files: telnet_uu_tests.patch
keywords: patch
nosy: Alex.Volkov
priority: normal
severity: normal
status: open
title: Increased test coverage for uu and telnet
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31284/telnet_uu_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18731>
_______________________________________

From report at bugs.python.org  Tue Aug 13 23:18:18 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 13 Aug 2013 21:18:18 +0000
Subject: [issue15787] PEP 3121, 384 Refactoring
In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za>
Message-ID: <1376428698.42.0.92018384359.issue15787@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I strongly believe that it is worthwhile to invest in fixing abitype.py.  It is much easier to review a patch to one python script than to review 50+ patches to C files.  There is no excuse for this tool not to work on all stdlib modules.  If there are any specific issues with the way individual modules are written that prevent automatic conversion, I would prefer to make a coding style change first and then include all modules in one automated PEP 384 conversion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15787>
_______________________________________

From report at bugs.python.org  Tue Aug 13 23:20:31 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 13 Aug 2013 21:20:31 +0000
Subject: [issue18732] IdleHistory.History: eliminate unused parameter;
	other cleanup.
Message-ID: <1376428831.4.0.308828193599.issue18732@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

idlelib.IdleHistory is only imported in PyShell.PyShell. History is only instantiated once, with output_sep defaulting to \n. This constant parameter and the consequence splitting and joining with \n in ._get_source and ._put_source are useless. After the tests for this class are committed in #18425, I plan to eliminate the unneeded parameter, splits, joins, and methods and inline the remaining text.get and .insert in .fetch. I want to do a few other transparent modernizations in the .fetch code, such as replacing 4 of the lines with
 pointer += -1 if reverse else 1

----------
assignee: terry.reedy
components: IDLE
messages: 195099
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IdleHistory.History: eliminate unused parameter; other cleanup.
type: performance
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18732>
_______________________________________

From report at bugs.python.org  Tue Aug 13 23:20:50 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 13 Aug 2013 21:20:50 +0000
Subject: [issue18732] IdleHistory.History: eliminate unused parameter;
	other cleanup.
In-Reply-To: <1376428831.4.0.308828193599.issue18732@psf.upfronthosting.co.za>
Message-ID: <1376428850.76.0.513708114032.issue18732@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
dependencies: +IDLE Unit test for IdleHistory.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18732>
_______________________________________

From report at bugs.python.org  Tue Aug 13 23:29:09 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Tue, 13 Aug 2013 21:29:09 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1376429349.06.0.73804503522.issue12939@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12939>
_______________________________________

From report at bugs.python.org  Wed Aug 14 00:19:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 22:19:35 +0000
Subject: [issue1227748] subprocess: inheritance of std descriptors inconsistent
Message-ID: <1376432375.38.0.398821679355.issue1227748@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1227748>
_______________________________________

From report at bugs.python.org  Wed Aug 14 00:21:29 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 22:21:29 +0000
Subject: [issue15798] subprocess.Popen() fails if 0,
	1 or 2 descriptor is closed
In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za>
Message-ID: <1376432489.96.0.862762174152.issue15798@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15798>
_______________________________________

From report at bugs.python.org  Wed Aug 14 00:23:18 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 22:23:18 +0000
Subject: [issue18544] subprocess.Popen support for redirection of arbitrary
	file descriptors
In-Reply-To: <1374674400.76.0.00470955001934.issue18544@psf.upfronthosting.co.za>
Message-ID: <1376432598.92.0.263751875389.issue18544@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Why not using the pass_fds parameter for your use case?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18544>
_______________________________________

From report at bugs.python.org  Wed Aug 14 00:57:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 22:57:45 +0000
Subject: [issue18685] Restore re performance to pre-PEP393 level
In-Reply-To: <1375967417.95.0.0303828296889.issue18685@psf.upfronthosting.co.za>
Message-ID: <1376434665.04.0.430702180637.issue18685@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Using #include "_sre.c" in _sre.c looks weird. Instead of huge sections delimited by "#ifdef SRE_RECURSIVE", I would prefer something similar to the stringlib. ".h" template files included more than once. I also expect shorter files: _sre.c is close to 4000 lines of C code :-(

If you move code from _sre.c to a new file, you should use "hg cp" to keep the history. For the review, it's maybe better to continue with your SRE_RECURSIVE hack :)

--

#define SRE_CHAR Py_UCS1
#define SIZEOF_SRE_CHAR 1
..
#define SRE_CHAR Py_UCS2
#define SIZEOF_SRE_CHAR 1
...
#define SRE_CHAR Py_UCS4
#define SIZEOF_SRE_CHAR 1

The value of SIZEOF_SRE_CHAR looks suspicious.

Does test_re have some non-ASCII tests? If not, we should probably start by adding such tests!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18685>
_______________________________________

From report at bugs.python.org  Wed Aug 14 01:13:39 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 23:13:39 +0000
Subject: [issue18296] test_os.test_trailers() is failing on AMD64 FreeBSD 9.0
	dtrace 3.x
In-Reply-To: <1372119942.09.0.162654139201.issue18296@psf.upfronthosting.co.za>
Message-ID: <1376435619.64.0.0265433472689.issue18296@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@koobs: The problem is in the Python test, not in FreeBSD. Can you upgrade the kernel to the last development version?

Attached patch should fix the test.

----------
keywords: +patch
Added file: http://bugs.python.org/file31285/sendfile_trailers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18296>
_______________________________________

From report at bugs.python.org  Wed Aug 14 01:14:06 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 23:14:06 +0000
Subject: [issue18609] test_ctypes failure on AIX in
	PyEval_CallObjectWithKeywords
In-Reply-To: <1375305877.13.0.891928742401.issue18609@psf.upfronthosting.co.za>
Message-ID: <1376435646.5.0.376977974595.issue18609@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18609>
_______________________________________

From report at bugs.python.org  Wed Aug 14 01:28:40 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Aug 2013 23:28:40 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <3cF9935D2kz7Lkn@mail.python.org>


Roundup Robot added the comment:

New changeset de5077aca668 by Victor Stinner in branch 'default':
Close #12015: The tempfile module now uses a suffix of 8 random characters
http://hg.python.org/cpython/rev/de5077aca668

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Wed Aug 14 01:35:48 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 23:35:48 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1376436948.93.0.961224995139.issue12015@psf.upfronthosting.co.za>


STINNER Victor added the comment:

With 8 lowercase characters, the entropy is 41.7 bits, whereas it is only 35.9 bits for 6 characters with uppercase and lowercase letters.

>>> math.log(26+26+10+1, 2) * 6 # (a-zA-Z0-9_) x 6
35.8636795409995
>>> math.log(26+10+1, 2) * 6 # (a-z0-9_) x 6
31.256720193773702
>>> math.log(26+10+1, 2) * 8 # (a-z0-9_) x 8
41.6756269250316

My changeset improves the entropy, it is now higher than with the old charset.

I don't know if it is enough or not to be safe. systemd creates a temporary directory per service. Linux 3.11 will add a new O_TMPFILE to open() which allow to create a file with no name. Using the flag should help to workaround the race condition attack. See #18673 for O_TMPFILE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Wed Aug 14 01:40:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Aug 2013 23:40:57 +0000
Subject: [issue18405] crypt.mksalt() result has unnecessarily low entropy
In-Reply-To: <1373306240.23.0.797149936972.issue18405@psf.upfronthosting.co.za>
Message-ID: <3cF9RD64NFz7Lks@mail.python.org>


Roundup Robot added the comment:

New changeset e8a314fe248b by Victor Stinner in branch '3.3':
Issue #18405: Improve the entropy of crypt.mksalt().
http://hg.python.org/cpython/rev/e8a314fe248b

New changeset 122e074c56f7 by Victor Stinner in branch 'default':
(Merge 3.3) Issue #18405: Improve the entropy of crypt.mksalt().
http://hg.python.org/cpython/rev/122e074c56f7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18405>
_______________________________________

From report at bugs.python.org  Wed Aug 14 01:41:10 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 23:41:10 +0000
Subject: [issue18405] crypt.mksalt() result has unnecessarily low entropy
In-Reply-To: <1373306240.23.0.797149936972.issue18405@psf.upfronthosting.co.za>
Message-ID: <1376437270.18.0.819543738321.issue18405@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18405>
_______________________________________

From report at bugs.python.org  Wed Aug 14 01:45:11 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 23:45:11 +0000
Subject: [issue18405] crypt.mksalt() result has unnecessarily low entropy
In-Reply-To: <1373306240.23.0.797149936972.issue18405@psf.upfronthosting.co.za>
Message-ID: <1376437511.23.0.638465467404.issue18405@psf.upfronthosting.co.za>


STINNER Victor added the comment:

With my change, any character can appear more than once. Example:

>>> crypt.mksalt()
'$6$idm7/asaywTgRf9V'
>>> sorted(_[3:])
['/', '7', '9', 'R', 'T', 'V', 'a', 'a', 'd', 'f', 'g', 'i', 'm', 's', 'w', 'y']

In this case, the 'a' letter occurs twice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18405>
_______________________________________

From report at bugs.python.org  Wed Aug 14 01:48:11 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 23:48:11 +0000
Subject: [issue14131] test_threading failure on WIndows 7 3.x buildbot
In-Reply-To: <1330259585.57.0.540126008704.issue14131@psf.upfronthosting.co.za>
Message-ID: <1376437691.14.0.206399310835.issue14131@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This failure was not seen recently, let's close this issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14131>
_______________________________________

From report at bugs.python.org  Wed Aug 14 01:50:15 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 23:50:15 +0000
Subject: [issue15581] curses: segfault in addstr()
In-Reply-To: <1344393356.61.0.716752115095.issue15581@psf.upfronthosting.co.za>
Message-ID: <1376437815.61.0.488315949192.issue15581@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Seems the bug was fixed for 3.3 in issue12567."

"Sorry, but without a smaller example program, I cannot help you on this issue. Please try to write a smaller program to reproduce the crash."

Let say that the bug was fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15581>
_______________________________________

From report at bugs.python.org  Wed Aug 14 01:52:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Aug 2013 23:52:19 +0000
Subject: [issue18425] IDLE Unit test for IdleHistory.py
In-Reply-To: <1373493838.59.0.876568806243.issue18425@psf.upfronthosting.co.za>
Message-ID: <3cF9hL4rD7z7Lk4@mail.python.org>


Roundup Robot added the comment:

New changeset 0bb9346665e9 by Terry Jan Reedy in branch '3.3':
Issue #18425: Add docstrings to IdleHistory.py.  Remove redundant 'history_'
http://hg.python.org/cpython/rev/0bb9346665e9

New changeset 22d7c755163d by Terry Jan Reedy in branch '2.7':
Issue #18425: Add docstrings to IdleHistory.py.  Remove redundant 'history_'
http://hg.python.org/cpython/rev/22d7c755163d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18425>
_______________________________________

From report at bugs.python.org  Wed Aug 14 01:58:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 23:58:20 +0000
Subject: [issue18733] elementtree: stop the parser more quickly on error
Message-ID: <1376438300.88.0.235284556503.issue18733@psf.upfronthosting.co.za>


New submission from STINNER Victor:

When a Python handler of a XML tag fails, the ElementTree parser continues to parse the whole document. It would be nice to stop the parser more quickly.

The pyexpat module unregisters all handlers to fail more quickly. ElementTree may do something similar.

Or does the expat library have a function or attribute to stop the XML parser?

See also the issue #18501 (_elementtree.c calls Python callbacks while a Python exception is set).

----------
components: XML
messages: 195110
nosy: fdrake, haypo
priority: normal
severity: normal
status: open
title: elementtree: stop the parser more quickly on error
type: performance
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18733>
_______________________________________

From report at bugs.python.org  Wed Aug 14 01:59:23 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 23:59:23 +0000
Subject: [issue18501] _elementtree.c calls Python callbacks while a Python
	exception is set
In-Reply-To: <1374181261.54.0.8148762893.issue18501@psf.upfronthosting.co.za>
Message-ID: <1376438363.21.0.973264904472.issue18501@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Instead of having to check if an exception is set in each Python
> callback, it would be better to "stop" the XML parser.

I created the issue #18733 to track this optimization.

The initial issue is fixed, so I'm closing it.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18501>
_______________________________________

From report at bugs.python.org  Wed Aug 14 02:11:36 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Aug 2013 00:11:36 +0000
Subject: [issue18408] Fixes crashes found by pyfailmalloc
In-Reply-To: <1373314243.02.0.649080681154.issue18408@psf.upfronthosting.co.za>
Message-ID: <1376439096.85.0.128390360059.issue18408@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"""
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/98/steps/test/logs/stdio

FAIL: test_finalize_runnning_thread (test.test_threading.ThreadTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/test_threading.py", line 298, in test_finalize_runnning_thread
    self.assertEqual(rc, 42)
AssertionError: -6 != 42
"""

Oh, this error is not a regression introduced by this issue: it was already present in the oldest build of this buildbot:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/5/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18408>
_______________________________________

From report at bugs.python.org  Wed Aug 14 02:19:50 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Aug 2013 00:19:50 +0000
Subject: [issue18408] Fixes crashes found by pyfailmalloc
In-Reply-To: <1373314243.02.0.649080681154.issue18408@psf.upfronthosting.co.za>
Message-ID: <1376439589.98.0.131426681821.issue18408@psf.upfronthosting.co.za>


STINNER Victor added the comment:

TODO:

- review and integrate frame_fasttolocals.patch
- #18507: import_init() should not use Py_FatalError() but return an error
- #18509: CJK decoders should return MBERR_EXCEPTION on PyUnicodeWriter error
- fix tests hang when an exception occurs in a thread

Most bugs have been fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18408>
_______________________________________

From report at bugs.python.org  Wed Aug 14 02:57:11 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Aug 2013 00:57:11 +0000
Subject: [issue18314] Have os.unlink remove junction points
In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za>
Message-ID: <1376441831.88.0.809470380608.issue18314@psf.upfronthosting.co.za>


STINNER Victor added the comment:

What is "an NTFS junction point"? Is it possible to delete it in cmd.exe with the del command?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18314>
_______________________________________

From report at bugs.python.org  Wed Aug 14 03:13:24 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 14 Aug 2013 01:13:24 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376442804.44.0.940716343793.issue18606@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Attached is a patch containing the statistics reference implementation, after considering feedback given here and on python-ideas, and tests.

----------
keywords: +patch
Added file: http://bugs.python.org/file31286/statistics.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Wed Aug 14 03:21:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Aug 2013 01:21:14 +0000
Subject: [issue18719] Remove false optimizaton for equality comparison of
	hashed strings
In-Reply-To: <1376339883.0.0.783356566828.issue18719@psf.upfronthosting.co.za>
Message-ID: <3cFCfx1Zzjz7LkF@mail.python.org>


Roundup Robot added the comment:

New changeset 8f9bc9283400 by Raymond Hettinger in branch '3.3':
Issue 18719: Remove a false optimization
http://hg.python.org/cpython/rev/8f9bc9283400

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18719>
_______________________________________

From report at bugs.python.org  Wed Aug 14 03:35:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Aug 2013 01:35:12 +0000
Subject: [issue18719] Remove false optimizaton for equality comparison of
	hashed strings
In-Reply-To: <1376339883.0.0.783356566828.issue18719@psf.upfronthosting.co.za>
Message-ID: <3cFCz358J6z7Ll6@mail.python.org>


Roundup Robot added the comment:

New changeset ac2f59a6637f by Raymond Hettinger in branch '2.7':
Issue 18719: Remove a false optimization
http://hg.python.org/cpython/rev/ac2f59a6637f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18719>
_______________________________________

From report at bugs.python.org  Wed Aug 14 03:35:51 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 14 Aug 2013 01:35:51 +0000
Subject: [issue18719] Remove false optimization for equality comparison of
	hashed strings
In-Reply-To: <1376339883.0.0.783356566828.issue18719@psf.upfronthosting.co.za>
Message-ID: <1376444151.24.0.903910744487.issue18719@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed
title: Remove false optimizaton for equality comparison of hashed strings -> Remove false optimization for equality comparison of hashed strings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18719>
_______________________________________

From report at bugs.python.org  Wed Aug 14 04:12:01 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Aug 2013 02:12:01 +0000
Subject: [issue18583] Idle: enhance FormatParagraph
In-Reply-To: <1375065577.4.0.851490009653.issue18583@psf.upfronthosting.co.za>
Message-ID: <1376446321.33.0.47245173473.issue18583@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Note to myself. The current test suite has one test commented out because it worked with EditorWindow but not the mock. It is possible that it is a mark-gravity issue. (I ran into this with the mock for IdleHistory.).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18583>
_______________________________________

From report at bugs.python.org  Wed Aug 14 04:41:10 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Aug 2013 02:41:10 +0000
Subject: [issue18425] IDLE Unit test for IdleHistory.py
In-Reply-To: <1373493838.59.0.876568806243.issue18425@psf.upfronthosting.co.za>
Message-ID: <1376448070.38.0.386273709892.issue18425@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

IdleHistory.py is identical in 2.7 and 3.3. It is only imported in PyShell.py (within class PyShell, line 852 in 3.3). History is only initialized once, with the default output_sep. See #18732 for deleting the unneeded parameter and associated cruft.

The pushed patch adds docstrings and a couple of comments and removes most of the redundant prefixes. It does not change any logic.

The attached patch started as JK's patch with names changed and Ezio's changes. All test methods pass. There are three chunks of History.fetch that are not covered. Two require cyclic=False. The other requires special situations with text or cursor changes after one call to fetch but before the next. I will add these soon and push.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18425>
_______________________________________

From report at bugs.python.org  Wed Aug 14 04:43:08 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Aug 2013 02:43:08 +0000
Subject: [issue18425] IDLE Unit test for IdleHistory.py
In-Reply-To: <1373493838.59.0.876568806243.issue18425@psf.upfronthosting.co.za>
Message-ID: <1376448188.7.0.67447453284.issue18425@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


Added file: http://bugs.python.org/file31287/test_idlehistory3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18425>
_______________________________________

From report at bugs.python.org  Wed Aug 14 05:15:23 2013
From: report at bugs.python.org (Eddie Stanley)
Date: Wed, 14 Aug 2013 03:15:23 +0000
Subject: [issue18734] Berkeley DB versions 4.4-4.9 are not discovered by
	setup.py
Message-ID: <1376450123.08.0.865805118992.issue18734@psf.upfronthosting.co.za>


New submission from Eddie Stanley:

Support for Berkeley DB up to 5.3 was introduced in Python 2.7.4 (see issue #17477) however I'm having problems with the detection code in setup.py.

I'm working on RHEL4, I've got Berkeley DB 4.7.25 installed in /opt/db-4.7.25

When I try and "make" Python, it can't build _bsddb because no suitable version of db.h was found. 

The function gen_db_minor_ver_nums(major) looks as though it's supposed to spit out all the minor versions for a given major, however it doesn't appear to work properly for 4.x - surely 4.3, 4.4, 4.5 ... all the way to 4.9 (or whatever) should be generated. 

It only generates minor version "3" though. The end result is that 4.3 is the only working version in the 4.x series.

----------
components: Build
messages: 195120
nosy: Eddie.Stanley
priority: normal
severity: normal
status: open
title: Berkeley DB versions 4.4-4.9 are not discovered by setup.py
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18734>
_______________________________________

From report at bugs.python.org  Wed Aug 14 05:48:40 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 14 Aug 2013 03:48:40 +0000
Subject: [issue18314] Have os.unlink remove junction points
In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za>
Message-ID: <1376452120.49.0.641203483256.issue18314@psf.upfronthosting.co.za>


Tim Peters added the comment:

Victor, Wikipedia has a readable explanation:

http://en.wikipedia.org/wiki/NTFS_junction_point

I haven't used them much.  From cmd.exe, I've been able to delete them, not with "del" but with "rmdir".  You can create one from cmd.exe with the "mklink" command.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18314>
_______________________________________

From report at bugs.python.org  Wed Aug 14 06:05:34 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Aug 2013 04:05:34 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376453134.15.0.767041343212.issue18606@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Revised patch with tests modified to pass, as described in pydev post.

1. test. added to test_statistics_approx import

2. delete test_main and change ending of both to
if __name__ == '__main__':
  unittest.main()

----------
nosy: +terry.reedy
Added file: http://bugs.python.org/file31288/statistics2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Wed Aug 14 06:33:34 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 14 Aug 2013 04:33:34 +0000
Subject: [issue18728] Increased test coverage for filecmp.py
In-Reply-To: <1376411694.99.0.620922615046.issue18728@psf.upfronthosting.co.za>
Message-ID: <1376454814.4.0.663545254649.issue18728@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Hi Alex.

Typo in  "#Speicify subdirectories to hide".

I think you should not create WIN32 constant. Use this statement instead: @unittest.skipIf(sys.platform == "win32", "Not valid on Windows")

I think you should use addCleanup if you want to remove the directories that you create in that specific test. For example, in test_phase2_check_diff_files, you can use:
self.addCleanup(os.rmdir, check_type_dir)

That is for now.

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18728>
_______________________________________

From report at bugs.python.org  Wed Aug 14 06:40:22 2013
From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=)
Date: Wed, 14 Aug 2013 04:40:22 +0000
Subject: [issue18314] Have os.unlink remove junction points
In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za>
Message-ID: <1376455222.47.0.878358009054.issue18314@psf.upfronthosting.co.za>


Kim Gr?sman added the comment:

Victor,

Junction points are like links between directories only. They've been around since the NTFS that came with Windows 2000, but integration with OS tools has been generally poor (e.g. Explorer wouldn't see the difference between a junction point and a regular folder.) As of Windows 7, this works better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18314>
_______________________________________

From report at bugs.python.org  Wed Aug 14 08:34:20 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 14 Aug 2013 06:34:20 +0000
Subject: [issue18698] importlib.reload() does not return the module in
	sys.modules
In-Reply-To: <1376090838.27.0.832453640234.issue18698@psf.upfronthosting.co.za>
Message-ID: <1376462060.32.0.000902915900025.issue18698@psf.upfronthosting.co.za>


Eric Snow added the comment:

Yep.  In 2.7 and 3.2 the PyImport_ExecCodeModuleEx() function in Python/importlib.c returns the module found in sys.modules.  Here is a patch.  I suppose this should be fixed in 2.7 as well.  Thoughts?

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file31289/reload_replaced_module.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18698>
_______________________________________

From report at bugs.python.org  Wed Aug 14 09:12:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Aug 2013 07:12:04 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376464324.29.0.240739772553.issue18720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What about SOCK_STREAM, SOCK_DGRAM, and SOCK_RAW?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 09:37:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Aug 2013 07:37:42 +0000
Subject: [issue14012] Misc tarfile fixes
In-Reply-To: <1329235837.42.0.144867770777.issue14012@psf.upfronthosting.co.za>
Message-ID: <1376465862.26.0.878266913086.issue14012@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Lets push it. Lars?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14012>
_______________________________________

From report at bugs.python.org  Wed Aug 14 11:44:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Aug 2013 09:44:08 +0000
Subject: [issue18685] Restore re performance to pre-PEP393 level
In-Reply-To: <1375967417.95.0.0303828296889.issue18685@psf.upfronthosting.co.za>
Message-ID: <1376473448.03.0.992563535025.issue18685@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Using #include "_sre.c" in _sre.c looks weird. Instead of huge sections delimited by "#ifdef SRE_RECURSIVE", I would prefer something similar to the stringlib. ".h" template files included more than once. I also expect shorter files: _sre.c is close to 4000 lines of C code :-(

Agree, but a patch will be larger and harder for the synchronization and for the review in Rietveld. I'm going first solve other issues (issue18647, issue18672) before creating a large final patch.

> The value of SIZEOF_SRE_CHAR looks suspicious.

Good catch. Actually this macro is used only in order to skip some checks for UCS4. It should not affects the correctness, only possible the performance.

> Does test_re have some non-ASCII tests? If not, we should probably start by adding such tests!

There is a small number (about 10) of tests for non-ASCII data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18685>
_______________________________________

From report at bugs.python.org  Wed Aug 14 11:54:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 09:54:59 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376474099.81.0.93512691707.issue18720@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm not really thrilled by the current implementation. The way it is done leads to duplication among socket constants. Also, if I create a socket from a numeric value (because a well-known socket family is known yet known by Python), then socket.family will fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 11:58:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 09:58:34 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376474314.39.0.915388675493.issue18720@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 13:21:30 2013
From: report at bugs.python.org (raymontag)
Date: Wed, 14 Aug 2013 11:21:30 +0000
Subject: [issue18735] SSL/TLS pinning for the ssl module
Message-ID: <1376479290.6.0.728586195996.issue18735@psf.upfronthosting.co.za>


New submission from raymontag:

Hello,

I would like to see an implementation for SSL/TLS pinning in the sll module of the standard library.

At this moment it's only possible to give the client a CAcert and check if the server's certificate is signed with this CA by creating a ssl.Context object with ssl.Context("/path/to/cafile"). If I don't know the server's certificate, that is I just have the root certificate, this is okay. But if I implement my own server/client structure I know the server's certificate. And here comes pinning into play: If I know server's certificate I could not only check if it's signed with my CA but also if it is the specific certificate I've signed. This is a better protection against MITM e.g. and would be a great enhancement of the ssl module IMHO.

raymontag

----------
messages: 195130
nosy: raymontag
priority: normal
severity: normal
status: open
title: SSL/TLS pinning for the ssl module
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18735>
_______________________________________

From report at bugs.python.org  Wed Aug 14 13:24:09 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Aug 2013 11:24:09 +0000
Subject: [issue13647] Python SSL stack doesn't securely validate certificate
	(as client)
In-Reply-To: <1324564490.24.0.352449270187.issue13647@psf.upfronthosting.co.za>
Message-ID: <1376479449.37.0.117612194895.issue13647@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13647>
_______________________________________

From report at bugs.python.org  Wed Aug 14 13:25:49 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Aug 2013 11:25:49 +0000
Subject: [issue15464] ssl: add set_msg_callback function
In-Reply-To: <1343352856.85.0.212414509347.issue15464@psf.upfronthosting.co.za>
Message-ID: <1376479549.88.0.604965694853.issue15464@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
assignee:  -> christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15464>
_______________________________________

From report at bugs.python.org  Wed Aug 14 13:28:36 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Aug 2013 11:28:36 +0000
Subject: [issue18735] SSL/TLS pinning for the ssl module
In-Reply-To: <1376479290.6.0.728586195996.issue18735@psf.upfronthosting.co.za>
Message-ID: <1376479716.58.0.548749931558.issue18735@psf.upfronthosting.co.za>


Christian Heimes added the comment:

TLS cert pinning should be possible with the implementation of #18293

----------
nosy: +christian.heimes, giampaolo.rodola, janssen, pitrou
stage:  -> needs patch
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18735>
_______________________________________

From report at bugs.python.org  Wed Aug 14 13:43:26 2013
From: report at bugs.python.org (raymontag)
Date: Wed, 14 Aug 2013 11:43:26 +0000
Subject: [issue18735] SSL/TLS pinning for the ssl module
In-Reply-To: <1376479290.6.0.728586195996.issue18735@psf.upfronthosting.co.za>
Message-ID: <1376480606.82.0.988931698551.issue18735@psf.upfronthosting.co.za>


raymontag added the comment:

Yep, that's exactly what I meant :)

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18735>
_______________________________________

From report at bugs.python.org  Wed Aug 14 13:45:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 11:45:45 +0000
Subject: [issue18735] SSL/TLS pinning for the ssl module
In-Reply-To: <1376479290.6.0.728586195996.issue18735@psf.upfronthosting.co.za>
Message-ID: <1376480745.68.0.572120893466.issue18735@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

If you want to check for a specific server certificate, then I guess it should be enough to expose the cert's fingerprint in the data returned by getpeercert().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18735>
_______________________________________

From report at bugs.python.org  Wed Aug 14 13:54:47 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Aug 2013 11:54:47 +0000
Subject: [issue18735] SSL/TLS pinning for the ssl module
In-Reply-To: <1376479290.6.0.728586195996.issue18735@psf.upfronthosting.co.za>
Message-ID: <1376481287.65.0.116710996099.issue18735@psf.upfronthosting.co.za>


Christian Heimes added the comment:

getpeercert() doesn't return Subject Public Key Info yet. It's on my TODO list. Chrome uses SPKI (PK algo + mod + exp) to pin certs, https://www.imperialviolet.org/2011/05/04/pinning.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18735>
_______________________________________

From report at bugs.python.org  Wed Aug 14 13:56:48 2013
From: report at bugs.python.org (raymontag)
Date: Wed, 14 Aug 2013 11:56:48 +0000
Subject: [issue18735] SSL/TLS pinning for the ssl module
In-Reply-To: <1376479290.6.0.728586195996.issue18735@psf.upfronthosting.co.za>
Message-ID: <1376481408.03.0.912295365994.issue18735@psf.upfronthosting.co.za>


raymontag added the comment:

Yeah, this was my first idea, too.

Are there at this moment other possibilities to implement pinning myself with the options the module provides me?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18735>
_______________________________________

From report at bugs.python.org  Wed Aug 14 13:59:06 2013
From: report at bugs.python.org (Basil Peace)
Date: Wed, 14 Aug 2013 11:59:06 +0000
Subject: [issue18736] Invalid charset in HTML pages inside documentation in
	CHM format
Message-ID: <1376481546.2.0.725412367622.issue18736@psf.upfronthosting.co.za>


New submission from Basil Peace:

HTML pages inside CHM documentation use the following tag to set applied character set:
    <meta http-equiv="Content-Type" content="text/html; charset=iso8859_1" />

`iso8859_1` is neither valid character set according to IANA registry nor is recognized by most browsers (I've checked IE, Firefox and Opera).

This isn't notable for text in English. But, in `Python Standard Library` in section `4.7.1 String Methods` there is a documentation for str.casefold(). This paragraph contains German letter `?`.
Without defined character set this letter can be displayed wrongly, depending on user's regional settings. In my Russian I see in CHM `?`. Firefox displays it as `?`.

Fix of charset to `ISO-8859-1` could resolve the problem.

P.S. Use of UTF-8 may be more convenient for preventing future errors.

----------
assignee: docs at python
components: Documentation
messages: 195136
nosy: docs at python, grv87
priority: normal
severity: normal
status: open
title: Invalid charset in HTML pages inside documentation in CHM format
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18736>
_______________________________________

From report at bugs.python.org  Wed Aug 14 14:02:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 12:02:07 +0000
Subject: [issue18735] SSL/TLS pinning for the ssl module
In-Reply-To: <1376481408.03.0.912295365994.issue18735@psf.upfronthosting.co.za>
Message-ID: <1796114293.62010660.1376481721696.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Are there at this moment other possibilities to implement pinning
> myself with the options the module provides me?

I don't think so. Perhaps you could use the serialNumber, but I'm not
sure how safe it is, even when restricting to a single CA cert.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18735>
_______________________________________

From report at bugs.python.org  Wed Aug 14 14:03:23 2013
From: report at bugs.python.org (raymontag)
Date: Wed, 14 Aug 2013 12:03:23 +0000
Subject: [issue18735] SSL/TLS pinning for the ssl module
In-Reply-To: <1376479290.6.0.728586195996.issue18735@psf.upfronthosting.co.za>
Message-ID: <1376481803.06.0.167253231403.issue18735@psf.upfronthosting.co.za>


raymontag added the comment:

That's not a good idea, a serial number could be faked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18735>
_______________________________________

From report at bugs.python.org  Wed Aug 14 14:03:36 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Aug 2013 12:03:36 +0000
Subject: [issue18735] SSL/TLS pinning for the ssl module
In-Reply-To: <1376479290.6.0.728586195996.issue18735@psf.upfronthosting.co.za>
Message-ID: <1376481816.27.0.902769498119.issue18735@psf.upfronthosting.co.za>


Christian Heimes added the comment:

sha256(conn.getpeercert(True)) works until the cert gets e.g. more SAN fields.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18735>
_______________________________________

From report at bugs.python.org  Wed Aug 14 14:10:44 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 12:10:44 +0000
Subject: [issue18735] SSL/TLS pinning for the ssl module
In-Reply-To: <1376481816.27.0.902769498119.issue18735@psf.upfronthosting.co.za>
Message-ID: <605028617.62026993.1376482237065.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> sha256(conn.getpeercert(True)) works until the cert gets e.g. more
> SAN fields.

Indeed, that's simply comparing the certificate by binary value. At this
point you don't even need a CA anymore, I guess :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18735>
_______________________________________

From report at bugs.python.org  Wed Aug 14 14:14:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 12:14:06 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1376417272.87.0.643335895011.issue8713@psf.upfronthosting.co.za>
Message-ID: <1385447416.62033268.1376482441049.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> I have added documentation now so I think it is ready to merge
> (except for a change to Makefile).

Good for me. This is a very nice addition!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Wed Aug 14 14:17:24 2013
From: report at bugs.python.org (raymontag)
Date: Wed, 14 Aug 2013 12:17:24 +0000
Subject: [issue18735] SSL/TLS pinning for the ssl module
In-Reply-To: <1376479290.6.0.728586195996.issue18735@psf.upfronthosting.co.za>
Message-ID: <1376482644.9.0.286316874641.issue18735@psf.upfronthosting.co.za>


raymontag added the comment:

Great, that matches my needs exactly

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18735>
_______________________________________

From report at bugs.python.org  Wed Aug 14 14:27:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 12:27:39 +0000
Subject: [issue16463] testConnectTimeout of test_timeout
	TCPTimeoutTestCasefailures fails intermittently
In-Reply-To: <1352757217.25.0.912881014186.issue16463@psf.upfronthosting.co.za>
Message-ID: <1376483259.28.0.0833819084152.issue16463@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, good point. My only issue with the patch is that www.python.org will be resolved for every test method, even those that don't use remote_addr. This will make test_timeout unnecessarily slower.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16463>
_______________________________________

From report at bugs.python.org  Wed Aug 14 14:28:03 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 12:28:03 +0000
Subject: [issue16463] testConnectTimeout of test_timeout
	TCPTimeoutTestCasefailures fails intermittently
In-Reply-To: <1352757217.25.0.912881014186.issue16463@psf.upfronthosting.co.za>
Message-ID: <1376483283.55.0.614538118751.issue16463@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: ncoghlan -> neologix
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16463>
_______________________________________

From report at bugs.python.org  Wed Aug 14 14:31:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 12:31:31 +0000
Subject: [issue18731] Increased test coverage for uu and telnet
Message-ID: <1376483491.13.0.318665465995.issue18731@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18731>
_______________________________________

From report at bugs.python.org  Wed Aug 14 14:33:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 12:33:00 +0000
Subject: [issue18727] test for writing dictionary rows to CSV
In-Reply-To: <1376409675.57.0.271656920796.issue18727@psf.upfronthosting.co.za>
Message-ID: <1376483580.88.0.855510813947.issue18727@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

You can probably use a StringIO for the file object, no need to create a temporary file.

----------
nosy: +pitrou
stage:  -> patch review
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18727>
_______________________________________

From report at bugs.python.org  Wed Aug 14 14:44:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Aug 2013 12:44:02 +0000
Subject: [issue18736] Invalid charset in HTML pages inside documentation in
	CHM format
In-Reply-To: <1376481546.2.0.725412367622.issue18736@psf.upfronthosting.co.za>
Message-ID: <1376484242.15.0.939542780344.issue18736@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18736>
_______________________________________

From report at bugs.python.org  Wed Aug 14 14:45:27 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 12:45:27 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376474099.81.0.93512691707.issue18720@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda-8uZwUQSZJw0d=dbnrCtDr+EaOeSqfQhKws_rz_TjHNg@mail.gmail.com>


Eli Bendersky added the comment:

> I'm not really thrilled by the current implementation. The way it is done
> leads to duplication among socket constants.

Can you clarify which duplication you mean specifically? In the code review
tool, Serhiy proposed that instead of listing all the constants explicitly
in the Python code, we can just do:

AddressFamily = IntEnum('AddressFamily',
           {name: value for name, value in _moduledict.items()
            if name.startswith('AF_')})

Is this less duplication?

> Also, if I create a socket from a numeric value (because a well-known
> socket family is known yet known by Python), then socket.family will fail.
>

Well, the documentation of socket.socket says it should be one of the AF_*
constants. One thing we can do is check in the socket.socket constructor
whether it's a known AF_* constants and fail early with a meaningful error
message. Would that be better?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 14:46:24 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 12:46:24 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376464324.29.0.240739772553.issue18720@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda-6GFLzGtQGqVTo_R62U738TJGdOPhPBoNtFLwAbOe4JA@mail.gmail.com>


Eli Bendersky added the comment:

> What about SOCK_STREAM, SOCK_DGRAM, and SOCK_RAW?
>

This is a proof of concept. As I mentioned in the original message starting
this issue - the SOCK_* constants will get the same treatment as AF_*
constants, once we decide what the right treatment is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 14:50:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Aug 2013 12:50:12 +0000
Subject: [issue16463] testConnectTimeout of test_timeout
	TCPTimeoutTestCasefailures fails intermittently
In-Reply-To: <1352757217.25.0.912881014186.issue16463@psf.upfronthosting.co.za>
Message-ID: <1376484612.46.0.779251412316.issue16463@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

We can do this in the setUpClass() method.

Or we can wrap the resolve_address() method with the @functools.lru_cache() decorator.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16463>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:02:24 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 14 Aug 2013 13:02:24 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376485344.2.0.0668866111635.issue18606@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Steven:  were you planning to start a discussion thread on python-dev for PEP 450?  I see that there's some activity on python-list and on python-ideas, but I think most core devs would expect the main discussions to happen on the python-dev mailing list.  (And I suspect that many core devs don't pay attention to python-list very much.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:11:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 13:11:51 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <CAF-Rda-8uZwUQSZJw0d=dbnrCtDr+EaOeSqfQhKws_rz_TjHNg@mail.gmail.com>
Message-ID: <1508259875.62132507.1376485905054.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Can you clarify which duplication you mean specifically? In the code
> review
> tool, Serhiy proposed that instead of listing all the constants
> explicitly
> in the Python code, we can just do:
> 
> AddressFamily = IntEnum('AddressFamily',
>            {name: value for name, value in _moduledict.items()
>             if name.startswith('AF_')})

Yes, that's better.

> > Also, if I create a socket from a numeric value (because a
> > well-known
> > socket family is known yet known by Python), then socket.family
> > will fail.
> >
> 
> Well, the documentation of socket.socket says it should be one of the
> AF_*
> constants. One thing we can do is check in the socket.socket
> constructor
> whether it's a known AF_* constants and fail early with a meaningful
> error
> message. Would that be better?

Well, no. We should still allow creating sockets with unknown numeric
values. The .family attribute should then return the raw integer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:13:13 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Aug 2013 13:13:13 +0000
Subject: [issue18737] Get virtual subclasses of an ABC
Message-ID: <1376485993.36.0.633495217077.issue18737@psf.upfronthosting.co.za>


New submission from Christian Heimes:

ABCs are missing one important introspection feature. They have no API to get registered virtual subclasses. The patch implements a new method get_virtual_subclasses(recurse=False).

ABC.get_virtual_subclasses() returns the direct virtual subclasses of an ABC. ABC.get_virtual_subclasses(recuse=True) also takes subclasses of the ABC as well as subclasses of registered virtual classes into account.

Example:
>>> import numbers
>>> numbers.Number.get_virtual_subclasses()
set()
>>> numbers.Number.get_virtual_subclasses(True)
{<class 'float'>, <class 'bool'>, <class 'int'>, <class 'complex'>}
>>> numbers.Integral.get_virtual_subclasses()
{<class 'int'>}
>>> numbers.Integral.get_virtual_subclasses(True)
{<class 'int'>, <class 'bool'>}

----------
components: Library (Lib)
files: virtual_subclasses.patch
keywords: patch
messages: 195150
nosy: christian.heimes, rhettinger, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Get virtual subclasses of an ABC
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31290/virtual_subclasses.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18737>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:17:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 13:17:31 +0000
Subject: [issue18737] Get virtual subclasses of an ABC
In-Reply-To: <1376485993.36.0.633495217077.issue18737@psf.upfronthosting.co.za>
Message-ID: <1376486251.31.0.366054442405.issue18737@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm not sure "recurse" is a relevant distinction here. A subclass of a subclass is still a subclass. "Virtual" subclasses should not be different.

At the very least, if "recurse" is kept, I would expect it to be True by default.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18737>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:22:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 13:22:36 +0000
Subject: [issue18737] Get virtual subclasses of an ABC
In-Reply-To: <1376485993.36.0.633495217077.issue18737@psf.upfronthosting.co.za>
Message-ID: <1376486556.03.0.0133393664531.issue18737@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Another problem is what happens when an implementation uses non-"virtual" inheritance:

>>> issubclass(collections.UserDict, collections.abc.Mapping)
True
>>> collections.UserDict in collections.abc.Mapping.get_virtual_subclasses(True)
False

IOW, I think this get_virtual_subclasses() proposal is too low-level to be commonly useful, since it depends on implementation details (whether subclassing is direct or not, whether registering is implicit or explicit).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18737>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:24:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Aug 2013 13:24:13 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376486653.4.0.0559327735823.issue18720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm surprised that test_repr is not failed. '%i' % socket.AddressFamily.AF_INET returns 'AddressFamily.AF_INET' instead of '2' as I expected. Is not this a bug in IntEnum implementation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:29:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 13:29:17 +0000
Subject: [issue18682] [PATCH] remove bogus codepath from pprint._safe_repr
In-Reply-To: <1375950566.41.0.226660086473.issue18682@psf.upfronthosting.co.za>
Message-ID: <1376486957.77.0.615124443928.issue18682@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ran some benchmark numbers:

$ ./python -m timeit -s "from pprint import saferepr; s='?\"x' * 1000" "saferepr(s)"
-> before patch: 555 usec per loop
-> after patch: 10.9 usec per loop

$ ./python -m timeit -s "from pprint import saferepr; s='xxx' * 1000" "saferepr(s)"
-> before patch: 290 usec per loop
-> after patch: 8.68 usec per loop

----------
nosy: +pitrou, serhiy.storchaka
stage:  -> patch review
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18682>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:39:49 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Aug 2013 13:39:49 +0000
Subject: [issue18737] Get virtual subclasses of an ABC
In-Reply-To: <1376485993.36.0.633495217077.issue18737@psf.upfronthosting.co.za>
Message-ID: <1376487589.58.0.579762386816.issue18737@psf.upfronthosting.co.za>


Christian Heimes added the comment:

It's called get_VIRTUAL_subclasses() for a reason. You can get the real subclasses of an ABC with standard tool, e.g. recurse into __subclasses__(). For virtual subclasses you have to deal with the internals like _abc_registry. I could implement all four cases: recurse True/False, only virtual True/False. But I prefer not to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18737>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:40:47 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 13:40:47 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376487647.21.0.648191564969.issue18720@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Attaching a new patch that uses Serhiy's suggestion to avoid the duplication, and uses Antoine's suggestion to keep socket.family working even if the family is an unknown numeric constant.

Note that the latter is challenging to test - I need families the OS knows and socket doesn't. Any suggestions are welcome. For the time being the test I cooked up is an abomination ;-)

----------
Added file: http://bugs.python.org/file31291/socket-intenum-af.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:43:11 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 13:43:11 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376486653.4.0.0559327735823.issue18720@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda9ouPDhosgfv9=qH2ugiWLQ5QG+TbRNaruBWRukc1QDcQ@mail.gmail.com>


Eli Bendersky added the comment:

On Wed, Aug 14, 2013 at 6:24 AM, Serhiy Storchaka <report at bugs.python.org>wrote:

>
> Serhiy Storchaka added the comment:
>
> I'm surprised that test_repr is not failed. '%i' %
> socket.AddressFamily.AF_INET returns 'AddressFamily.AF_INET' instead of '2'
> as I expected. Is not this a bug in IntEnum implementation?
>

I did notice it when playing with the implementation. Perhaps %i doesn't
call enum? Need to look into it more carefully...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:47:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 13:47:15 +0000
Subject: [issue18737] Get virtual subclasses of an ABC
In-Reply-To: <1376487589.58.0.579762386816.issue18737@psf.upfronthosting.co.za>
Message-ID: <1921401657.62182355.1376488029256.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> It's called get_VIRTUAL_subclasses() for a reason. You can get the
> real subclasses of an ABC with standard tool, e.g. recurse into
> __subclasses__().

What use case are you trying to solve? If I want to find out all classes
which implement an ABC, I don't care whether they implement it "virtually"
or not. OTOH, I do care that the results are stable and reliable, i.e.
that they don't change when someone changes from virtual inheritance to
real inheritance as an implementation detail.

For comparison, issubclass() doesn't make a difference between real and
virtual subclasses, or direct and recursive.

> For virtual subclasses you have to deal with the
> internals like _abc_registry. I could implement all four cases:
> recurse True/False, only virtual True/False.

I don't care about all four cases. What I'm saying is that only
"recurse=True, only virtual=False" makes sense from an user's POV.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18737>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:48:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Aug 2013 13:48:25 +0000
Subject: [issue18682] [PATCH] remove bogus codepath from pprint._safe_repr
In-Reply-To: <1375950566.41.0.226660086473.issue18682@psf.upfronthosting.co.za>
Message-ID: <1376488105.75.0.431524230903.issue18682@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

We can just remove "if typ is str:" case at all. A general case works for strings.

But for performance (this will slowdown Antoine's tests by 15-20%) we should left it and may be even extend it to other builtin types:

builtin_type = (str, int, float, NoneType, list, tuple, dict, set, bytes): # or may be use a set?
...
    if typ in builtin_type:
        return repr(object), True, False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18682>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:48:56 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 13:48:56 +0000
Subject: [issue18738] % formatting incomplete for Enum
Message-ID: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>


New submission from Ethan Furman:

While `.format()` works fine with enum, %-formatting does not:

--> class AF(enum.IntEnum):
...   IPv4 = 1
...   IPv6 = 2
... 

--> AF.IPv4
<AF.IPv4: 1>

--> '%s' % AF.IPv4
'AF.IPv4'

--> '%r' % AF.IPv4
'<AF.IPv4: 1>'

--> '%d' % AF.IPv4
'AF.IPv4'

--> '%i' % AF.IPv4
'AF.IPv4'

--> '%x' % AF.IPv4
'1'

--> '%o' % AF.IPv4
'1'

Hex and octal work, decimal and integer do not.

----------
messages: 195160
nosy: barry, eli.bendersky, ethan.furman, serhiy.storchaka
priority: normal
severity: normal
status: open
title: % formatting incomplete for Enum
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:49:59 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 13:49:59 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376488199.03.0.577794741529.issue18720@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Issue18738 created.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:55:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Aug 2013 13:55:42 +0000
Subject: [issue18738] % formatting incomplete for Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376488542.14.0.384919056452.issue18738@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

`.format()` is surprised too.

>>> '{:}'.format(AF.IPv4)
'AF.IPv4'
>>> '{:10}'.format(AF.IPv4)
'         1'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:56:04 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Aug 2013 13:56:04 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376488564.32.0.772541206314.issue18720@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The manual list of AF_ prefixes looks ugly. We are going to run into the same problem for every module. How about an additional constructor that takes a name, dict and string prefix?

class IntEnum(int, Enum):
    @classmethod
    def from_moduledict(cls, name, moddict, prefix):
        members = {name: value for name, value in moddict.items()
                   if name.startswith(prefix)}
        return cls(name, members)

>>> import socket, enum, pprint
>>> AddressFamily = enum.IntEnum.from_moduledict("AddressFamily", socket.__dict__, "AF_")
>>> pprint.pprint(dict(AddressFamily.__members__))
{'AF_APPLETALK': <AddressFamily.AF_APPLETALK: 5>,
 'AF_ASH': <AddressFamily.AF_ASH: 18>,
 'AF_ATMPVC': <AddressFamily.AF_ATMPVC: 8>,
 'AF_ATMSVC': <AddressFamily.AF_ATMSVC: 20>,
 'AF_AX25': <AddressFamily.AF_AX25: 3>,
 'AF_BLUETOOTH': <AddressFamily.AF_BLUETOOTH: 31>,
 'AF_BRIDGE': <AddressFamily.AF_BRIDGE: 7>,
 'AF_CAN': <AddressFamily.AF_CAN: 29>,
 'AF_DECnet': <AddressFamily.AF_DECnet: 12>,
 'AF_ECONET': <AddressFamily.AF_ECONET: 19>,
 'AF_INET': <AddressFamily.AF_INET: 2>,
 'AF_INET6': <AddressFamily.AF_INET6: 10>,
 'AF_IPX': <AddressFamily.AF_IPX: 4>,
 'AF_IRDA': <AddressFamily.AF_IRDA: 23>,
 'AF_KEY': <AddressFamily.AF_KEY: 15>,
 'AF_LLC': <AddressFamily.AF_LLC: 26>,
 'AF_NETBEUI': <AddressFamily.AF_NETBEUI: 13>,
 'AF_NETLINK': <AddressFamily.AF_NETLINK: 16>,
 'AF_NETROM': <AddressFamily.AF_NETROM: 6>,
 'AF_PACKET': <AddressFamily.AF_PACKET: 17>,
 'AF_PPPOX': <AddressFamily.AF_PPPOX: 24>,
 'AF_RDS': <AddressFamily.AF_RDS: 21>,
 'AF_ROSE': <AddressFamily.AF_ROSE: 11>,
 'AF_ROUTE': <AddressFamily.AF_NETLINK: 16>,
 'AF_SECURITY': <AddressFamily.AF_SECURITY: 14>,
 'AF_SNA': <AddressFamily.AF_SNA: 22>,
 'AF_TIPC': <AddressFamily.AF_TIPC: 30>,
 'AF_UNIX': <AddressFamily.AF_UNIX: 1>,
 'AF_UNSPEC': <AddressFamily.AF_UNSPEC: 0>,
 'AF_WANPIPE': <AddressFamily.AF_WANPIPE: 25>,
 'AF_X25': <AddressFamily.AF_X25: 9>}

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:57:35 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Aug 2013 13:57:35 +0000
Subject: [issue18738] % formatting incomplete for Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376488655.68.0.997538877179.issue18738@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 15:59:12 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 13:59:12 +0000
Subject: [issue18738] % formatting incomplete for Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376488752.77.0.227229442864.issue18738@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

In Objects/unicodeobject.c when it gets into mainformatlong, an IntEnum is recognized as an integer (passes PyLong_Check) and goes into formatlong. There, in the cases of 'd', 'i', 'u' it has:

    case 'u':
        /* Special-case boolean: we want 0/1 */
        if (PyBool_Check(val))
            result = PyNumber_ToBase(val, 10);
        else
            result = Py_TYPE(val)->tp_str(val);
        break;

So tp_str is invoked...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 16:03:12 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 14:03:12 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376488992.07.0.486238963052.issue18720@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Christian, this is an interesting idea - but I suggest we review it once we actually get to convert "many modules". For the time being the manual listing is gone in the recent patch, and for a number of constant families in the same module (i.e. SOCK_* that will be added here) we can combine the lookup into a single loop - so no need walking the module dict multiple times.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 16:03:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Aug 2013 14:03:27 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376489007.29.0.202339708413.issue18720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I thing the AddressFamily enum class and the family property should be documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 16:07:01 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 14:07:01 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376489007.29.0.202339708413.issue18720@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda921i+udva0fUtSYB0N02fAxfA7kKLFdCB_9ur_gZON3w@mail.gmail.com>


Eli Bendersky added the comment:

> I thing the AddressFamily enum class and the family property should be
> documented.
>

I'm leaving the documentation to the end when we decide on the
implementation strategy. Once that happens I'll post a patch with .rst
changes, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 16:08:23 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 14:08:23 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376489303.64.0.42905078755.issue18606@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Wed Aug 14 16:12:32 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 14:12:32 +0000
Subject: [issue18738] % formatting incomplete for Enum
In-Reply-To: <1376488542.14.0.384919056452.issue18738@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda8dCSL6VpGU9cUa-OPmGVpdxgxe-mx=j+pFj+yWHqO-PA@mail.gmail.com>


Eli Bendersky added the comment:

On Wed, Aug 14, 2013 at 6:55 AM, Serhiy Storchaka <report at bugs.python.org>wrote:

>
> Serhiy Storchaka added the comment:
>
> `.format()` is surprised too.
>
> >>> '{:}'.format(AF.IPv4)
> 'AF.IPv4'
> >>> '{:10}'.format(AF.IPv4)
> '         1'
>
>
Oh, this looks like a bug in str.format (and probably the %i behavior too).
Python allows subclassing int and providing custom __str__/__repr__. The
formatting tools should behave sensically in this situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 16:12:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Aug 2013 14:12:58 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376489578.4.0.259713961011.issue18720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Nitpick: If we have grouped this constants in an enum class perhaps it will be good if they will be enumerated in the order of its values. Or no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Wed Aug 14 16:14:40 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 14:14:40 +0000
Subject: [issue18738] % formatting incomplete for Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376489680.1.0.926673379402.issue18738@psf.upfronthosting.co.za>


Ethan Furman added the comment:

'{:}'.format(AF.IPv4) is incorrect, but '{:10}'.format(AF.IPv4) behaves as it should.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 16:16:39 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 14:16:39 +0000
Subject: [issue18738] % formatting incomplete for Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376489799.25.0.915983110794.issue18738@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Looks like Objects/unicodeobject.c needs the same enhancement that Modules/_json.c received: convert int/float subclasses into actual ints/floats before continuing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 16:18:28 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 14:18:28 +0000
Subject: [issue18738] % formatting incomplete for Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376489908.0.0.557876092117.issue18738@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Ethan, str.format uses __format__. We don't seem to provide a custom one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 16:19:11 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 14:19:11 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376489951.29.0.811148823125.issue18738@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
title: % formatting incomplete for Enum -> String formatting (% and str.format) issues with Enum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 16:22:04 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 14:22:04 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376490124.43.0.0196679714094.issue18738@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Gotcha.  I'm on it.

----------
assignee:  -> ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 16:49:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Aug 2013 14:49:00 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <3cFYZz3ShNz7LkD@mail.python.org>


Roundup Robot added the comment:

New changeset 3b82e0d83bf9 by Richard Oudkerk in branch 'default':
Issue #8713: Support alternative start methods in multiprocessing on Unix.
http://hg.python.org/cpython/rev/3b82e0d83bf9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Wed Aug 14 17:04:47 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 14 Aug 2013 15:04:47 +0000
Subject: [issue18739] math.log of a long returns a different value of math.log
	of an int
Message-ID: <1376492687.31.0.627121997874.issue18739@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

This is a very odd inconsistency in math.log behavior.  That said, it is probably only a single bit imprecision at the end of the float result.  Still, 10 == 10L so I'd expect math.log of both to give the same result.

oss/cpython/2.7:LOAS$ ./python
Python 2.7.5+ (2.7:395ac61ebe1a, Aug 14 2013, 07:11:35) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.log(10) - math.log(10L)
4.440892098500626e-16
>>> math.log(10)
2.302585092994046
>>> math.log(10L)
2.3025850929940455
>>> 

In Python 3.3 things seem fine and match the int behavior from 2.7 above despite the internal number implementation being a PyLong in 3.x:

>>> math.log(10)
2.302585092994046

----------
messages: 195175
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: math.log of a long returns a different value of math.log of an int
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18739>
_______________________________________

From report at bugs.python.org  Wed Aug 14 17:05:49 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Aug 2013 15:05:49 +0000
Subject: [issue18739] math.log of a long returns a different value of math.log
	of an int
In-Reply-To: <1376492687.31.0.627121997874.issue18739@psf.upfronthosting.co.za>
Message-ID: <1376492749.8.0.860242763416.issue18739@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Fascinating, how did you find the issue?

----------
nosy: +christian.heimes, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18739>
_______________________________________

From report at bugs.python.org  Wed Aug 14 17:11:04 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 Aug 2013 15:11:04 +0000
Subject: [issue18698] importlib.reload() does not return the module in
	sys.modules
In-Reply-To: <1376090838.27.0.832453640234.issue18698@psf.upfronthosting.co.za>
Message-ID: <1376493064.23.0.0885738481828.issue18698@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I think you mean in 3.3 and yes. =) Patch LGTM so I say fix in 3.3 and merge into default.

----------
assignee:  -> eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18698>
_______________________________________

From report at bugs.python.org  Wed Aug 14 17:12:37 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 14 Aug 2013 15:12:37 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1376493157.04.0.429672297278.issue8713@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> Good for me. This is a very nice addition!

Thanks.  

I do see a couple of failed assertions on Windows which presumably happen in a child process because they do not cause a failure:

    Assertion failed: !collecting, file ..\Modules\gcmodule.c, line 1617

The assertion is in _PyGC_CollectNoFail() and checks that it is not called recursively.  See

    http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/2510/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Wed Aug 14 17:24:23 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 15:24:23 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376493863.97.0.561531232892.issue18738@psf.upfronthosting.co.za>


Ethan Furman added the comment:

The %-formatting needs to be handled by str, correct?

What is '{:}' supposed to mean?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 17:28:30 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Aug 2013 15:28:30 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376493863.97.0.561531232892.issue18738@psf.upfronthosting.co.za>
Message-ID: <DD9E1F7D-0231-4EE9-9C92-B268B152A65F@trueblade.com>


Eric V. Smith added the comment:

> What is '{:}' supposed to mean?
> 

It should be the same as '{}'. That is, an empty format string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 17:37:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 15:37:36 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1376493157.04.0.429672297278.issue8713@psf.upfronthosting.co.za>
Message-ID: <1273793863.62351434.1376494648984.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> I do see a couple of failed assertions on Windows which presumably
> happen in a child process because they do not cause a failure:
> 
>     Assertion failed: !collecting, file ..\Modules\gcmodule.c, line
>     1617
> 
> The assertion is in _PyGC_CollectNoFail() and checks that it is not
> called recursively.  See
> 
>     http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/2510/steps/test/logs/stdio

That's extremely weird. _PyGC_CollectNoFail() is only called from
PyImport_Cleanup, which itself is only called from Py_Finalize()
and Py_EndInterpreter(). It should be basically impossible for the
GC to be already collecting garbage at that point... 

Perhaps you could try to find out in which test this happens?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Wed Aug 14 17:47:17 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Aug 2013 15:47:17 +0000
Subject: [issue18737] Get virtual subclasses of an ABC
In-Reply-To: <1376485993.36.0.633495217077.issue18737@psf.upfronthosting.co.za>
Message-ID: <1376495237.5.0.553323208411.issue18737@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I like to do something similar to marker interfaces [1] with ABCs. For introspection and documentation I need a way to get all non-abstract classes that are implemented by an ABC.

How about I change the implementation to get_subclasses(direct=False) to return all virtual and real subclasses of an ABC? I can filter out abstract types with inspect.isabstract() later.

[1] http://www.muthukadan.net/docs/zca.html#marker-interfaces

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18737>
_______________________________________

From report at bugs.python.org  Wed Aug 14 17:54:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Aug 2013 15:54:55 +0000
Subject: [issue18737] Get virtual subclasses of an ABC
In-Reply-To: <1376495237.5.0.553323208411.issue18737@psf.upfronthosting.co.za>
Message-ID: <448171054.62376305.1376495689205.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> I like to do something similar to marker interfaces [1] with ABCs.
> For introspection and documentation I need a way to get all
> non-abstract classes that are implemented by an ABC.

You mean that implement an ABC? But you also need to return real
subclasses that implement the ABC (e.g. UserDict in the example above).

> How about I change the implementation to get_subclasses(direct=False)
> to return all virtual and real subclasses of an ABC? I can filter
> out abstract types with inspect.isabstract() later.

Sounds ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18737>
_______________________________________

From report at bugs.python.org  Wed Aug 14 18:11:10 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 16:11:10 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376496670.33.0.0952057949116.issue18738@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Which is the same as '%s', yes?  In that case, the current behavior of '{:}'.format(AF.IPv4) is correct, isn't it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 18:48:58 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 14 Aug 2013 16:48:58 +0000
Subject: [issue18739] math.log of a long returns a different value of math.log
	of an int
In-Reply-To: <1376492687.31.0.627121997874.issue18739@psf.upfronthosting.co.za>
Message-ID: <1376498938.21.0.68965263746.issue18739@psf.upfronthosting.co.za>


Tim Peters added the comment:

Yup - 2.7 evaluates this in a less precise way, as

log(10L) = log(10./16 * 2**4) = log(0.625) + log(2)*4

>>> log(10L) == log(0.625) + log(2)*4
True

This patterns works well even for longs that are far too large to represent as a double; e.g.,

>>> log(1L << 50000)
34657.35902799726

which is evaluated internally as log(0.5) + log(2) * 50001:

>>> log(1L << 50000) == log(0.5) + log(2) * 50001
True

Python 3 is more careful, falling back to this pattern _only_ if converting the long to a double overflows.  Of course 10L can be represented exactly as a double, so Python 3 evaluates it directly as log(float(10L)) = log(10.0).  It's minor difference overall, but definitely visible ;-)

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18739>
_______________________________________

From report at bugs.python.org  Wed Aug 14 18:55:43 2013
From: report at bugs.python.org (Ron Adam)
Date: Wed, 14 Aug 2013 16:55:43 +0000
Subject: [issue18740] str is number methods don't recognize '.'
Message-ID: <1376499343.4.0.632911217056.issue18740@psf.upfronthosting.co.za>


New submission from Ron Adam:

Shouldn't at least isdecimal return True?

>>> '123.0'.isdecimal()
False
>>> '123.0'.isalnum()
False
>>> '123.0'.isnumeric()
False
>>> '123.0'.isdigit()
False

----------
components: Interpreter Core
messages: 195186
nosy: ron_adam
priority: normal
severity: normal
status: open
title: str is number methods don't recognize '.'
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18740>
_______________________________________

From report at bugs.python.org  Wed Aug 14 19:03:29 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 14 Aug 2013 17:03:29 +0000
Subject: [issue18739] math.log of a long returns a different value of math.log
	of an int
In-Reply-To: <1376492687.31.0.627121997874.issue18739@psf.upfronthosting.co.za>
Message-ID: <1376499809.56.0.429051073303.issue18739@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

We found this while refactoring an API to be more consistent about returning longs vs ints in specific cases.  This resulted in another unittest that was using math.log for a nicer display of the value by magnitude to fail as the result was slightly different for the two input types.

arguably that is a fragile test as it cares about the last couple bits of a float... but that such a test exists does suggest that making a future 2.7.6+ release more pedantic about the behavior on values that safely fit into a double might break an odd test or three out there.  OTOH, it makes things more consistent all around and match 3.x in both cases so I'm still be for doing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18739>
_______________________________________

From report at bugs.python.org  Wed Aug 14 19:20:51 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Aug 2013 17:20:51 +0000
Subject: [issue18740] str is number methods don't recognize '.'
In-Reply-To: <1376499343.4.0.632911217056.issue18740@psf.upfronthosting.co.za>
Message-ID: <1376500851.62.0.365308517257.issue18740@psf.upfronthosting.co.za>


Ned Deily added the comment:

isdecimal() is working as documented, isn't it?  A period character serving as a decimal point is not the same as a decimal character.

"Return true if all characters in the string are decimal characters and there is at least one character, false otherwise. Decimal characters are those from general category ?Nd?. This category includes digit characters, and all characters that can be used to form decimal-radix numbers, e.g. U+0660, ARABIC-INDIC DIGIT ZERO."

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18740>
_______________________________________

From report at bugs.python.org  Wed Aug 14 19:50:24 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Aug 2013 17:50:24 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376502624.83.0.0440092301745.issue18738@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I think:

>>> '{:}'.format(AF.IPv4)
'AF.IPv4'

is correct, assuming str(AF.IPv4) is 'AF.IPv4'. I'm not sure what:

>>> '{:10}'.format(AF.IPv4)

should produce. There's a special case for an empty format string calling str().

I think that specifying __format__() would be best, except then you need to decide what sort of format specification language you want to support, and deal with all of the implementation details. Or, maybe just have Enum's __format__ be:

    def __format__(self, fmt):
        return format(str(self), fmt)

which makes the format specification language match str's.

%-formatting is a whole different thing, of course.

----------
assignee: ethan.furman -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 20:25:41 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 18:25:41 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376502624.83.0.0440092301745.issue18738@psf.upfronthosting.co.za>
Message-ID: <520BCBA5.8010706@stoneleaf.us>


Ethan Furman added the comment:

> Eric V. Smith added the comment:
>
> I think that specifying __format__() would be best, except then you need to decide what sort of format specification language you want to support, and deal with all of the implementation details. Or, maybe just have Enum's __format__ be:
>
>      def __format__(self, fmt):
>          return format(str(self), fmt)
>
> which makes the format specification language match str's.

I disagree.  A subclass shouldn't have to write code to provide the /same/ behavior as its superclass, just code for 
different behavior.  In the cases of
     '%d' % int_subclass
or
     '{:d}'.format(int_subclass)

str should be smart enough to actually produce the numeric value, not rely on the subclass' __repr__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 20:35:40 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Aug 2013 18:35:40 +0000
Subject: [issue18718] datetime documentation contradictory on leap second
	support
In-Reply-To: <1376339376.74.0.0279691228671.issue18718@psf.upfronthosting.co.za>
Message-ID: <3cFfcX1kWpz7Lk0@mail.python.org>


Roundup Robot added the comment:

New changeset 5063dab96843 by David Wolever in branch '2.7':
Issue #18718: datetime documentation contradictory on leap second support
http://hg.python.org/cpython/rev/5063dab96843

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18718>
_______________________________________

From report at bugs.python.org  Wed Aug 14 20:39:29 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Aug 2013 18:39:29 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <520BCBA5.8010706@stoneleaf.us>
Message-ID: <520BCEDB.1050301@trueblade.com>


Eric V. Smith added the comment:

>>
>> I think that specifying __format__() would be best, except then you need to decide what sort of format specification language you want to support, and deal with all of the implementation details. Or, maybe just have Enum's __format__ be:
>>
>>      def __format__(self, fmt):
>>          return format(str(self), fmt)
>>
>> which makes the format specification language match str's.
> 
> I disagree.  A subclass shouldn't have to write code to provide the /same/ behavior as its superclass, just code for 
> different behavior.  In the cases of
>      '%d' % int_subclass
> or
>      '{:d}'.format(int_subclass)
> 
> str should be smart enough to actually produce the numeric value, not rely on the subclass' __repr__.

I'm not sure which "str" you mean here: "str should be smart enough to
actually produce the numeric value".

For the format version, what gets called is:

int_subclass.__format__('d'), which is int.__format__(int_subclass,
'd'), which produces '1', assuming int(int_subclass) is 1.

So, there's no "str" involved anywhere, except the one on which
.format() is called ('{:d}'), and it doesn't know about the types of any
arguments or what the format specifiers mean, so it can't make any
decisions.

Which is why it's easier to think of this in terms of:
format(int_subclass, 'd')

instead of:
'{:d}'.format(int_subclass)

It's int_subclass, and only int_subclass, that gets to decide what the
format specifier means. We can either let it fall back to int.__format__
(the default), or str.__format__ (which I suggest above), or it can do
it's own custom thing with the format specifier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 20:47:18 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 14 Aug 2013 18:47:18 +0000
Subject: [issue18739] math.log of a long returns a different value of math.log
	of an int
In-Reply-To: <1376492687.31.0.627121997874.issue18739@psf.upfronthosting.co.za>
Message-ID: <1376506038.12.0.50193878507.issue18739@psf.upfronthosting.co.za>


Tim Peters added the comment:

FYI, the improvement was made in these 2 changesets:

c8dc4b5e54fb
a9349fd3d0f7

If desired, those could presumably be grafted back into the 2.7 branch.

The commit messages refer to issue #9599, but that appears to be mistaken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18739>
_______________________________________

From report at bugs.python.org  Wed Aug 14 20:48:59 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 18:48:59 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <520BCEDB.1050301@trueblade.com>
Message-ID: <520BD11B.3040804@stoneleaf.us>


Ethan Furman added the comment:

> Eric V. Smith added the comment:
>
> For the format version, what gets called is:
>
> int_subclass.__format__('d'), which is int.__format__(int_subclass,
> 'd'), which produces '1', assuming int(int_subclass) is 1.

Ah, I didn't realize.  Thanks.

> So, there's no "str" involved anywhere, except the one on which
> .format() is called ('{:d}'), and it doesn't know about the types of any
> arguments or what the format specifiers mean, so it can't make any
> decisions.

As far as format goes, I don't think there is a problem.  It's behaving just like it should (which makes sense, since 
IntEnum is derived from int and is already using int's __format__ by default).

The problem, then, is just with %-formatting, which is squarely a str (aka Objects/unicodeobject.c) issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 20:50:14 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 14 Aug 2013 18:50:14 +0000
Subject: [issue18739] math.log of a long returns a different value of math.log
	of an int
In-Reply-To: <1376492687.31.0.627121997874.issue18739@psf.upfronthosting.co.za>
Message-ID: <1376506214.92.0.391546296834.issue18739@psf.upfronthosting.co.za>


Tim Peters added the comment:

OK, the correct one is issue #9959.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18739>
_______________________________________

From report at bugs.python.org  Wed Aug 14 20:55:05 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 18:55:05 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <520BD11B.3040804@stoneleaf.us>
Message-ID: <CAF-Rda9xZJC1ZyYbAhAV0ttt=CC3K6P2OXZYDdOrCvRQGbsmNw@mail.gmail.com>


Eli Bendersky added the comment:

On Wed, Aug 14, 2013 at 11:48 AM, Ethan Furman <report at bugs.python.org>wrote:

>
> Ethan Furman added the comment:
>
> > Eric V. Smith added the comment:
> >
> > For the format version, what gets called is:
> >
> > int_subclass.__format__('d'), which is int.__format__(int_subclass,
> > 'd'), which produces '1', assuming int(int_subclass) is 1.
>
> Ah, I didn't realize.  Thanks.
>
> > So, there's no "str" involved anywhere, except the one on which
> > .format() is called ('{:d}'), and it doesn't know about the types of any
> > arguments or what the format specifiers mean, so it can't make any
> > decisions.
>
> As far as format goes, I don't think there is a problem.  It's behaving
> just like it should (which makes sense, since
> IntEnum is derived from int and is already using int's __format__ by
> default).
>

I'm not sure I understand. The discrepancy between {:} and {:10} is clearly
a problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 20:55:05 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 Aug 2013 18:55:05 +0000
Subject: [issue18740] str is number methods don't recognize '.'
In-Reply-To: <1376499343.4.0.632911217056.issue18740@psf.upfronthosting.co.za>
Message-ID: <1376506505.42.0.858954445082.issue18740@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Ned is right, everything is working as documented and intended: as a way to avoid using a regex to test a simple case instead of trying to do anything fancy like identify a number.

----------
nosy: +brett.cannon
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18740>
_______________________________________

From report at bugs.python.org  Wed Aug 14 20:56:32 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Aug 2013 18:56:32 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376506592.53.0.016995600964.issue18738@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

For format, I think the question is "should an IntEnum format like an int, with the wacky exception of a specifier of '', or should it always format like a str?"

I assumed we'd want it to look like the str() version of itself, always. But it's debatable.

I agree the %-formatting question is different, and I further think there's not much we can do there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 21:00:32 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 19:00:32 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376506592.53.0.016995600964.issue18738@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda8n_ameUr0QeY=X3VoaqvZhnk9BALo08_aj9+jjJrvAUA@mail.gmail.com>


Eli Bendersky added the comment:

On Wed, Aug 14, 2013 at 11:56 AM, Eric V. Smith <report at bugs.python.org>wrote:

>
> Eric V. Smith added the comment:
>
> For format, I think the question is "should an IntEnum format like an int,
> with the wacky exception of a specifier of '', or should it always format
> like a str?"
>
> I assumed we'd want it to look like the str() version of itself, always.
> But it's debatable.
>
> I agree the %-formatting question is different, and I further think
> there's not much we can do there.
>

How about always being a string, unless integer formatting "%i" / {d} is
explicitly requested?

The alternative (always a string) is also fine, but the behavior should be
consistent. Certainly field-width-justification ({:}) can't affect the
formatting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 21:03:54 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 14 Aug 2013 19:03:54 +0000
Subject: [issue18735] SSL/TLS pinning for the ssl module
In-Reply-To: <1376479290.6.0.728586195996.issue18735@psf.upfronthosting.co.za>
Message-ID: <1376507034.32.0.982753459009.issue18735@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18735>
_______________________________________

From report at bugs.python.org  Wed Aug 14 21:05:29 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 14 Aug 2013 19:05:29 +0000
Subject: [issue18293] ssl.wrap_socket (cert_reqs=...), getpeercert,
	and unvalidated certificates
In-Reply-To: <1372100693.76.0.99629035685.issue18293@psf.upfronthosting.co.za>
Message-ID: <1376507129.06.0.0874226954695.issue18293@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18293>
_______________________________________

From report at bugs.python.org  Wed Aug 14 21:07:01 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 14 Aug 2013 19:07:01 +0000
Subject: [issue18735] SSL/TLS pinning for the ssl module
In-Reply-To: <1376479290.6.0.728586195996.issue18735@psf.upfronthosting.co.za>
Message-ID: <1376507221.63.0.890307948904.issue18735@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

This technique is used in Mercurial and I use it in my projects too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18735>
_______________________________________

From report at bugs.python.org  Wed Aug 14 21:07:21 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 19:07:21 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376506592.53.0.016995600964.issue18738@psf.upfronthosting.co.za>
Message-ID: <520BD569.8090503@stoneleaf.us>


Ethan Furman added the comment:

> Eric V. Smith added the comment:
>
> I assumed we'd want it to look like the str() version of itself, always. But it's debatable.

An IntEnum's str and repr should be (and any format or % codes that are the equivalent) the Enum str and repr.  The % 
and format codes that specifically call for a numeric representation should give that numeric representation (format is 
good here, % is not).

> For format, I think the question is "should an IntEnum format like an int, with the wacky exception of a specifier of '', or should it always format like a str?"
>

I think for format we should treat IntEnums as ints unless the s or r codes are specifically used.

> I agree the %-formatting question is different, and I further think there's not much we can do there.

We can have unicodeobject.c convert int (and float) subclasses to actual ints and floats before getting the numeric 
value (we just did this to _json.c so it could serialize IntEnums).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 21:12:14 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 19:12:14 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <520BD569.8090503@stoneleaf.us>
Message-ID: <CAF-Rda_T8MKaFwbJd2CWHNO4VOTXv99vF8C6pCgv2V0EAuVgdA@mail.gmail.com>


Eli Bendersky added the comment:

On Wed, Aug 14, 2013 at 12:07 PM, Ethan Furman <report at bugs.python.org>wrote:

>
> Ethan Furman added the comment:
>
> > Eric V. Smith added the comment:
> >
> > I assumed we'd want it to look like the str() version of itself, always.
> But it's debatable.
>
> An IntEnum's str and repr should be (and any format or % codes that are
> the equivalent) the Enum str and repr.  The %
> and format codes that specifically call for a numeric representation
> should give that numeric representation (format is
> good here, % is not).
>
> > For format, I think the question is "should an IntEnum format like an
> int, with the wacky exception of a specifier of '', or should it always
> format like a str?"
> >
>
> I think for format we should treat IntEnums as ints unless the s or r
> codes are specifically used.
>

As I wrote above, I rather see it differently. The original intent of Enums
was to have string representation in most cases. So this should be the
default, since most of the time this is what the user wants. No one really
passes explicit s/r codes. In the minority, specialized cases, where the
user wants to force int-like formatting, then the number should be given
and not the member name. This would also be consistent with non-decimal
formatting options like %x and the .format equivalent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 21:15:44 2013
From: report at bugs.python.org (Ron Adam)
Date: Wed, 14 Aug 2013 19:15:44 +0000
Subject: [issue18740] str is number methods don't recognize '.'
In-Reply-To: <1376499343.4.0.632911217056.issue18740@psf.upfronthosting.co.za>
Message-ID: <1376507744.04.0.229117464658.issue18740@psf.upfronthosting.co.za>


Ron Adam added the comment:

I get the same resluts if I make the string by str(123.0).  I was thinking it should test True for the isdecimal case for that.

It seems I missunderstood their purpose/use.  This seems like it would be a very common misunderstanding.

It appears, (Because it isn't stated in the doc strings), that they are for testing what specific sub-group of unicode data, the individual character(s) are in.  I think the methods doc strings should say this and be worded so they are more character specific.  

   """ Tests each character, and returns true if
    all of them are in the unicode _______ sub-group. """

As for testing weather or not a string as a whole represents a number value, it seems try/except is still the best way.  :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18740>
_______________________________________

From report at bugs.python.org  Wed Aug 14 21:21:44 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 14 Aug 2013 19:21:44 +0000
Subject: [issue18740] str is number methods don't recognize '.'
In-Reply-To: <1376499343.4.0.632911217056.issue18740@psf.upfronthosting.co.za>
Message-ID: <1376508104.1.0.589296432796.issue18740@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Feel free to submit an issue suggesting better docstrings as that sounds like it could stand to get some TLC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18740>
_______________________________________

From report at bugs.python.org  Wed Aug 14 21:33:39 2013
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Wed, 14 Aug 2013 19:33:39 +0000
Subject: [issue13504] Meta-issue for "Invent with Python" IDLE feedback
In-Reply-To: <1322613083.36.0.200533745275.issue13504@psf.upfronthosting.co.za>
Message-ID: <1376508819.47.0.980525840801.issue13504@psf.upfronthosting.co.za>


Changes by Kurt B. Kaiser <kbk at shore.net>:


----------
nosy: +kbk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13504>
_______________________________________

From report at bugs.python.org  Wed Aug 14 21:34:13 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Aug 2013 19:34:13 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376508853.21.0.680026839315.issue18738@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I think IntEnum should act like a str for format() purposes. After all, having a useful string representation is a prime reason it exists. If you want it to act like a str() sometimes, and an int() at others, you're going to have to parse the format specifier and figure out what to do. It might be as easy as:

def __format__(self, fmt):
  if len(fmt) >= 1 and fmt[-1] in 'oOxXdD':
    # treat like an int
    return format(self.value, fmt)
  else:
    # treat like a string
    format(str(self), fmt)

But I haven't completely thought it through or tested it.

Or, couldn't we just say it's always str, and if you want to treat it like an int then use .value?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 21:42:01 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 19:42:01 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376509321.25.0.31196418024.issue18738@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Okay, I see your points.  I can certainly agree with going with the str representation when no numeric code is specified.  But, if a numeric code is specified (x, b, d, etc.) then the numeric value should be used.

Agreed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 21:45:56 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 19:45:56 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <CAF-Rda9xZJC1ZyYbAhAV0ttt=CC3K6P2OXZYDdOrCvRQGbsmNw@mail.gmail.com>
Message-ID: <520BDE74.4030209@stoneleaf.us>


Ethan Furman added the comment:

On 08/14/2013 11:55 AM, Eli Bendersky wrote:
>
> I'm not sure I understand. The discrepancy between {:} and {:10} is clearly
> a problem.

Ah, you're right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 21:57:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Aug 2013 19:57:47 +0000
Subject: [issue18682] [PATCH] remove bogus codepath from pprint._safe_repr
In-Reply-To: <1375950566.41.0.226660086473.issue18682@psf.upfronthosting.co.za>
Message-ID: <1376510267.45.0.743586839323.issue18682@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which adds fast path for builtin scalar types.

Or we can just remove a special case for strings.

----------
Added file: http://bugs.python.org/file31292/pprint_safe_repr_scalars.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18682>
_______________________________________

From report at bugs.python.org  Wed Aug 14 22:04:22 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 20:04:22 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376509321.25.0.31196418024.issue18738@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda8XUs=Td7Xkqk-opWrWGd=aoYz1e-F3R6ybfxurdg6S-g@mail.gmail.com>


Eli Bendersky added the comment:

>
> Okay, I see your points.  I can certainly agree with going with the str
> representation when no numeric code is specified.  But, if a numeric code
> is specified (x, b, d, etc.) then the numeric value should be used.
>
> Agreed?
>

 Yes. I suggest to wait a day or two for others to react (night in Europe,
etc). If this sounds good to everyone then it may make sense to split this
issue to one for str.format and another for legacy % formatting, because
the implementation is likely to be different.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 22:08:26 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 14 Aug 2013 20:08:26 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
In-Reply-To: <1375885327.18.0.790620363467.issue18677@psf.upfronthosting.co.za>
Message-ID: <1376510906.31.0.942802942615.issue18677@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

"locally visible" is, I think a very misleading term.  How is

with ignore_error, acquire_resource as r:
   doo_stuff_with_resource(r) #can be silently skipped

any more locally visible than
with acquire_resource_ignore_error as r:
    doo_stuff_with resource(r) # can be silently skipped.

? does the "nested with" syntax immediatelly tell you "hey, the body can be silently skipped"?

Requiring that some context manager patterns must be done with a special syntax is odd.  What is more, it prohibits us to abstract away context managers.  For instance, you can write a function like this

def execute_with_context(ctxt, fn, args):
    with ctxt:
        return fn(*args)

but if your context manager is of the kind mentioned, i.e. requiring the double syntax, you are screwed.

Basically, what I'm proposing (and what the patch provides) is that you can write this code:
@contextmanager
def nestedc(ca, cb):
    with ca as a, cb as b:
        yield a, b

and have it work for _all_ pair of ca, cb.  This then, allows context managers to be used like abstract entities, like other objects in the language.  It is _not_ about flow control, but about completeness.

A similar pattern for functions is already possible:
def nestedf(fa, fb):
    def helper(v):
        return fa(fb(v))
    return helper

And so, we could write:
execute_with_context(nestedc(ca, cb), nestedf(fa, fb), ('foo',))

Current python does not allow this for arbitrary pairs ca, cb.  My version does.  This is what I'm advocating.  That programmers are given the tool to combine context managers if they want.
 

As for "contextlib.nested()".
I'm not necessarily advocation its resuciation in the standardlib, but adding that to the patch here to demonstrate how it now _works_.

Here is a simpler version of contextlib.nested:

@contextmanager
def nested_empty():
    yield []

@contextmanager
def nested_append(prev, next):
    with prev as a, next as b:
        a.append(b)
        yield a

def nested(*managers):
    total = nested_empty()
    for mgr in managers:
        total = nested_append(total, mgr)
    return total

Pretty nice, no?

Now we come to the argument with nested(open(a), open(b)).
I see your point, but I think that the problem is not due to nested, but to open.  Deprecating nested, even as a programming pattern demonstration is throwing out the baby with the bathwater.

I?ve coined the term "hybrid context manager" (at least I think I have)to mean resources that are their own context managers.  They're hybrid because they are acquired explicitly, but can be released via a context manager.  The context manager is a bolt on, an afterthought.  Instead of adding __exit__() to files, and allowing
with open(fn) as f: pass
We should have encouraged the use of proper context managers:
with opened(fn) as f: pass
or 
with closing(f):  pass

Now, we unfortunately have files being context managers and widely see the pattern
with open(fn) as f, open(fn2) as f2:
    pass

But how is this bug here:
with nested(open(fn), open(fn2)) as f, f2: pass

any more devuiys than
f, f2 = open(fn), open(fn2)
with f, f2: pass
?

The problem is that files aren't "real" context managers but "hybrids" and this is what we should warn people about.  The fact that we do have those hybrids in our code base should not be cause to remove tools that are designed to work with "proper" context managers.

The decision to remove "nested" on these grounds sets the precedence that we cannot have any functions that operate on context managers.  In fact, what this is really is saying is this:

"context managers should only be used with the "with" statement and only instantiated in-line.
Anything else may introduce sublte bugs because some context managers are in fact not context managers, but the resource that they manage.
"

In my opinion, it would have been better to deprecate the use of files as context managers, and instead urge people to use proper context managers for the:  (the proposed) contextlib.opened and (the existing) contextlib.closing)

K

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18677>
_______________________________________

From report at bugs.python.org  Wed Aug 14 22:11:24 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Wed, 14 Aug 2013 20:11:24 +0000
Subject: [issue18727] test for writing dictionary rows to CSV
In-Reply-To: <1376409675.57.0.271656920796.issue18727@psf.upfronthosting.co.za>
Message-ID: <1376511084.76.0.832342400624.issue18727@psf.upfronthosting.co.za>


Muhammad Jehanzeb added the comment:

Thanks Antoine,

Attached is the updated version of patch using StringIO

----------
Added file: http://bugs.python.org/file31293/issue18727_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18727>
_______________________________________

From report at bugs.python.org  Wed Aug 14 22:15:09 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Wed, 14 Aug 2013 20:15:09 +0000
Subject: [issue4749] Issue with RotatingFileHandler logging handler on Windows
In-Reply-To: <1230295606.47.0.842082380856.issue4749@psf.upfronthosting.co.za>
Message-ID: <1376511309.65.0.126458903255.issue4749@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4749>
_______________________________________

From report at bugs.python.org  Wed Aug 14 22:19:11 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Aug 2013 20:19:11 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376511551.9.0.618250433545.issue18738@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

If IntEnum.__format__ is going to parse the format string, it's a little fragile. For example, say we modify int.__format__ to understand a "Z" presentation type. Who's going to remember to update IntEnum.__format__?

For reference, the existing integer formats are: "bdoxXn".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 22:32:52 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 20:32:52 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376511551.9.0.618250433545.issue18738@psf.upfronthosting.co.za>
Message-ID: <520BE973.5030703@stoneleaf.us>


Ethan Furman added the comment:

What I'm hoping is to get agreement on what the behavior should be (unspecified format codes use str or repr, specified 
numeric codes use the value), and then persuade folks that int (or PyLong) is where that behavior should be kept (so int 
is subclass friendly) -- then IntEnum (and other int subclasses) don't have to worry about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 22:57:47 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Aug 2013 20:57:47 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376513867.95.0.878649401767.issue18738@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I don't think it's possible for int (PyLong) to handle a decision to format itself as a string. Personally, I'd like this:

>>> format(3, 's')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 's' for object of type 'int'

To continue to be an error.

This is exactly why the __format__ protocol was added: so a type could make a decision on how it should format itself. My only concern is the fragility of the proposed solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 22:58:38 2013
From: report at bugs.python.org (paul j3)
Date: Wed, 14 Aug 2013 20:58:38 +0000
Subject: [issue15428] add "Name Collision" section to argparse docs
In-Reply-To: <1343001632.52.0.429837248023.issue15428@psf.upfronthosting.co.za>
Message-ID: <1376513918.58.0.753208997181.issue15428@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15428>
_______________________________________

From report at bugs.python.org  Wed Aug 14 23:08:30 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Aug 2013 21:08:30 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376514510.83.0.447414419089.issue18738@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 23:13:28 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 21:13:28 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376513867.95.0.878649401767.issue18738@psf.upfronthosting.co.za>
Message-ID: <520BF2F7.8090705@stoneleaf.us>


Ethan Furman added the comment:

--> class Test(enum.IntEnum):
...   one = 1
...   two = 2
...

--> '{}'.format(Test.one)
'Test.one'

--> '{:d}'.format(Test.one)
'1'

--> '{:}'.format(Test.one)
'Test.one'

--> '{:10}'.format(Test.one)
'         1'

Sometimes the str is used, and sometimes the value of the int is used.  I suggesting we tighten that up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 23:21:25 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Wed, 14 Aug 2013 21:21:25 +0000
Subject: [issue18741] Fix typos/spelling mistakes in Lib/*/*/.py files
Message-ID: <1376515284.41.0.228001908428.issue18741@psf.upfronthosting.co.za>


New submission from F?vry Thibault:

Using the same tool described in issue 18705, I fixed more typos.

----------
assignee: docs at python
components: Documentation
files: another_typo_patch.diff
keywords: patch
messages: 195216
nosy: docs at python, iwontbecreative
priority: normal
severity: normal
status: open
title: Fix typos/spelling mistakes in Lib/*/*/.py files
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31294/another_typo_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18741>
_______________________________________

From report at bugs.python.org  Wed Aug 14 23:22:30 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Aug 2013 21:22:30 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376515350.17.0.747291787089.issue18738@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

The value of int is always used, except when the format string is empty. PEP 3101 explicitly requires this behavior. "For all built-in types, an empty format specification will produce the equivalent of str(value)." The "built-in type" here refers to int, since IntEnum is derived from int (at least I think it is: I haven't followed the metaclass and multiple inheritance completely).

If you want it to be different, you need to implement __format__ for IntEnum or a base class (or the metaclass? again, I haven't checked).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 23:26:17 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 21:26:17 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376515350.17.0.747291787089.issue18738@psf.upfronthosting.co.za>
Message-ID: <520BF5F8.80506@stoneleaf.us>


Ethan Furman added the comment:

So what you're saying is that '{:}' is empty, but '{:10}' is not?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 23:29:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Aug 2013 21:29:15 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1376515755.26.0.573474142509.issue18647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

So what now? Just remove unneeded check?

Related issues: issue1633953, issue2537.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18647>
_______________________________________

From report at bugs.python.org  Wed Aug 14 23:38:37 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Aug 2013 21:38:37 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376516317.24.0.848797129006.issue18738@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

> So what you're saying is that '{:}' is empty, but '{:10}' is not?

Yes, exactly. The part before the colon says which argument to .format() to use. The empty string there means "use the next one". The part after the colon is the format specifier. In the first example above, there's an empty string after the colon, and in the second example there's a "10" after the colon.

Which is why it's really easier to use:
format(obj, '')
and
format(obj, '10')
instead of .format examples. By using the built-in format, you only need to write the format specifier, not the ''.format() "which argument am I processing" stuff with the braces and colons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 23:45:05 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Aug 2013 21:45:05 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376516317.24.0.848797129006.issue18738@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda8vV6oPnj7U6jhQ8QH=+qCam8RAjMv8jUHaStF458TCYg@mail.gmail.com>


Eli Bendersky added the comment:

On Wed, Aug 14, 2013 at 2:38 PM, Eric V. Smith <report at bugs.python.org>wrote:

>
> Eric V. Smith added the comment:
>
> > So what you're saying is that '{:}' is empty, but '{:10}' is not?
>
> Yes, exactly. The part before the colon says which argument to .format()
> to use. The empty string there means "use the next one". The part after the
> colon is the format specifier. In the first example above, there's an empty
> string after the colon, and in the second example there's a "10" after the
> colon.
>
> Which is why it's really easier to use:
> format(obj, '')
> and
> format(obj, '10')
> instead of .format examples. By using the built-in format, you only need
> to write the format specifier, not the ''.format() "which argument am I
> processing" stuff with the braces and colons.
>

Eric, I'd have to disagree with this part. Placing strictly formal
interpretation of "empty" aside, it seems to me unacceptable that
field-width affects the interpretation of the string. This appears more
like bug in the .format implementation than the original intention. I
suspect that at this point it may be useful to take this discussion to
pydev to get more opinions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 14 23:48:32 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 14 Aug 2013 21:48:32 +0000
Subject: [issue18677] Enhanced context managers with ContextManagerExit and
	None
In-Reply-To: <1375885327.18.0.790620363467.issue18677@psf.upfronthosting.co.za>
Message-ID: <1376516912.61.0.506554963898.issue18677@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I think you make a good case, but I already tried and failed to convince Guido of this in PEP 377 (see http://www.python.org/dev/peps/pep-0377/#rationale-for-change)

More importantly, see his quoted concerns in http://mail.python.org/pipermail/python-dev/2009-March/087263.html

While you have come up with a much simpler *implementation* for PEP 377, which imposes no additional overhead in the typical case (unlike my implementation, which predated the SETUP_WITH opcode and avoided introducing one, which required wrapping every __enter__ call in a separate try/except block), it still adds a new builtin exception type, and I thing needs a new builtin constant as well.

The latter comes in because I think the bound variable name still needs to be set to something, and rather than abusing any existing constant, I think a new SkipWith constant for both "don't call enter/exit" and "with statement body was skipped" would actually be clearer.

I actually think explaining a custom exception and constant is less of a burden than explaining why factoring out certain constructs with @contextmanager and yield doesn't work properly (that's why I wrote PEP 377 in the first place), but Guido is the one that ultimately needs to be convinced of the gain.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18677>
_______________________________________

From report at bugs.python.org  Thu Aug 15 00:06:40 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Aug 2013 22:06:40 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376518000.28.0.981570167254.issue18738@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

It's not whether a field width is specified that makes it "empty" or not, it's where there's anything in the format specifier at all. I'm trying to simplify the conversation by using format() instead of str.format(), but I'm not succeeding!

Going back to str.format examples:

'{}'.format(Test.one)
# equivalent to format(Test.one, '')
# result is Test.one.__format__('')

'{:d}'.format(Test.one)
# equivalent to format(Test.one, 'd')
# result is Test.one.__format__('d')

'{:}'.format(Test.one)
# equivalent to format(Test.one, '')
# result is Test.one.__format__('')

'{:10}'.format(Test.one)
# equivalent to format(Test.one, '10')
# result is Test.one.__format__('10')

In all of these cases, since there is no Test.one.__format__, int.__format__ is called. int.__format__ contains logic (Python/formatter_unicode.c, line 1422) that says "if the format specifier is empty, return str(self), otherwise do the int formatting". This is in order to comply with the previously mentioned PEP requirement. That's the only place where there's any "treat this as a str instead of an int" logic.

In order to avoid that logic, and cause more format specifiers to result in str-like behavior, we'll need to implement an __format__ somewhere (IntEnum, I guess) that makes the "int or str" decision.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Thu Aug 15 00:12:54 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 22:12:54 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376518000.28.0.981570167254.issue18738@psf.upfronthosting.co.za>
Message-ID: <520C00E5.1000804@stoneleaf.us>


Ethan Furman added the comment:

> In order to avoid that logic, and cause more format specifiers to result in str-like behavior, we'll need to implement an __format__ somewhere (IntEnum, I guess) that makes the "int or str" decision.

If this is the way format is supposed to work, then I'll add __format__ to IntEnum with simple logic that says if not 
letter format code is present, use string formatting, otherwise use int formatting.  That should be future proof.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Thu Aug 15 00:22:18 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Aug 2013 22:22:18 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <520C00E5.1000804@stoneleaf.us>
Message-ID: <520C030B.6060105@trueblade.com>


Eric V. Smith added the comment:

>> In order to avoid that logic, and cause more format specifiers to result in str-like behavior, we'll need to implement an __format__ somewhere (IntEnum, I guess) that makes the "int or str" decision.
> 
> If this is the way format is supposed to work, then I'll add __format__ to IntEnum with simple logic that says if not 
> letter format code is present, use string formatting, otherwise use int formatting.  

Yes, that's exactly how it's supposed to be used, and why __format__
exists at all.

> That should be future proof.

Agreed.

It does mean that a few things that look like int format specifiers
won't be, but I don't think it's a big loss.

For example, '+' only makes sense on an int, but with your proposal it
would be a str format specifier:

>>> format(42, '+')
'+42'
>>> format('42', '+')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Sign not allowed in string format specifier

Again, I don't think any of these would be a big deal. But it does mean
that there are places that could take an int that can't take an IntEnum.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Thu Aug 15 00:31:12 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Aug 2013 22:31:12 +0000
Subject: [issue18742] Abstract base class for hashlib
Message-ID: <1376519472.63.0.753349393836.issue18742@psf.upfronthosting.co.za>


New submission from Christian Heimes:

All hashlib types provide a common interfaces but there is no common super class. The patch implements provides hashlib.CryptoHash abstract base class as common virtual class for all hash types.

The patch also exposes all internal types of the internal hash C modules so I don't have to jump throw the type(constructor()) hoop.

I have also changed __get_builtin_constructor() to use a lookup cache instead of importing the module every time. It is necessary to avoid multiple calls to CryptoHash.register().

----------
files: hashlib_abc.patch
keywords: patch
messages: 195226
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
stage: patch review
status: open
title: Abstract base class for hashlib
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31295/hashlib_abc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18742>
_______________________________________

From report at bugs.python.org  Thu Aug 15 00:47:01 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 22:47:01 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <520C030B.6060105@trueblade.com>
Message-ID: <520C08E5.90607@stoneleaf.us>


Ethan Furman added the comment:

Drat.  IntEnum is supposed to be a drop-in replacement for int.  I guess I'll have to consider more than just the letter 
code to decide whether to go with int.__format__ or str.__format__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Thu Aug 15 01:40:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Aug 2013 23:40:20 +0000
Subject: [issue18425] IDLE Unit test for IdleHistory.py
In-Reply-To: <1373493838.59.0.876568806243.issue18425@psf.upfronthosting.co.za>
Message-ID: <1376523620.78.0.408865292575.issue18425@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Moved most initialization to method setUp to prevent cascading of test failures. Added info about History.fetch and FetchTest.fetch_test methods. Added tests for non-cyclic and special behavior and for fetch event wrappers. Coverage is essentially 100%.

----------
stage: patch review -> committed/rejected
Added file: http://bugs.python.org/file31296/test_idlehistory4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18425>
_______________________________________

From report at bugs.python.org  Thu Aug 15 02:18:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Aug 2013 00:18:33 +0000
Subject: [issue18698] importlib.reload() does not return the module in
	sys.modules
In-Reply-To: <1376090838.27.0.832453640234.issue18698@psf.upfronthosting.co.za>
Message-ID: <3cFpD621Dcz7LjX@mail.python.org>


Roundup Robot added the comment:

New changeset e22e7268e58a by Eric Snow in branch '3.3':
issue #18698: ensure importlib.reload() returns the module out of sys.modules.
http://hg.python.org/cpython/rev/e22e7268e58a

New changeset 1af087712e69 by Eric Snow in branch 'default':
Closes issue #18698: ensure importlib.reload() returns the module out of sys.modules.
http://hg.python.org/cpython/rev/1af087712e69

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18698>
_______________________________________

From report at bugs.python.org  Thu Aug 15 02:23:16 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 15 Aug 2013 00:23:16 +0000
Subject: [issue18698] importlib.reload() does not return the module in
	sys.modules
In-Reply-To: <1376090838.27.0.832453640234.issue18698@psf.upfronthosting.co.za>
Message-ID: <1376526196.39.0.240676706244.issue18698@psf.upfronthosting.co.za>


Eric Snow added the comment:

oops.  That commit message for 3.3 should have read "imp.reload()". :)

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18698>
_______________________________________

From report at bugs.python.org  Thu Aug 15 07:01:51 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 15 Aug 2013 05:01:51 +0000
Subject: [issue18743] References to non-existant "StringIO" module
Message-ID: <1376542911.78.0.658455842148.issue18743@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

Doing a "grep StringIO Doc/library/*.rst" shows a handful of references to the old StringIO library. Notably:

gzip.rst
mailbox.rst
tempfile.rst
test.rst
unittest.mock.rst
xml.dom.minidom.rst

----------
assignee: docs at python
components: Documentation
messages: 195231
nosy: docs at python, jcea
priority: normal
severity: normal
status: open
title: References to non-existant "StringIO" module
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18743>
_______________________________________

From report at bugs.python.org  Thu Aug 15 07:20:25 2013
From: report at bugs.python.org (K Richard Pixley)
Date: Thu, 15 Aug 2013 05:20:25 +0000
Subject: [issue18744] pathological performance using tarfile
Message-ID: <1376544025.63.0.959353089302.issue18744@psf.upfronthosting.co.za>


New submission from K Richard Pixley:

There's a problem with tarfile.  Write a program to traverse the contents of a modest sized tar archive.  Make sure your tar archive is compressed.  Then read the tar archive with your program.

I'm finding that allowing tarfile to read a compressed archive costs me somewhere on the order of a 60x performance penalty by comparison to opening the file with gzip, then passing the gzip contents to tarfile.  Programs that could take a few minutes are literally taking a few hours when using tarfile.

This seems stupid.  The tarfile library could do the same thing I'm doing manually, in fact, I had assumed that it would and was surprised by the performance I was seeing, so I ran with the profiler and saw millions of decompression calls.  It's almost as though the tarfile library is decompressing the entire archive for every member extraction.

Note, you can get even worse performance if you sort the member names and then extract in that order.  I'm not sure whether this "should" matter since the tar file order is sequential.

----------
components: Library (Lib)
messages: 195232
nosy: teamnoir
priority: normal
severity: normal
status: open
title: pathological performance using tarfile
type: performance
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18744>
_______________________________________

From report at bugs.python.org  Thu Aug 15 07:23:29 2013
From: report at bugs.python.org (Mikhail Traskin)
Date: Thu, 15 Aug 2013 05:23:29 +0000
Subject: [issue18219] csv.DictWriter is slow when writing files with large
	number of columns
In-Reply-To: <1371273159.09.0.766674685212.issue18219@psf.upfronthosting.co.za>
Message-ID: <1376544209.54.0.151052187667.issue18219@psf.upfronthosting.co.za>


Mikhail Traskin added the comment:

> What is the purpose in touching fieldnames [...]

Wrapping the fieldnames property and tupleizing it guarantees that fieldnames and _fieldset fields are consistent.
Otherwise, having a separate _fieldset field means that someone who is modifying the fieldnames field will not modify the _fieldset. This will result in inconsistent DictWriter behavior. Normal DictWriter users (ones that do not modify fieldnames after DictWriter was created) will not notice this wrapper. "Non-normal" DictWriter will have their code broken, but it is better than having inconsistent internal data structures since these errors are very hard to detect. If you insist on keeping the interface intact, then use the attached v3 of the patch: it creates a fieldset object every time the _dict_to_list method is executed. This does slow execution down, but performance is acceptable, just about 1.5 time slower than version with _fieldset field.

> wrong_fields could be calculated with [...]
I believe it is better to report all wrong fields at ones. In addition this optimization is meaningless, since usually, unless something is wrong, the field check will require full scan of the rowdict.

> That said, in 3.x, replacing [...]

In 2.x the list comprehension version is faster than the set difference version. In 3.x the set difference is slightly faster (maybe 10% faster). However, list comprehension works both in 2.x and 3.x, while set difference requires different code for them. Hence I prefer sticking with list comprehension.

> Does test/text_cvs have tests [...]
No there are no tests for wrong fields. Correct fields are already checked with standard writing tests. I do not know how you write tests for exception handling. If you provide a link with instructions, I can write the missing test part.

> Also, if you have not done so yet, please go to [...]
I have already done this.

----------
Added file: http://bugs.python.org/file31297/csvdictwriter.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18219>
_______________________________________

From report at bugs.python.org  Thu Aug 15 07:33:50 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 15 Aug 2013 05:33:50 +0000
Subject: [issue17628] str==str: compare the first character before calling
	memcmp()
In-Reply-To: <1365024552.84.0.0461498193244.issue17628@psf.upfronthosting.co.za>
Message-ID: <1376544830.0.0.728763429384.issue17628@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The dont-compare-first-last patch looks about right.

The "if (len == 0) return 1;" shortcut perhaps should be taken out.  It makes the common case pay (if only slightly) for the rare case (which of course, never gets predicted).  This whole code block gets inlined in the very tight inner loops of the set/dict lookkey functions -- it should be as thin as possible.

One other thing to take a look at is the "PyUnicode_GET_LENGTH(a) * PyUnicode_KIND(a)" expression.  The disassembly shows an imulq instruction rather than the usual scaled LEA computation.  I don't know if this can be sped-up by a predictable branch for the common case.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17628>
_______________________________________

From report at bugs.python.org  Thu Aug 15 07:36:06 2013
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Aug 2013 05:36:06 +0000
Subject: [issue18744] pathological performance using tarfile
In-Reply-To: <1376544025.63.0.959353089302.issue18744@psf.upfronthosting.co.za>
Message-ID: <1376544966.8.0.877068960141.issue18744@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18744>
_______________________________________

From report at bugs.python.org  Thu Aug 15 09:12:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Aug 2013 07:12:23 +0000
Subject: [issue18744] pathological performance using tarfile
In-Reply-To: <1376544025.63.0.959353089302.issue18744@psf.upfronthosting.co.za>
Message-ID: <1376550743.52.0.253423076305.issue18744@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please provide a simple script which shows the problem?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18744>
_______________________________________

From report at bugs.python.org  Thu Aug 15 09:24:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Aug 2013 07:24:22 +0000
Subject: [issue17628] str==str: compare the first character before calling
	memcmp()
In-Reply-To: <1365024552.84.0.0461498193244.issue17628@psf.upfronthosting.co.za>
Message-ID: <1376551462.51.0.635502273586.issue17628@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps it worth manually inline unicode_eq() in these tight inner loops. Then we can move "PyUnicode_GET_LENGTH(a) * PyUnicode_KIND(a)" out of the loop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17628>
_______________________________________

From report at bugs.python.org  Thu Aug 15 09:32:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Aug 2013 07:32:17 +0000
Subject: [issue18743] References to non-existant "StringIO" module
In-Reply-To: <1376542911.78.0.658455842148.issue18743@psf.upfronthosting.co.za>
Message-ID: <1376551937.81.0.0892559762013.issue18743@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18743>
_______________________________________

From report at bugs.python.org  Thu Aug 15 09:45:47 2013
From: report at bugs.python.org (Michal Vyskocil)
Date: Thu, 15 Aug 2013 07:45:47 +0000
Subject: [issue18682] [PATCH] remove bogus codepath from pprint._safe_repr
In-Reply-To: <1375950566.41.0.226660086473.issue18682@psf.upfronthosting.co.za>
Message-ID: <1376552747.33.0.370804363533.issue18682@psf.upfronthosting.co.za>


Michal Vyskocil added the comment:

The fast scalars approach looks great!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18682>
_______________________________________

From report at bugs.python.org  Thu Aug 15 09:59:00 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 15 Aug 2013 07:59:00 +0000
Subject: [issue18745] Test enum in test_json is ignorant of infinity value
Message-ID: <1376553540.47.0.197538167938.issue18745@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Test enum json in Lib/test/test_json/test_enum.py is ignorant of infinity values. Also, NaN, but since NaN is a weirdo, let's not take that into account.

The unit test should represent of what will work in every case. For example:

    def test_floats(self):
         for enum in FloatNum:
            self.assertEqual(self.dumps(enum), repr(enum.value))

This will fail if enum is infinity.

This wisdom about infinity was bestowed upon me when I was reading Lib/test/test_json/test_float.py.

    def test_floats(self):
        for num in [1617161771.7650001, math.pi, math.pi**100, math.pi**-100, 3.1]:
            self.assertEqual(float(self.dumps(num)), num)
            self.assertEqual(self.loads(self.dumps(num)), num)

    def test_ints(self):
        for num in [1, 1<<32, 1<<64]:
            self.assertEqual(self.dumps(num), str(num))
            self.assertEqual(int(self.dumps(num)), num)

As you can see, in float case, we don't use str(num) because it does not work with infinity.

Attached the patch to refactor the test to handle infinity value. For the completeness sake, I added the case of negative infinity and NaN as well.

----------
components: Tests
files: add_infinity_to_test_enum_in_json.patch
keywords: patch
messages: 195238
nosy: ethan.furman, vajrasky
priority: normal
severity: normal
status: open
title: Test enum in test_json is ignorant of infinity value
versions: Python 3.4
Added file: http://bugs.python.org/file31298/add_infinity_to_test_enum_in_json.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18745>
_______________________________________

From report at bugs.python.org  Thu Aug 15 11:18:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 09:18:43 +0000
Subject: [issue16463] testConnectTimeout of test_timeout
	TCPTimeoutTestCasefailures fails intermittently
In-Reply-To: <1352757217.25.0.912881014186.issue16463@psf.upfronthosting.co.za>
Message-ID: <1376558323.43.0.486002985259.issue16463@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Or we can wrap the resolve_address() method with the @functools.lru_cache() decorator.

Sounds ok to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16463>
_______________________________________

From report at bugs.python.org  Thu Aug 15 11:22:11 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Aug 2013 09:22:11 +0000
Subject: [issue17628] str==str: compare the first character before calling
	memcmp()
In-Reply-To: <1365024552.84.0.0461498193244.issue17628@psf.upfronthosting.co.za>
Message-ID: <1376558531.72.0.562797703026.issue17628@psf.upfronthosting.co.za>


STINNER Victor added the comment:

In issue #18719, Raymond modified Python 2.7, but he didn't touch the following macro:

#define Py_UNICODE_MATCH(string, offset, substring) \
    ((*((string)->str + (offset)) == *((substring)->str)) && \
    ((*((string)->str + (offset) + (substring)->length-1) == *((substring)->str + (substring)->length-1))) && \
     !memcmp((string)->str + (offset), (substring)->str, (substring)->length*sizeof(Py_UNICODE)))

It was said that looking for the last character before calling memcmp() is inefficient for the CPU cache. This macro should also be modified.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17628>
_______________________________________

From report at bugs.python.org  Thu Aug 15 11:28:36 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Aug 2013 09:28:36 +0000
Subject: [issue17628] str==str: compare the first character before calling
	memcmp()
In-Reply-To: <1365024552.84.0.0461498193244.issue17628@psf.upfronthosting.co.za>
Message-ID: <1376558916.91.0.65280284181.issue17628@psf.upfronthosting.co.za>


Christian Heimes added the comment:

It's also bad for memory read performance if the string is rather long. The memory controller performs best when code reads memory sequential. The talk http://www.youtube.com/watch?v=MC1EKLQ2Wmg about mythbusting modern hardware sums it up real nice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17628>
_______________________________________

From report at bugs.python.org  Thu Aug 15 11:40:36 2013
From: report at bugs.python.org (koobs)
Date: Thu, 15 Aug 2013 09:40:36 +0000
Subject: [issue18296] test_os.test_trailers() is failing on AMD64 FreeBSD 9.0
	dtrace 3.x
In-Reply-To: <1372119942.09.0.162654139201.issue18296@psf.upfronthosting.co.za>
Message-ID: <1376559636.11.0.601263517047.issue18296@psf.upfronthosting.co.za>


koobs added the comment:

As per our IRC conversation, our 'koobs-freebsd10' bot also reproduces the failure and can be used to test the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18296>
_______________________________________

From report at bugs.python.org  Thu Aug 15 11:58:05 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Aug 2013 09:58:05 +0000
Subject: [issue18296] test_os.test_trailers() is failing on AMD64 FreeBSD 9.0
	dtrace 3.x
In-Reply-To: <1372119942.09.0.162654139201.issue18296@psf.upfronthosting.co.za>
Message-ID: <3cG34r16Cbz7Ljh@mail.python.org>


Roundup Robot added the comment:

New changeset 924d327da3af by Victor Stinner in branch '3.3':
Issue #18296: Try to fix TestSendfile.test_trailers() of test_os on FreeBSD
http://hg.python.org/cpython/rev/924d327da3af

New changeset 92039fb68483 by Victor Stinner in branch 'default':
(Merge 3.3) Issue #18296: Try to fix TestSendfile.test_trailers() of test_os on FreeBSD
http://hg.python.org/cpython/rev/92039fb68483

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18296>
_______________________________________

From report at bugs.python.org  Thu Aug 15 12:14:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Aug 2013 10:14:20 +0000
Subject: [issue18746] test_threading.test_finalize_with_trace() fails on
	FreeBSD buildbot
Message-ID: <1376561660.51.0.498019291184.issue18746@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The following test fails on FreeBSD buildbot:

    def test_finalize_with_trace(self):
        # Issue1733757
        # Avoid a deadlock when sys.settrace steps into threading._shutdown
        assert_python_ok("-c", """if 1:
            import sys, threading

            # A deadlock-killer, to prevent the
            # testsuite to hang forever
            def killer():
                import os, time
                time.sleep(2)
                print('program blocked; aborting')
                os._exit(2)
            t = threading.Thread(target=killer)
            t.daemon = True
            t.start()

            # This is the trace function
            def func(frame, event, arg):
                threading.current_thread()
                return func

            sys.settrace(func)
            """)

I ran it manually on my FreeBSD 9.1 VM, I get the following error. I don't know if it's the same error than the buildbot.
----
(...)
# clear builtins._
(...)
# restore sys.stderr
# cleanup __main__
# cleanup[1] _sysconfigdata
(...)
# cleanup[1] threading
Exception ignored in: <function WeakSet.__init__.<locals>._remove at 0x801b11058>
Traceback (most recent call last):
  File "/usr/home/haypo/prog/python/default/Lib/_weakrefset.py", line 38, in _remove
  File "x.py", line 17, in func
AttributeError: 'NoneType' object has no attribute 'current_thread'
# cleanup[1] _weakrefset
(...)
# cleanup[3] _codecs
PyThreadState_Clear: warning: thread still has a frame
----

The weakref is probably threading._dangling.

IMO Py_Finalize() should first clear the trace function. Tracing Python exception while Python is dying (exiting) is insane. I'm surprised that it works :-)

----------
messages: 195244
nosy: haypo, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: test_threading.test_finalize_with_trace() fails on FreeBSD buildbot
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18746>
_______________________________________

From report at bugs.python.org  Thu Aug 15 12:14:24 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Aug 2013 10:14:24 +0000
Subject: [issue18746] test_threading.test_finalize_with_trace() fails on
	FreeBSD buildbot
In-Reply-To: <1376561660.51.0.498019291184.issue18746@psf.upfronthosting.co.za>
Message-ID: <1376561664.48.0.730877260305.issue18746@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18746>
_______________________________________

From report at bugs.python.org  Thu Aug 15 12:17:34 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Aug 2013 10:17:34 +0000
Subject: [issue18746] test_threading.test_finalize_with_trace() fails on
	FreeBSD buildbot
In-Reply-To: <1376561660.51.0.498019291184.issue18746@psf.upfronthosting.co.za>
Message-ID: <1376561854.43.0.848482909718.issue18746@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31299/finalize_clear_trace.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18746>
_______________________________________

From report at bugs.python.org  Thu Aug 15 12:23:17 2013
From: report at bugs.python.org (Peter Otten)
Date: Thu, 15 Aug 2013 10:23:17 +0000
Subject: [issue18219] csv.DictWriter is slow when writing files with large
	number of columns
In-Reply-To: <1371273159.09.0.766674685212.issue18219@psf.upfronthosting.co.za>
Message-ID: <1376562197.39.0.404127077864.issue18219@psf.upfronthosting.co.za>


Peter Otten added the comment:

Note that set operations on dict views work with lists, too. So the only change necessary is to replace

wrong_fields = [k for k in rowdict if k not in self.fieldnames]

with

wrong_fields = rowdict.keys() - self.filenames

(A backport to 2.7 would need to replace keys() with viewkeys())

----------
nosy: +peter.otten

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18219>
_______________________________________

From report at bugs.python.org  Thu Aug 15 13:24:15 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Aug 2013 11:24:15 +0000
Subject: [issue18739] math.log of a long returns a different value of math.log
	of an int
In-Reply-To: <1376492687.31.0.627121997874.issue18739@psf.upfronthosting.co.za>
Message-ID: <1376565855.25.0.696481360125.issue18739@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Ah, Tim saw through my cunningly-laid false trail of incorrect issue numbers.  Step 1 of my world domination plan is foiled!

Yes, let's fix this.  In my mind, it's definitely a bug that ints and longs aren't interchangeable here, and it would be nice to have 2.7 and 3.x behaving the same way.  I do have some worries about the fix breaking / changing existing code, but given that it'll only affect log of a long, those worries barely register.

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18739>
_______________________________________

From report at bugs.python.org  Thu Aug 15 14:03:20 2013
From: report at bugs.python.org (Julian Berman)
Date: Thu, 15 Aug 2013 12:03:20 +0000
Subject: [issue18335] Add textwrap.dedent, .indent, as str methods.
In-Reply-To: <1372656829.33.0.351971247179.issue18335@psf.upfronthosting.co.za>
Message-ID: <1376568200.11.0.548034198786.issue18335@psf.upfronthosting.co.za>


Changes by Julian Berman <Julian+Python.org at GrayVines.com>:


----------
nosy: +Julian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18335>
_______________________________________

From report at bugs.python.org  Thu Aug 15 14:35:01 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Aug 2013 12:35:01 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
Message-ID: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>


New submission from Christian Heimes:

A couple of reports and check-in messages like

  Postgres / pgcrypto CVE-2013-1900
  http://bugs.ruby-lang.org/issues/4579
  http://www.exim.org/lurker/message/20130402.171710.92f14a60.fi.html

suggests that OpenSSL's PRNG should be reset or re-seeded after fork(). Otherwise child processes can generate the same or similar pseudo random values.

Python doesn't have an API to run code before and after fork yet. The patch uses pthread_atfork() for the task. It's available on all pthread platforms -- which are all official supported platforms that have fork(), too.

The patch doesn't use RAND_cleanup() like Postgres because child process would hav to initial the PRNG again by opening and reading from /dev/urandom. The atfork prepare hook pulls from random bytes from the PRNG and stores them in a static buffer. The child handler seeds the PRNG from that buffer + pid + current time. PID and current time are mixed into the state to extenuate race conditions.

----------
components: Extension Modules
files: openssl_prng_atfork.patch
keywords: patch
messages: 195247
nosy: christian.heimes, haypo
priority: normal
severity: normal
stage: patch review
status: open
title: Re-seed OpenSSL's PRNG after fork
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31300/openssl_prng_atfork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 15 14:38:03 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 12:38:03 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1376570283.53.0.610098221959.issue18747@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Are there any uses of the OpenSSL PRNG from Python?
Is the PRNG used for SSL session keys, or another mechanism?

----------
nosy: +pitrou, sbt
type: security -> enhancement
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 15 14:40:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 12:40:24 +0000
Subject: [issue18335] Add textwrap.dedent, .indent, as str methods.
In-Reply-To: <1372656829.33.0.351971247179.issue18335@psf.upfronthosting.co.za>
Message-ID: <1376570424.1.0.19289690801.issue18335@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18335>
_______________________________________

From report at bugs.python.org  Thu Aug 15 14:43:44 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 12:43:44 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1376570624.89.0.783920928242.issue18747@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 15 14:44:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 12:44:16 +0000
Subject: [issue16500] Add an 'atfork' module
In-Reply-To: <1353252005.31.0.454056781872.issue16500@psf.upfronthosting.co.za>
Message-ID: <1376570656.38.0.532497398426.issue16500@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16500>
_______________________________________

From report at bugs.python.org  Thu Aug 15 14:46:30 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Aug 2013 12:46:30 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1376570790.44.0.281491407661.issue18747@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The ssl module exposes OpenSSL's PRNG and advertises the API as secure CPRNG: http://docs.python.org/3/library/ssl.html#random-generation

OpenSSL uses its own PRNG to create (amongst others) session keys for SSL connections.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 15 14:50:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 12:50:23 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570790.44.0.281491407661.issue18747@psf.upfronthosting.co.za>
Message-ID: <1376571015.2755.3.camel@fsol>


Antoine Pitrou added the comment:

> The ssl module exposes OpenSSL's PRNG and advertises the API as secure
> CPRNG: http://docs.python.org/3/library/ssl.html#random-generation

AFAICT, Python's PRNG isn't reset after fork, so I don't think OpenSSL's
should be reset.
OTOH, multiprocessing does reseed the random module after fork, so it
should also do so for the ssl module if already loaded.

We may add a note in the ssl docs stating that it's better to reseed
after fork().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 15 14:50:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 12:50:28 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1376571028.21.0.450527593783.issue8713@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Using the custom builders, it seems to happen randomly in test_rlock:

test_rlock (test.test_multiprocessing_spawn.WithManagerTestLock) ... Assertion failed: !collecting, file ..\Modules\gcmodule.c, line 1617
ok

http://buildbot.python.org/all/builders/AMD64%20Windows%20Server%202008%20%5BSB%5D%20custom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Thu Aug 15 14:58:31 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Aug 2013 12:58:31 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1376571511.01.0.556748779882.issue18747@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Python doesn't have a builtin PRNG. We use the OS's CPRNG such as /dev/urandom or CryptGenRandom(). Both use a system wide state and are not affected by process state. OpenSSL's PRNG is different because it uses an internal state. AFAIK it only polls the system's entropy poll when the PRNG is used for the first time.

It's not only multiprocessing. What about forking webservers etc. that use HTTPS?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 15 15:10:42 2013
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Thu, 15 Aug 2013 13:10:42 +0000
Subject: [issue18748] libgcc_s.so.1 must be installed for pthread_cancel to
	work
Message-ID: <1376572242.37.0.931026549367.issue18748@psf.upfronthosting.co.za>


New submission from Maries Ionel Cristian:

Running the file couple of times will make the interpreter fail with: libgcc_s.so.1 must be installed for pthread_cancel to work

>From what I've seen it is triggered from PyThread_delete_key (tries to load libgcc_s.so at that time).

How does it happen?

The main thread will close fd 4 (because fh object is getting dereferenced to 0) exactly at the same time libpthread will try to open and read libgcc_s.so with the same descriptor (4)

It's fairly obvious that the file handling in bug.py is a bug, but the interpreter should not crash like that !

This doesn't happen on python2.7. Also, python2.7 appears to be linked with libgcc_s.so.1 directly while the 3.x does not (I've tried 3.2 from ubuntu repos, and built 3.3 and 3.4 myself on ubuntu 12.04.2) - at least that's what ldd indicates.

----------
components: Build, Extension Modules
files: bug.py
messages: 195253
nosy: ionel.mc
priority: normal
severity: normal
status: open
title: libgcc_s.so.1 must be installed for pthread_cancel to work
type: crash
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31301/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18748>
_______________________________________

From report at bugs.python.org  Thu Aug 15 15:14:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 13:14:06 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1376572446.01.0.829855118908.issue18747@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Python doesn't have a builtin PRNG.

Of course it does. It's in the random module, and you can seed() it:

>>> random.seed(5)
>>> random.random()
0.6229016948897019
>>> random.random()
0.7417869892607294
>>> random.seed(5)
>>> random.random()
0.6229016948897019

See e.g. issue12856. And the multiprocessing module:
http://hg.python.org/cpython/file/92039fb68483/Lib/multiprocessing/forkserver.py#l195

> We use the OS's CPRNG such as /dev/urandom or CryptGenRandom().

"We"?

> It's not only multiprocessing. What about forking webservers etc.
> that use HTTPS?

Well, are they affected? I haven't understood your previous answer.
("OpenSSL uses its own PRNG to create (amongst others) session keys for SSL connections")

Note that it seems debatable whether it's an OpenSSL bug:
http://www.openwall.com/lists/oss-security/2013/04/12/3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 15 15:35:18 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Aug 2013 13:35:18 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376572446.01.0.829855118908.issue18747@psf.upfronthosting.co.za>
Message-ID: <520CD915.9090003@cheimes.de>


Christian Heimes added the comment:

Am 15.08.2013 15:14, schrieb Antoine Pitrou:
>> Python doesn't have a builtin PRNG.
> 
> Of course it does. It's in the random module, and you can seed() it:

Now you are nit-picking. Although random is a PRNG, it is not a CPRNG.
I'm clearly talking about the integrity of a CPRNG here.

>> We use the OS's CPRNG such as /dev/urandom or CryptGenRandom().
> 
> "We"?

Python's os.urandom() and _PyOS_URandom().

> Well, are they affected? I haven't understood your previous answer.
> ("OpenSSL uses its own PRNG to create (amongst others) session keys for SSL connections")

Yes, they are are affected. A forking HTTPS server does:

1) listen() on a TCP port
2) accept() new TCP connection
3) fork() a child process to handle request
4) do SSL handshake in the child process
5) read/write data in child process

When the OpenSSL's CPRNG is already initialized before 3) than all child
processes created by 3) will have almost the same PRNG state. According
to http://bugs.ruby-lang.org/issues/4579 the PRNG will return the same
value when PID numbers are recycled.

> Note that it seems debatable whether it's an OpenSSL bug:
> http://www.openwall.com/lists/oss-security/2013/04/12/3

It probably is an OpenSSL bug but the declaration doesn't help us. It's
not the first time Python has to work around OpenSSL, e.g. #18709.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 15 15:44:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 13:44:51 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <520CD915.9090003@cheimes.de>
Message-ID: <1376574283.2755.10.camel@fsol>


Antoine Pitrou added the comment:

> When the OpenSSL's CPRNG is already initialized before 3) than all child
> processes created by 3) will have almost the same PRNG state. According
> to http://bugs.ruby-lang.org/issues/4579 the PRNG will return the same
> value when PID numbers are recycled.

Thanks. Here is some discussion of the reseeding strategy:
http://marc.info/?l=openssl-dev&m=130432419329454&w=2

More precisely, instead of reseeding in the child, you can simply
perturb the PRNG with a constant in the parent, to make sure the same
PRNG state doesn't get re-used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 15 16:24:39 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 15 Aug 2013 14:24:39 +0000
Subject: [issue18749] [issue 18606] Re: Add statistics module to standard
	library
In-Reply-To: <20130815125837.25707.49680@psf.upfronthosting.co.za>
Message-ID: <520CE48B.5000809@pearwood.info>


New submission from Steven D'Aprano:

I hope I'm doing the right thing by replying in-line. This is my first code review, please let me know if I'm doing something wrong.

By the way, the email hasn't gone to the tracker again. Is that a bug in the tracker? I've taken the liberty of changing the address to report at bugs.python.org.

On 15/08/13 22:58, ezio.melotti at gmail.com wrote:
>
> http://bugs.python.org/review/18606/diff/8927/Lib/statistics.py
> File Lib/statistics.py (right):
>
> http://bugs.python.org/review/18606/diff/8927/Lib/statistics.py#newcode113
> Lib/statistics.py:113: __date__ = "2013-08-13"
> Are these still needed after inclusion?

Probably not. Also the licence will need to be changed.

> http://bugs.python.org/review/18606/diff/8927/Lib/statistics.py#newcode194
> Lib/statistics.py:194: """
> This would be good in the rst docs, but IMHO docstrings should be less
> verbose.
> If you end up copy/pasting all these in the rst file, you will duplicate
> all the docs and they will risk to get out of sync (in addition to have
> to update both every time).

Personally, I like having detailed docs in the docstring, at my fingers in the interactive interpreter. But I'll follow the consensus here.

> http://bugs.python.org/review/18606/diff/8927/Lib/statistics.py#newcode277
> Lib/statistics.py:277: assert isinstance(x, float) and
> isinstance(partials, list)
> Is this a good idea?

I think so :-) add_partials is internal/private, and so I don't have to worry about the caller providing wrong arguments, say a non-float. But I want some testing to detect coding errors. Using assert for this sort of internal pre-condition is exactly what assert is designed for.

> http://bugs.python.org/review/18606/diff/8927/Lib/statistics.py#newcode524
> Lib/statistics.py:524: """mode(data [, max_modes]) -> mode(s)
> The form "mode(data, max_modes=1) -> mode(s)" is preferred.

Is it? I see plenty of examples in the standard library of that form, e.g. str.find:

find(...)
     S.find(sub [,start [,end]]) -> int

> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics.py
> File Lib/test/test_statistics.py (right):
>
> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics.py#newcode46
> Lib/test/test_statistics.py:46: 'missing name "%s" in __all__' % name)
> FWIW This should be already covered by test___all__.

Sorry, I don't understand this. test__all__?

[...]
> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics.py#newcode144
> Lib/test/test_statistics.py:144: assert data != sorted(data)
> Why not assertNotEqual?
>
> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics.py#newcode385
> Lib/test/test_statistics.py:385: assert x == inf
> Why not assertEqual?

In general, I use bare asserts for testing code logic, even if the code is test code. So if I use self.assertSpam(...) then I'm performing a unit test of the module being tested. If I use a bare assert, I'm asserting something about the test logic itself.

> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics.py#newcode417
> Lib/test/test_statistics.py:417: self.assertTrue(math.isnan(sum(data)))
> Since you seem to use this quite often, it might be better to define a
> assertIsNaN (and possibly assertIsNotNaN) in NumericTestCase and provide
> a better error message in case of failure.
> The same could apply for assertIsInf.
>
> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics.py#newcode913
> Lib/test/test_statistics.py:913: self.assertTrue(isinstance(result,
> Decimal))
> assertIsInstance

I used to be able to remember all the unittest assert* methods... there are so many now, 31 not including deprecated aliases.

> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py
> File Lib/test/test_statistics_approx.py (right):
>
> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py#newcode1
> Lib/test/test_statistics_approx.py:1: """Numeric approximated equal
> comparisons and unit testing.
> Do I understand correctly that this is just an helper module used in
> test_statistics and that it doesn't actually test anything from the
> statistics module?

Correct. It does, however, test itself.

> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py#newcode137
> Lib/test/test_statistics_approx.py:137: # and avoid using
> TestCase.almost_equal, because it sucks :-)
> Could you elaborate on this?

Ah, I misspelled "TestCase.AlmostEqual".

- Using round() to test for equal-to-some-tolerance is quite an idiosyncratic way of doing approx-equality tests. I've never seen anyone do it that way before. It surprises me.

- It's easy to think that ``places`` means significant figures, not decimal places.

- There's now a delta argument (when was that added?) that is the same as my absolute error tolerance ``tol``, but no relative error argument.

- You can't set a  per-instance error tolerance.

> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py#newcode241
> Lib/test/test_statistics_approx.py:241: assert len(args1) == len(args2)
> Why not assertEqual?

As above, I use bare asserts to test the test logic, and assertSpam methods to perform the test. In this case, I'm confirming that I haven't created dodgy test data.

> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py#newcode255
> Lib/test/test_statistics_approx.py:255: self.assertTrue(approx_equal(b,
> a, tol=0, rel=rel))
> Why not assertApproxEqual?

Because I'm testing the approx_equal function. I can't use assertApproxEqual to test its own internals :-)

----------
messages: 195257
nosy: stevenjd
priority: normal
severity: normal
status: open
title: [issue 18606] Re: Add statistics module to standard library

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18749>
_______________________________________

From report at bugs.python.org  Thu Aug 15 16:45:38 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Aug 2013 14:45:38 +0000
Subject: [issue18749] [issue 18606] Re: Add statistics module to standard
	library
In-Reply-To: <520CE48B.5000809@pearwood.info>
Message-ID: <1376577938.19.0.562272944193.issue18749@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I hope I'm doing the right thing by replying in-line. This is my
> first code review, please let me know if I'm doing something wrong.
>
> By the way, the email hasn't gone to the tracker again. Is that a
> bug in the tracker? I've taken the liberty of changing the address
> to report at bugs.python.org.

Apparently that doesn't work, since it created a new issue :)

The best way is to reply directly on http://bugs.python.org/review/18606/.  You can either reply to the individual comments (better), or to the whole message like you did here.  I don't know if there's a way to reply via email.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18749>
_______________________________________

From report at bugs.python.org  Thu Aug 15 17:28:32 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Aug 2013 15:28:32 +0000
Subject: [issue18742] Abstract base class for hashlib
In-Reply-To: <1376519472.63.0.753349393836.issue18742@psf.upfronthosting.co.za>
Message-ID: <1376580512.42.0.407180218633.issue18742@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Updated patch.

I'm going to add documentation when everybody is happy with the patch.

----------
nosy: +pitrou
Added file: http://bugs.python.org/file31302/hashlib_abc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18742>
_______________________________________

From report at bugs.python.org  Thu Aug 15 18:15:16 2013
From: report at bugs.python.org (Ben North)
Date: Thu, 15 Aug 2013 16:15:16 +0000
Subject: [issue18533] Avoid error from repr() of recursive dictview
In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za>
Message-ID: <1376583316.06.0.762199518257.issue18533@psf.upfronthosting.co.za>


Ben North added the comment:

Is anything further needed from me before this can be reviewed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18533>
_______________________________________

From report at bugs.python.org  Thu Aug 15 18:33:22 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Aug 2013 16:33:22 +0000
Subject: [issue18532] hashlib.HASH objects should officially expose the hash
	name
In-Reply-To: <1374524940.42.0.582552143445.issue18532@psf.upfronthosting.co.za>
Message-ID: <1376584402.96.0.365836383567.issue18532@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The builtin hash algorithms still had upper case names. I fixed it in 
revision http://hg.python.org/cpython/rev/9a4949f5d15c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18532>
_______________________________________

From report at bugs.python.org  Thu Aug 15 18:33:29 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Aug 2013 16:33:29 +0000
Subject: [issue18532] hashlib.HASH objects should officially expose the hash
	name
In-Reply-To: <1374524940.42.0.582552143445.issue18532@psf.upfronthosting.co.za>
Message-ID: <1376584408.99.0.243656514595.issue18532@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18532>
_______________________________________

From report at bugs.python.org  Thu Aug 15 18:42:47 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Aug 2013 16:42:47 +0000
Subject: [issue18533] Avoid error from repr() of recursive dictview
In-Reply-To: <1374531750.42.0.70756948567.issue18533@psf.upfronthosting.co.za>
Message-ID: <1376584967.85.0.84188565609.issue18533@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Please visit
http://www.python.org/psf/contrib/
http://www.python.org/psf/contrib/contrib-form/
and submit a Contributor Agreement. This process is complete when '*' appears after your name here, as with mine and others.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18533>
_______________________________________

From report at bugs.python.org  Thu Aug 15 19:08:05 2013
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 15 Aug 2013 17:08:05 +0000
Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.4
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1376586485.0.0.48686556419.issue13248@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Thu Aug 15 19:10:56 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 15 Aug 2013 17:10:56 +0000
Subject: [issue18750] ''' % [1] doens't fail
Message-ID: <1376586656.31.0.488715338617.issue18750@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

I think this is a bug.
Can be reproduced on all Pythons (from 2.6 to 3.4a).
Maybe should be fixed for 3.4 only as backward incompatible change.

----------
messages: 195263
nosy: asvetlov
priority: normal
severity: normal
status: open
title: ''' % [1] doens't fail

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18750>
_______________________________________

From report at bugs.python.org  Thu Aug 15 19:35:25 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 15 Aug 2013 17:35:25 +0000
Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.4
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <1376588125.9.0.151465952326.issue13248@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13248>
_______________________________________

From report at bugs.python.org  Thu Aug 15 19:44:04 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Aug 2013 17:44:04 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1376588644.68.0.0837275365085.issue18747@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue was already discussed in the atfork issue:
http://bugs.python.org/issue16500#msg179838

See also:
http://www.openwall.com/lists/oss-security/2013/04/12/3
"I believe it is wrong to fix this in PostgreSQL.  Rather, this is a
bug in the OpenSSL fork protection code.  It should either install a
fork hook, or reseed the PRNG from /dev/urandom if a PID change is
detected."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 15 19:45:46 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Aug 2013 17:45:46 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1376588746.0.0.835329790552.issue18747@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Another link:
http://article.gmane.org/gmane.comp.encryption.openssl.user/48480/match=does+child+process+still+need+reseeded+after+fork

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 15 20:07:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 18:07:00 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1376590020.37.0.824321404189.issue8713@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, I enabled faulthandler in the child process and I got the explanation:
http://buildbot.python.org/all/builders/AMD64%20Windows%20Server%202008%20%5BSB%5D%20custom/builds/5/steps/test/logs/stdio

multiprocessing's manager Server uses daemon threads... Daemon threads are not joined when the interpreter shuts down, they are simply "frozen" at some point. Unfortunately, it may happen that a deamon thread is "frozen" while it was doing a cyclic garbage collection, which later triggers the assert.

I'm gonna replace the assert by a plain "if", then.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Thu Aug 15 20:13:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 18:13:16 +0000
Subject: [issue18751] A manager's server never joins its threads
Message-ID: <1376590396.18.0.712968689777.issue18751@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The Server class in multiprocessing.managers creates daemon threads and never joins them. This is in contrast with e.g. the Pool class, which creates daemon threads but uses util.Finalize to join them.

(not joining daemon threads may have adverse effects such as resource leaks or otherwise unexpected glitches)

Issue spawned from http://bugs.python.org/issue8713#msg195178.

----------
components: Library (Lib)
messages: 195267
nosy: pitrou, sbt
priority: normal
severity: normal
status: open
title: A manager's server never joins its threads
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18751>
_______________________________________

From report at bugs.python.org  Thu Aug 15 20:14:13 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Aug 2013 18:14:13 +0000
Subject: [issue18750] ''' % [1] doens't fail
In-Reply-To: <1376586656.31.0.488715338617.issue18750@psf.upfronthosting.co.za>
Message-ID: <1376590453.42.0.339486041445.issue18750@psf.upfronthosting.co.za>


R. David Murray added the comment:

What is it that doesn't fail?  The expression in the title is the beginning of a triple quoted string with no closing triple quote.

If you mean '' % [1] not falling, it has been that way forever (well, python2.4 is as far back as I can test), so if it is deemed worth changing it certainly should not be backported.

I suspect it is some consequence of the C level similarities between lists and dicts, since '' % {<anything>} is supposed to not produce an error.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18750>
_______________________________________

From report at bugs.python.org  Thu Aug 15 20:18:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Aug 2013 18:18:01 +0000
Subject: [issue18750] '' % [1] doens't fail
In-Reply-To: <1376586656.31.0.488715338617.issue18750@psf.upfronthosting.co.za>
Message-ID: <1376590681.49.0.306870634329.issue18750@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I don't understand why str % list and str % dict behaves differently than str % int:

>>> 'abc' % [1]
'abc'
>>> 'abc' % ([1],)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: not all arguments converted during string formatting
>>> 'abc' % 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: not all arguments converted during string formatting
>>> 'abc' % {1:2}
'abc'
>>> 'abc' % ({1:2},)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: not all arguments converted during string formatting

----------
nosy: +haypo
title: ''' % [1] doens't fail -> '' % [1] doens't fail

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18750>
_______________________________________

From report at bugs.python.org  Thu Aug 15 20:27:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 18:27:24 +0000
Subject: [issue18727] test for writing dictionary rows to CSV
In-Reply-To: <1376409675.57.0.271656920796.issue18727@psf.upfronthosting.co.za>
Message-ID: <1376591244.28.0.221400325451.issue18727@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks. One more question: is there a reason you don't simply call getvalue() at the end (rather than seek(0) followed by several readline() calls)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18727>
_______________________________________

From report at bugs.python.org  Thu Aug 15 20:33:09 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Aug 2013 18:33:09 +0000
Subject: [issue18425] IDLE Unit test for IdleHistory.py
In-Reply-To: <1373493838.59.0.876568806243.issue18425@psf.upfronthosting.co.za>
Message-ID: <3cGGW82Yflz7Lks@mail.python.org>


Roundup Robot added the comment:

New changeset 0e9d41edb2e4 by Terry Jan Reedy in branch '2.7':
Issue #18425: Unittests for idlelib.IdleHistory. First patch by R. Jayakrishnan.
http://hg.python.org/cpython/rev/0e9d41edb2e4

New changeset c4cac5d73e9d by Terry Jan Reedy in branch '3.3':
Issue #18425: Unittests for idlelib.IdleHistory. First patch by R. Jayakrishnan.
http://hg.python.org/cpython/rev/c4cac5d73e9d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18425>
_______________________________________

From report at bugs.python.org  Thu Aug 15 20:34:53 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Aug 2013 18:34:53 +0000
Subject: [issue18750] '' % [1] doens't fail
In-Reply-To: <1376586656.31.0.488715338617.issue18750@psf.upfronthosting.co.za>
Message-ID: <1376591693.26.0.317540742787.issue18750@psf.upfronthosting.co.za>


R. David Murray added the comment:

haypo: str % dict is a feature:

  >>> "%(a)s" % {'a': 1, 'b': 2}
  '1'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18750>
_______________________________________

From report at bugs.python.org  Thu Aug 15 20:38:05 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 15 Aug 2013 18:38:05 +0000
Subject: [issue18750] '' % [1] doens't fail
In-Reply-To: <1376586656.31.0.488715338617.issue18750@psf.upfronthosting.co.za>
Message-ID: <1376591885.24.0.106616524464.issue18750@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

For dict it is correct from my perspective.
"" % {'a': 'b'}
tries to substitute format specs like "%(a)s" and does nothing if spec is not present.

But list case like
"" % [1]
confuse me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18750>
_______________________________________

From report at bugs.python.org  Thu Aug 15 20:38:24 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 15 Aug 2013 18:38:24 +0000
Subject: [issue18739] math.log of a long returns a different value of math.log
	of an int
In-Reply-To: <1376492687.31.0.627121997874.issue18739@psf.upfronthosting.co.za>
Message-ID: <1376591904.0.0.366893084428.issue18739@psf.upfronthosting.co.za>


Tim Peters added the comment:

+1 on fixing it in 2.7, for the reasons Mark gave.

Way back when I introduced the original scheme, log(a_long) raised an exception, and the `int` and `long` types had a much higher wall between them.  The original scheme changed an annoying failure into a "pretty good" approximation, and because int operations never returned a long back then the relatively rare code using longs forced their use.

In the meantime, you can change failing cases of log(some_long) to log(int(some_long)).  int(some_long) will convert to int if possible (avoiding this path in the log code), but return some_long unchanged otherwise.  In the old days, int(some_long) would fail if some_long was too big to fit in an int - that's different now too - and for the better :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18739>
_______________________________________

From report at bugs.python.org  Thu Aug 15 21:08:17 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Aug 2013 19:08:17 +0000
Subject: [issue18226] IDLE Unit test for FormatParagrah.py
In-Reply-To: <1371335636.99.0.534048602964.issue18226@psf.upfronthosting.co.za>
Message-ID: <3cGHHj0wPbzRhQ@mail.python.org>


Roundup Robot added the comment:

New changeset 47307e7c80e1 by Terry Jan Reedy in branch '2.7':
Issue #18226: Fix ImportError and subsequent TypeError in 2.7 backport.
http://hg.python.org/cpython/rev/47307e7c80e1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18226>
_______________________________________

From report at bugs.python.org  Thu Aug 15 21:11:33 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Aug 2013 19:11:33 +0000
Subject: [issue18425] IDLE Unit test for IdleHistory.py
In-Reply-To: <1373493838.59.0.876568806243.issue18425@psf.upfronthosting.co.za>
Message-ID: <1376593893.4.0.637979865269.issue18425@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
superseder:  -> IdleHistory.History: eliminate unused parameter; other cleanup.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18425>
_______________________________________

From report at bugs.python.org  Thu Aug 15 21:12:39 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Aug 2013 19:12:39 +0000
Subject: [issue18425] IDLE Unit test for IdleHistory.py
In-Reply-To: <1373493838.59.0.876568806243.issue18425@psf.upfronthosting.co.za>
Message-ID: <1376593959.84.0.825758015766.issue18425@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18425>
_______________________________________

From report at bugs.python.org  Thu Aug 15 21:15:19 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Aug 2013 19:15:19 +0000
Subject: [issue18226] IDLE Unit test for FormatParagrah.py
In-Reply-To: <1371335636.99.0.534048602964.issue18226@psf.upfronthosting.co.za>
Message-ID: <1376594119.45.0.951389886588.issue18226@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

test.regrtest is semi-useless, at least for idle, in 2.7 -- see commit message. First run single file directly or python -m test.test_idle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18226>
_______________________________________

From report at bugs.python.org  Thu Aug 15 21:22:13 2013
From: report at bugs.python.org (K Richard Pixley)
Date: Thu, 15 Aug 2013 19:22:13 +0000
Subject: [issue18744] pathological performance using tarfile
In-Reply-To: <1376544025.63.0.959353089302.issue18744@psf.upfronthosting.co.za>
Message-ID: <1376594533.71.0.998895625733.issue18744@psf.upfronthosting.co.za>


K Richard Pixley added the comment:

New info...

I see the degradation on most of the linux boxes I've tried:
* ubuntu-13.04, (raring), 64-bit
* rhel-5.4 64-bit
* rhel-5.7 64-bit
* suse-11 64-bit

I see some degradation on MacOsX-10.8.4 but it's in the acceptable range, more like 2x than 60x.  That is still suspicious, but not as problematic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18744>
_______________________________________

From report at bugs.python.org  Thu Aug 15 21:23:13 2013
From: report at bugs.python.org (K Richard Pixley)
Date: Thu, 15 Aug 2013 19:23:13 +0000
Subject: [issue18744] pathological performance using tarfile
In-Reply-To: <1376544025.63.0.959353089302.issue18744@psf.upfronthosting.co.za>
Message-ID: <1376594593.45.0.544038872864.issue18744@psf.upfronthosting.co.za>


K Richard Pixley added the comment:

Here's a script that tests for the problem.

----------
Added file: http://bugs.python.org/file31303/tarproblem.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18744>
_______________________________________

From report at bugs.python.org  Thu Aug 15 21:44:50 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Aug 2013 19:44:50 +0000
Subject: [issue16190] Misleading warning in random module docs
In-Reply-To: <1349885590.41.0.193272073786.issue16190@psf.upfronthosting.co.za>
Message-ID: <1376595890.92.0.10109229276.issue16190@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thomas H. Ptacek pointed me to a good explanation: http://security.stackexchange.com/a/3939

TL;DR: Just use /dev/urandom and be happy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16190>
_______________________________________

From report at bugs.python.org  Thu Aug 15 21:47:47 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Aug 2013 19:47:47 +0000
Subject: [issue18739] math.log of a long returns a different value of math.log
	of an int
In-Reply-To: <1376492687.31.0.627121997874.issue18739@psf.upfronthosting.co.za>
Message-ID: <1376596067.22.0.514012550953.issue18739@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Here's a patch that simply backports the Python 3.x code to Python 2.7.

----------
keywords: +patch
Added file: http://bugs.python.org/file31304/issue18739.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18739>
_______________________________________

From report at bugs.python.org  Thu Aug 15 21:47:55 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Aug 2013 19:47:55 +0000
Subject: [issue18739] math.log of a long returns a different value of math.log
	of an int
In-Reply-To: <1376492687.31.0.627121997874.issue18739@psf.upfronthosting.co.za>
Message-ID: <1376596075.39.0.643579625728.issue18739@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18739>
_______________________________________

From report at bugs.python.org  Thu Aug 15 21:48:00 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Aug 2013 19:48:00 +0000
Subject: [issue18750] '' % [1] doens't fail
In-Reply-To: <1376586656.31.0.488715338617.issue18750@psf.upfronthosting.co.za>
Message-ID: <1376596080.52.0.384320662365.issue18750@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, I suspect you are right that that is a bug...and a long standing one :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18750>
_______________________________________

From report at bugs.python.org  Thu Aug 15 22:19:55 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Aug 2013 20:19:55 +0000
Subject: [issue18732] IdleHistory.History: eliminate unused parameter;
	other cleanup.
In-Reply-To: <1376428831.4.0.308828193599.issue18732@psf.upfronthosting.co.za>
Message-ID: <3cGJtL2HXVz7Ljf@mail.python.org>


Roundup Robot added the comment:

New changeset 7339dcff171f by Terry Jan Reedy in branch '2.7':
Issue #18732: Remove unused* parameter output_sep from IdleHistory.History
http://hg.python.org/cpython/rev/7339dcff171f

New changeset 3105b78d3434 by Terry Jan Reedy in branch '3.3':
Issue #18732: Remove unused* parameter output_sep from IdleHistory.History
http://hg.python.org/cpython/rev/3105b78d3434

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18732>
_______________________________________

From report at bugs.python.org  Thu Aug 15 22:19:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 20:19:54 +0000
Subject: [issue13647] Python SSL stack doesn't securely validate certificate
	(as client)
In-Reply-To: <1324564490.24.0.352449270187.issue13647@psf.upfronthosting.co.za>
Message-ID: <1376597994.03.0.848466723206.issue13647@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm gonna close this entry, since there's no actual issue to fix in Python.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13647>
_______________________________________

From report at bugs.python.org  Thu Aug 15 22:21:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 20:21:22 +0000
Subject: [issue16190] Misleading warning in random module docs
In-Reply-To: <1349885590.41.0.193272073786.issue16190@psf.upfronthosting.co.za>
Message-ID: <1376598082.08.0.950137714234.issue16190@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Agreed with a re-wording.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16190>
_______________________________________

From report at bugs.python.org  Thu Aug 15 22:21:32 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Aug 2013 20:21:32 +0000
Subject: [issue18732] IdleHistory.History: eliminate unused parameter;
	other cleanup.
In-Reply-To: <1376428831.4.0.308828193599.issue18732@psf.upfronthosting.co.za>
Message-ID: <1376598092.6.0.997976367404.issue18732@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18732>
_______________________________________

From report at bugs.python.org  Thu Aug 15 22:25:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 20:25:57 +0000
Subject: [issue13146] Writing a pyc file is not atomic
In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za>
Message-ID: <1376598357.97.0.0847841116407.issue13146@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Barry, do you still want to keep this issue open?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13146>
_______________________________________

From report at bugs.python.org  Thu Aug 15 22:26:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 20:26:28 +0000
Subject: [issue17970] Mutlithread XML parsing cause segfault
In-Reply-To: <1368453158.92.0.142296100122.issue17970@psf.upfronthosting.co.za>
Message-ID: <1376598388.98.0.208840099355.issue17970@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17970>
_______________________________________

From report at bugs.python.org  Thu Aug 15 22:32:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 20:32:17 +0000
Subject: [issue6132] Implement the GIL with critical sections in Windows
In-Reply-To: <1243462195.91.0.81958628587.issue6132@psf.upfronthosting.co.za>
Message-ID: <1376598737.93.0.448180474636.issue6132@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm closing this as out-of-date (due to the new GIL in 3.2 and upwards).

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6132>
_______________________________________

From report at bugs.python.org  Thu Aug 15 22:53:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 20:53:29 +0000
Subject: [issue13477] tarfile module should have a command line
In-Reply-To: <1322190665.85.0.356467902383.issue13477@psf.upfronthosting.co.za>
Message-ID: <1376600009.61.0.0269840953512.issue13477@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Regenerated patch against latest default (fixing conflicts).

----------
nosy: +pitrou
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31305/tarcli.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13477>
_______________________________________

From report at bugs.python.org  Thu Aug 15 22:56:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 20:56:15 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle
	SSL	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1376600175.57.0.433293445696.issue10441@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I would like to reject this approach. I am still adding Christian to the CC list, in case he has something to say about it :)

----------
nosy: +christian.heimes
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Thu Aug 15 23:03:04 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Aug 2013 21:03:04 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle
	SSL	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1376600584.78.0.248070113743.issue10441@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I agree with Antoine. I'm not sure what is going to happen if you use a single SSLContext for unrelated services and different hosts -- not to mention SNI.

A while ago I tried a similar patch but I was stopped by the fact that OpenSSL doesn't provide an API to clone / copy a SSLContext object. Perhaps we have to introduce a factory that creates SSLContext object from a global configuration?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Thu Aug 15 23:05:59 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Aug 2013 21:05:59 +0000
Subject: [issue18752] Make chain.from_iterable an alias for a new
	chain_iterable.
Message-ID: <1376600759.44.0.81483548171.issue18752@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

It has become apparent from various discussions in recent months that chain.from_iterable is at least as useful as chain. In fact, I now think that 'chain' should have been what chain.from_iterable is, with current chain(a,b,c) done as chain((a,b,d)). But too late for that.

Based on today's pydev post* by Eric Smith, I propose that chain_iterable (or chain_from_iterable, but I think the 'from' is not needed) be added to itertools and listed in the index table and documented as a function in its own right. 

This would make the long discussion of how to properly document chain.from_iterable (#18301) moot, as the method could be simply mentioned as a (deprecated) alias of chain_iterable.

* "I think that [itertools.chain.from_iterable] was a mistake, too. As a
recent discussion showed, it's not exactly discoverable. The fact that
it's not mentioned in the list of functions at the top of the
documentation doesn't help. And "chain" is documented as a "module
function", and "chain.from_iterable" as a "classmethod" making it all
the more confusing.

I think itertools.combinations and itertools.combinations_with_replacement is the better example of related
functions that should be followed. Not nested, no special parameters
trying to differentiate them: just two different function names."

If this proposal is rejected, then chain.iterable should be added to the index table. That would make it more discoverable, but not less confusing.

----------
messages: 195290
nosy: eric.smith, rhettinger, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Make chain.from_iterable an alias for a new chain_iterable.
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18752>
_______________________________________

From report at bugs.python.org  Thu Aug 15 23:08:58 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Aug 2013 21:08:58 +0000
Subject: [issue18301] In itertools.chain.from_iterable() there is no cls
	argument
In-Reply-To: <1372186723.21.0.67533324157.issue18301@psf.upfronthosting.co.za>
Message-ID: <1376600938.79.0.959304898545.issue18301@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

My counter proposal #18752 is that chain.from_iterable become a deprecated alias for a new function, chain_iterable.  With '@classmethod' removed, the current Python equivalent would work for chain_iterable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18301>
_______________________________________

From report at bugs.python.org  Thu Aug 15 23:29:34 2013
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 15 Aug 2013 21:29:34 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376602174.71.0.191462324432.issue18738@psf.upfronthosting.co.za>


Ethan Furman added the comment:

+    def __format__(self, *args, **kwargs):
+        return self.__class__._member_type_.__format__(self.value, *args, **kwargs)
+

With this in the Enum class all members simply forward formatting to the mixed-in type, meaning that IntEnum behaves exactly like int for formatting purposes.  Another way of saying that is that the name attribute of an IntEnum member will only be used when the !r or !s codes are used.

If we are all good with that, then the question remaining is how should pure enums handle formatting?  Should they also go the value route, or should they go with the name?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Thu Aug 15 23:46:50 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 15 Aug 2013 21:46:50 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376603210.07.0.54860483499.issue18738@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

The whole point of IntEnum and replacing stdlib constants with it was friendly str & repr out of the box. This means that "just printing out" an enum member should have a nice string representation. And "just printing out" means:

print(member)
"%s" % member
"{}".format(member)

!s/!r are quite esoteric - IntEnum should behave in the nicest way possible out of the box.

Let's just rig IntEnum's __format__ to do the right thing and not worry about Enum itself. I hope that mixin-with-Enum cases are rare (and most are IntEnum anyway), and in such rare cases users are free to lift the implementation from IntEnum.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Thu Aug 15 23:55:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 21:55:58 +0000
Subject: [issue16105] Pass read only FD to signal.set_wakeup_fd
In-Reply-To: <1349125559.77.0.651840030069.issue16105@psf.upfronthosting.co.za>
Message-ID: <1376603757.99.0.556716449542.issue16105@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a cleaned up patch.
However, I'm wondering if raising an error is a good idea. The effect will be to get cryptic OSErrors at random execution points. Perhaps using PyErr_WriteUnraisable would be better?

----------
versions:  -Python 2.6, Python 2.7, Python 3.3
Added file: http://bugs.python.org/file31306/wakeup_fd_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16105>
_______________________________________

From report at bugs.python.org  Fri Aug 16 00:15:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 22:15:53 +0000
Subject: [issue18121] antigravity leaks subprocess.Popen object
In-Reply-To: <1370197134.34.0.214224244916.issue18121@psf.upfronthosting.co.za>
Message-ID: <1376604953.65.0.723608544748.issue18121@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Outdated by PEP 442.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18121>
_______________________________________

From report at bugs.python.org  Fri Aug 16 00:17:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 22:17:00 +0000
Subject: [issue17930] Search not needed in combinations_with_replacement
In-Reply-To: <1367962723.84.0.508821715816.issue17930@psf.upfronthosting.co.za>
Message-ID: <1376605020.54.0.940316296069.issue17930@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17930>
_______________________________________

From report at bugs.python.org  Fri Aug 16 00:20:03 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 15 Aug 2013 22:20:03 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376603210.07.0.54860483499.issue18738@psf.upfronthosting.co.za>
Message-ID: <520D540A.2020509@trueblade.com>


Eric V. Smith added the comment:

On 8/15/2013 5:46 PM, Eli Bendersky wrote:
> The whole point of IntEnum and replacing stdlib constants with it was friendly str & repr out of the box. This means that "just printing out" an enum member should have a nice string representation. And "just printing out" means:
> 
> print(member)
> "%s" % member
> "{}".format(member)

100% agreed.

> !s/!r are quite esoteric - IntEnum should behave in the nicest way possible out of the box.

Not only that, they're not part of the __format__ protocol, anyway.

> Let's just rig IntEnum's __format__ to do the right thing and not worry about Enum itself. I hope that mixin-with-Enum cases are rare (and most are IntEnum anyway), and in such rare cases users are free to lift the implementation from IntEnum.

Agreed.

And the next question is: what is "the right thing"? Does it always
appear to be a str? Or sometimes str and sometimes int? And how far
deviant from plain int can it be?

I think the answers should be:

- Formats as int if the length of the format spec is >= 1 and it ends in
one of "bdoxX" (the int presentation types).

- Possibly format as float if the format spec ends in "eEfFgGn%" (the
float presentation types), but the utility is doubtful. However, int
converts to float with these, so we may as well do the same.

- Otherwise formats as a str.

- This will break a small number of valid int format strings, but we
should just accept that potential breakage. This is something to
consider if we're replacing existing ints with IntEnums (which I'm not
generally in favor of, anyway).

- Live with the fact that we'll need to update this code if we add any
int (or float) presentation types.

I think we might want to consider the same thing for bool.__format__,
but that's another issue. Maybe int could grow a __format_derived_type__
method implements the above, and bool and IntEnum could set their
__format__ to be that. Which probably points out that the original
int.__format__ design is flawed (as Nick pointed out), but too late to
change it.

Or, thinking even more outside the box, maybe int.__format__ could
implement the above logic if it knows it's working on a derived class.
That would change bool as well as all other int-derived types, but leave
int itself alone. More breakage, but potentially more useful. But again,
we should open another issue if we want to pursue this approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Fri Aug 16 00:33:56 2013
From: report at bugs.python.org (Julien Phalip)
Date: Thu, 15 Aug 2013 22:33:56 +0000
Subject: [issue16611] multiple problems with Cookie.py
In-Reply-To: <1354654224.49.0.677339520856.issue16611@psf.upfronthosting.co.za>
Message-ID: <1376606036.57.0.0887673124648.issue16611@psf.upfronthosting.co.za>


Julien Phalip added the comment:

Updated the patch to use a tuple instead of a list for the cookie flags.

----------
Added file: http://bugs.python.org/file31307/cookies-httponly-secure-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16611>
_______________________________________

From report at bugs.python.org  Fri Aug 16 00:37:13 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 15 Aug 2013 22:37:13 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <520D540A.2020509@trueblade.com>
Message-ID: <CAF-Rda91fyRsJBJesMztKoDSURq63oX5iYf4twVbcyDb1yk4pQ@mail.gmail.com>


Eli Bendersky added the comment:

On Thu, Aug 15, 2013 at 3:20 PM, Eric V. Smith <report at bugs.python.org>wrote:

>
> Eric V. Smith added the comment:
>
> On 8/15/2013 5:46 PM, Eli Bendersky wrote:
> > The whole point of IntEnum and replacing stdlib constants with it was
> friendly str & repr out of the box. This means that "just printing out" an
> enum member should have a nice string representation. And "just printing
> out" means:
> >
> > print(member)
> > "%s" % member
> > "{}".format(member)
>
> 100% agreed.
>
> > !s/!r are quite esoteric - IntEnum should behave in the nicest way
> possible out of the box.
>
> Not only that, they're not part of the __format__ protocol, anyway.
>
> > Let's just rig IntEnum's __format__ to do the right thing and not worry
> about Enum itself. I hope that mixin-with-Enum cases are rare (and most are
> IntEnum anyway), and in such rare cases users are free to lift the
> implementation from IntEnum.
>
> Agreed.
>
> And the next question is: what is "the right thing"? Does it always
> appear to be a str? Or sometimes str and sometimes int? And how far
> deviant from plain int can it be?
>
> I think the answers should be:
>
> - Formats as int if the length of the format spec is >= 1 and it ends in
> one of "bdoxX" (the int presentation types).
>
> - Possibly format as float if the format spec ends in "eEfFgGn%" (the
> float presentation types), but the utility is doubtful. However, int
> converts to float with these, so we may as well do the same.
>
> - Otherwise formats as a str.
>
>
Sounds good to me. One of IntEnum's raison d'?tres is to be an integer with
a nice string representation. So it makes sense to make it show itself as a
string, unless expicitly asked for an int. Float-conversion *is* dubious,
but I agree that following int's lead here is harmless and least surprising.

Naturally, compatibility with % formatting is desired. '%s' is str, '%i' is
int().
*
*
*

*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Fri Aug 16 00:56:19 2013
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 15 Aug 2013 22:56:19 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <CAF-Rda91fyRsJBJesMztKoDSURq63oX5iYf4twVbcyDb1yk4pQ@mail.gmail.com>
Message-ID: <520D5C93.5080303@stoneleaf.us>


Ethan Furman added the comment:

> Eli Bendersky added the comment:
> Naturally, compatibility with % formatting is desired. '%s' is str, '%i' is
> int().

Can we solve that one on this issue, or do we need to make another?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Fri Aug 16 01:00:48 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 15 Aug 2013 23:00:48 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376607648.53.0.0106593605867.issue18738@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I guess there are merits to keeping it all in the same place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Fri Aug 16 01:00:55 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Aug 2013 23:00:55 +0000
Subject: [issue18742] Abstract base class for hashlib
In-Reply-To: <1376519472.63.0.753349393836.issue18742@psf.upfronthosting.co.za>
Message-ID: <1376607655.34.0.931906828695.issue18742@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


Removed file: http://bugs.python.org/file31295/hashlib_abc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18742>
_______________________________________

From report at bugs.python.org  Fri Aug 16 01:01:01 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Aug 2013 23:01:01 +0000
Subject: [issue18742] Abstract base class for hashlib
In-Reply-To: <1376519472.63.0.753349393836.issue18742@psf.upfronthosting.co.za>
Message-ID: <1376607661.55.0.132302943435.issue18742@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


Removed file: http://bugs.python.org/file31302/hashlib_abc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18742>
_______________________________________

From report at bugs.python.org  Fri Aug 16 01:01:18 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Aug 2013 23:01:18 +0000
Subject: [issue18742] Abstract base class for hashlib
In-Reply-To: <1376519472.63.0.753349393836.issue18742@psf.upfronthosting.co.za>
Message-ID: <1376607678.8.0.025024241355.issue18742@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Now with block_size

----------
Added file: http://bugs.python.org/file31308/hashlib_abc3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18742>
_______________________________________

From report at bugs.python.org  Fri Aug 16 01:09:24 2013
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 15 Aug 2013 23:09:24 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <520D540A.2020509@trueblade.com>
Message-ID: <520D5FA3.8000205@stoneleaf.us>


Ethan Furman added the comment:

> Eric V. Smith added the comment:
>
> I think the answers should be:
>
> - Formats as int if the length of the format spec is >= 1 and it ends in
> one of "bdoxX" (the int presentation types).

Hmmm.  How about defining the characters that will be supported for string interpretation, and if there are any other 
characters in format spec then go int (or whatever the mix-in type is)?  I'm thinking "<^>01234566789".  Anything else 
("+", all letter codes, etc.) gets the normal (host-type) treatment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Fri Aug 16 01:59:52 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 15 Aug 2013 23:59:52 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <520D5FA3.8000205@stoneleaf.us>
Message-ID: <520D6B70.5080500@trueblade.com>


Eric V. Smith added the comment:

On 8/15/2013 7:09 PM, Ethan Furman wrote:
> 
> Ethan Furman added the comment:
> 
>> Eric V. Smith added the comment:
>>
>> I think the answers should be:
>>
>> - Formats as int if the length of the format spec is >= 1 and it ends in
>> one of "bdoxX" (the int presentation types).
> 
> Hmmm.  How about defining the characters that will be supported for string interpretation, and if there are any other 
> characters in format spec then go int (or whatever the mix-in type is)?  I'm thinking "<^>01234566789".  Anything else 
> ("+", all letter codes, etc.) gets the normal (host-type) treatment.

Is the goal of this approach to implement __format__ in Enum instead of
IntEnum?

But you can't do this in general, because in the place you implement
__format__ you must understand the mix-in type's format strings.
Consider if the mix-in type is datetime: it's format strings don't end
in a the set of characters you list. So I think you have to implement
__format__ on each derived-from-Enum type so you can make the best
decisions there.

I think we want to have the most possible interpretations give a str
output, and only use the base type if that's explicitly asked for. As
Eli says, that's one of the main reasons IntEnum exists in the first
place. Hence my approach for IntEnum.__format__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Fri Aug 16 02:04:22 2013
From: report at bugs.python.org (Felipe Cruz)
Date: Fri, 16 Aug 2013 00:04:22 +0000
Subject: [issue16105] Pass read only FD to signal.set_wakeup_fd
In-Reply-To: <1349125559.77.0.651840030069.issue16105@psf.upfronthosting.co.za>
Message-ID: <1376611462.1.0.483947264148.issue16105@psf.upfronthosting.co.za>


Felipe Cruz added the comment:

Looks like PyErr_WriteUnraisable can be a better choice. Exceptions at random execution points looks a little bit dirty at least for this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16105>
_______________________________________

From report at bugs.python.org  Fri Aug 16 02:20:34 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 16 Aug 2013 00:20:34 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <520D6B70.5080500@trueblade.com>
Message-ID: <520D704D.2070808@stoneleaf.us>


Ethan Furman added the comment:

> Eric V. Smith added the comment:
>> Ethan Furman added the comment:
>>
>>> Hmmm.  How about defining the characters that will be supported for string interpretation, and if there are any other
>>> characters in format spec then go int (or whatever the mix-in type is)?  I'm thinking "<^>01234566789".  Anything else
>>> ("+", all letter codes, etc.) gets the normal (host-type) treatment.
>
> Is the goal of this approach to implement __format__ in Enum instead of
> IntEnum?

Yes.

> But you can't do this in general, because in the place you implement
> __format__ you must understand the mix-in type's format strings.

Which is why I suggest concentrating on what defines an "empty" format string.  In this case "empty" means what can we 
put in the format spec and still get string treatment.

> Consider if the mix-in type is datetime: it's format strings don't end
> in a the set of characters you list.

The characters I list are the justification chars and the digits that would be used to specify the field width.  If 
those are the only characters given then treat the MixedEnum member as the member string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Fri Aug 16 02:26:54 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Aug 2013 00:26:54 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <520D704D.2070808@stoneleaf.us>
Message-ID: <520D71C6.40409@trueblade.com>


Eric V. Smith added the comment:

On 8/15/2013 8:20 PM, Ethan Furman wrote:
> The characters I list are the justification chars and the digits that would be used to specify the field width.  If 
> those are the only characters given then treat the MixedEnum member as the member string.

But a datetime format string can end in "0", for example.

>>> format(datetime.datetime.now(), '%H:%M:%S.00')
'20:25:27.00'

I think your code would produce the equivalent of:
>>> format(str(datetime.datetime.now()), '%H:%M:%S.00')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid conversion specification

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Fri Aug 16 02:37:06 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Aug 2013 00:37:06 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
	subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376613426.83.0.782591995526.issue18709@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Brian Cameron from Oracle has requested a fix for Python 2.6. I have attached a patch for 2.6. In order to compile and test the patch I had to modify _ssl.c to handle OPENSSL_NO_SSL2. I also copied keycert.pem from 2.7 to fix two test failures. The former keycert.pem has expired.

It's a bit of a challenge to compile Python 2.6 on modern Linux OS. I had to set a couple of flags and overwrite MACHDEP:

export arch=$(dpkg-architecture -qDEB_HOST_MULTIARCH)
export LDFLAGS="-L/usr/lib/$arch -L/lib/$arch"
export CFLAGS="-I/usr/include/$arch"
export CPPFLAGS="-I/usr/include/$arch"
./configure --config-cache --with-pydebug
make -j4 MACHDEP=linux2

----------
Added file: http://bugs.python.org/file31309/CVE-2013-4073_py26.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Fri Aug 16 02:47:13 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 16 Aug 2013 00:47:13 +0000
Subject: [issue18742] Abstract base class for hashlib
In-Reply-To: <1376519472.63.0.753349393836.issue18742@psf.upfronthosting.co.za>
Message-ID: <1376614033.57.0.0888879157462.issue18742@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

your patch makes sense to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18742>
_______________________________________

From report at bugs.python.org  Fri Aug 16 06:04:02 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Aug 2013 04:04:02 +0000
Subject: [issue18750] '' % [1] doens't fail
In-Reply-To: <1376586656.31.0.488715338617.issue18750@psf.upfronthosting.co.za>
Message-ID: <1376625842.55.0.468693588955.issue18750@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Objects/unicodeobject.c has this, at line 14316:

    if (PyMapping_Check(args) && !PyTuple_Check(args) && !PyUnicode_Check(args))
        ctx.dict = args;
    else
        ctx.dict = NULL;

and later at line 14348:
    if (ctx.argidx < ctx.arglen && !ctx.dict) {
        PyErr_SetString(PyExc_TypeError,
                        "not all arguments converted during string formatting");
        goto onError;
    }

Because list now returns true for PyMapping_Check, this code thinks the list is a dict and skips the error.

There's some discussion of PyMapping_Check in issue 5945.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18750>
_______________________________________

From report at bugs.python.org  Fri Aug 16 06:04:56 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Aug 2013 04:04:56 +0000
Subject: [issue18750] '' % [1] doesn't fail
In-Reply-To: <1376586656.31.0.488715338617.issue18750@psf.upfronthosting.co.za>
Message-ID: <1376625896.76.0.852530506559.issue18750@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
title: '' % [1] doens't fail -> '' % [1] doesn't fail

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18750>
_______________________________________

From report at bugs.python.org  Fri Aug 16 06:24:20 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 16 Aug 2013 04:24:20 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <520D71C6.40409@trueblade.com>
Message-ID: <520DA974.4040006@stoneleaf.us>


Ethan Furman added the comment:

> Eric V. Smith added the comment:
>
> But a datetime format string can end in "0", for example.
>
>>>> format(datetime.datetime.now(), '%H:%M:%S.00')
> '20:25:27.00'

Not a problem, because once the digits were removed there would still be % : H M S and ., so the datetime format would 
be called.  str format would only be called when the result of removing < ^ > 0 1 2 3 4 5 6 7 8 9 was an empty string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Fri Aug 16 06:31:32 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Aug 2013 04:31:32 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <520DA974.4040006@stoneleaf.us>
Message-ID: <520DAB19.9000404@trueblade.com>


Eric V. Smith added the comment:

On 8/16/2013 12:24 AM, Ethan Furman wrote:
> 
> Ethan Furman added the comment:
> 
>> Eric V. Smith added the comment:
>>
>> But a datetime format string can end in "0", for example.
>>
>>>>> format(datetime.datetime.now(), '%H:%M:%S.00')
>> '20:25:27.00'
> 
> Not a problem, because once the digits were removed there would still be % : H M S and ., so the datetime format would 
> be called.  str format would only be called when the result of removing < ^ > 0 1 2 3 4 5 6 7 8 9 was an empty string.

Ah, I misread your earlier text. You'd want to remove 's' also, wouldn't
you?

You might be able to guess whether this particular format spec is a str
format spec or not, but it can't work in the general case, because not
all types with format specifiers have been written yet. I can imagine a
type with a format specification that's identical to str's (yet produces
different output), and you'd always want to use its __format__ instead
of str.__format__.

I feel strongly this is sufficiently magic that we shouldn't do it, and
instead just implement the more robust algorithm in IntEnum.__format__.
But I'm not going to argue it any more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Fri Aug 16 08:14:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 06:14:57 +0000
Subject: [issue18743] References to non-existant "StringIO" module
In-Reply-To: <1376542911.78.0.658455842148.issue18743@psf.upfronthosting.co.za>
Message-ID: <1376633697.25.0.393503502217.issue18743@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: docs at python -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18743>
_______________________________________

From report at bugs.python.org  Fri Aug 16 08:34:37 2013
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 16 Aug 2013 06:34:37 +0000
Subject: [issue14191] argparse doesn't allow optionals within positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1376634877.49.0.901461797021.issue14191@psf.upfronthosting.co.za>


Glenn Linderman added the comment:

Paul, is this ready to merge, or are you thinking of more refinements?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14191>
_______________________________________

From report at bugs.python.org  Fri Aug 16 09:26:55 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 16 Aug 2013 07:26:55 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376638015.36.0.234709516748.issue18738@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Eric, please do not feel your time has been wasted.  I greatly appreciate the knowledge you shared and I learned much.

I feel very strongly that, as much as possible, an Enum should Just Work.  Requiring users to write their own __format__ any time they create a new mixinEnum in order to get sane default behaviour is just not cool.

And while the behaviour of switching from str.__format__ to mixin.__format__ can appear a bit magical, it is nothing compared to Enum as a whole.

You can review the attached patch to see what I mean about filtering the format spec to decide which __format__ method to call.  Any code besides the basic width and justification codes will switch to the mix-in's __format__; so '+', 'b', '%Y', 's', and everything we haven't thought of yet will switch to mix-in.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file31310/issue18738.stoneleaf.01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Fri Aug 16 10:01:13 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 16 Aug 2013 08:01:13 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376640073.04.0.183055645446.issue18738@psf.upfronthosting.co.za>


Ethan Furman added the comment:

This patch contains the previous patch, plus a fix and tests for %i, %d, and %u formatting, and tests only for %f formatting (nothing to fix there, but don't want it breaking in the future ;) .

----------
Added file: http://bugs.python.org/file31311/issue18738.stoneleaf.02.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Fri Aug 16 10:31:04 2013
From: report at bugs.python.org (Kees Bos)
Date: Fri, 16 Aug 2013 08:31:04 +0000
Subject: [issue18753] [c]ElementTree.fromstring fails to parse
	<value>]]></value>
Message-ID: <1376641863.98.0.614514582932.issue18753@psf.upfronthosting.co.za>


New submission from Kees Bos:

ElementTree.fromstring and cElementTree.fromstring fail on parsing
"<value>]]></value>", but do parse "<value>]]&gt;</value>"

$ python
Python 2.7.3 (default, Apr 10 2013, 05:09:49) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree import cElementTree as ET
>>> ET.fromstring("<value>]]></value>").text
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 124, in XML
cElementTree.ParseError: not well-formed (invalid token): line 1, column 9
>>> ET.fromstring("<value>]]&gt;</value>").text
']]>'
>>> from xml.etree import ElementTree as ET
>>> ET.fromstring("<value>]]></value>").text
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1301, in XML
    parser.feed(text)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1643, in feed
    self._raiseerror(v)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1507, in _raiseerror
    raise err
xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 1, column 9
>>> ET.fromstring("<value>]]&gt;</value>").text
']]>'
>>>

----------
components: XML
messages: 195315
nosy: kees
priority: normal
severity: normal
status: open
title: [c]ElementTree.fromstring fails to parse <value>]]></value>
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18753>
_______________________________________

From report at bugs.python.org  Fri Aug 16 12:38:26 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 10:38:26 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376649506.42.0.215304549321.issue18720@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

I've just had a quick look at the patch, but from what I can see, socket.getaddrinfo() will return a raw integer for the family, and not an AddressFamily instance. That's unfortunate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Fri Aug 16 12:48:20 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 10:48:20 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <1376080127.3.0.151953760782.issue18643@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0pzM04sTvvqAMnQ5y4ot498G=Xw=W536es59ijsBySmg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

I was thinking about dropping the C wrapper from socketmodule.c, and
replacing it with a pure Python implementation (e.g. the one posted by
Richard on python-dev).
What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Fri Aug 16 13:53:39 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 11:53:39 +0000
Subject: [issue16463] testConnectTimeout of test_timeout
	TCPTimeoutTestCasefailures fails intermittently
In-Reply-To: <1376558323.43.0.486002985259.issue16463@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2UCXtdx5kCxjnQAJikYdX3sHggZZhkFouzy9b8UhWs+g@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Here's an updated patch using the lru_cache decorator.

----------
Added file: http://bugs.python.org/file31312/connect_timeout-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16463>
_______________________________________
-------------- next part --------------
diff -r 928d405fe2ad Lib/test/test_timeout.py
--- a/Lib/test/test_timeout.py	Sun Aug 04 15:35:57 2013 +0200
+++ b/Lib/test/test_timeout.py	Fri Aug 16 13:50:31 2013 +0200
@@ -1,5 +1,6 @@
 """Unit tests for socket timeout feature."""
 
+import functools
 import unittest
 from test import support
 
@@ -126,13 +127,24 @@
         self.assertLess(delta, timeout + self.fuzz)
         self.assertGreater(delta, timeout - 1.0)
 
+    @functools.lru_cache()
+    def resolve_address(self, host, port):
+        """Resolve an (host, port) to an address.
+
+        We must perform name resolution before timeout tests, otherwise it will
+        be performed by connect().
+        """
+        with support.transient_internet(host):
+            return socket.getaddrinfo(host, port, socket.AF_INET,
+                                      socket.SOCK_STREAM)[0][4]
+
 
 class TCPTimeoutTestCase(TimeoutTestCase):
     """TCP test case for socket.socket() timeout functions"""
 
     def setUp(self):
         self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-        self.addr_remote = ('www.python.org.', 80)
+        self.addr_remote = self.resolve_address('www.python.org.', 80)
 
     def tearDown(self):
         self.sock.close()
@@ -142,7 +154,7 @@
         # to a host that silently drops our packets.  We can't simulate this
         # from Python because it's a function of the underlying TCP/IP stack.
         # So, the following Snakebite host has been defined:
-        blackhole = ('blackhole.snakebite.net', 56666)
+        blackhole = self.resolve_address('blackhole.snakebite.net', 56666)
 
         # Blackhole has been configured to silently drop any incoming packets.
         # No RSTs (for TCP) or ICMP UNREACH (for UDP/ICMP) will be sent back
@@ -154,7 +166,7 @@
         # to firewalling or general network configuration.  In order to improve
         # our confidence in testing the blackhole, a corresponding 'whitehole'
         # has also been set up using one port higher:
-        whitehole = ('whitehole.snakebite.net', 56667)
+        whitehole = self.resolve_address('whitehole.snakebite.net', 56667)
 
         # This address has been configured to immediately drop any incoming
         # packets as well, but it does it respectfully with regards to the

From report at bugs.python.org  Fri Aug 16 14:32:07 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 12:32:07 +0000
Subject: [issue18748] libgcc_s.so.1 must be installed for pthread_cancel to
 work
In-Reply-To: <1376572242.37.0.931026549367.issue18748@psf.upfronthosting.co.za>
Message-ID: <1376656327.19.0.465292432443.issue18748@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Unfortunately, there's not much we can do about it: if dlsym() fails - which is the case here either because read() fails with EBADF, or because the file descriptor now points to another stream (i.e. not libgcc), the libc aborts (here upon pthread_exit(), not PyThread_delete_key()):
"""
libgcc_s.so.1 must be installed for pthread_cancel to work

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7b0eb70 (LWP 17152)]
0xb7fe1424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fe1424 in __kernel_vsyscall ()
#1  0xb7e4e941 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb7e51d72 in *__GI_abort () at abort.c:92
#3  0xb7e8ae15 in __libc_message (do_abort=1, fmt=0xb7f606f5 "%s") at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#4  0xb7e8af44 in *__GI___libc_fatal (message=0xb7fc75ec "libgcc_s.so.1 must be installed for pthread_cancel to work\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:200
#5  0xb7fc4ffa in pthread_cancel_init () at ../nptl/sysdeps/pthread/unwind-forcedunwind.c:65
#6  0xb7fc509d in _Unwind_ForcedUnwind (exc=0xb7b0edc0, stop=0xb7fc2bf0 <unwind_stop>, stop_argument=0xb7b0e454) at ../nptl/sysdeps/pthread/unwind-forcedunwind.c:126
#7  0xb7fc2b98 in *__GI___pthread_unwind (buf=<optimized out>) at unwind.c:130
#8  0xb7fbcce0 in __do_cancel () at pthreadP.h:265
#9  __pthread_exit (value=0x0) at pthread_exit.c:30
#10 0x08132ced in PyThread_exit_thread () at Python/thread_pthread.h:266
#11 0x08137c37 in t_bootstrap (boot_raw=0x8318aa8) at ./Modules/_threadmodule.c:1023
#12 0xb7fbbc39 in start_thread (arg=0xb7b0eb70) at pthread_create.c:304
#13 0xb7ef978e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
"""

So if you're unlucky and end up closing the FD referring to libgcc used by dlopen/dlsym, you're pretty much screwed, and there's no way around this.

Note that you specific problem (upon PyThread_delete_key()) doesn't occur for python 2.7 because it uses and ad-hoc TLS implementation, whereas Python 3 uses the platform native TLS.
But as noted above, you can very well get an abort on pthread_exit(), and in likely many other places (pretty much everywhere libgcc can be dlopen'ed).

Unfortunately, we can't do much against this, so I'm tempted to close this as "wont fix".

----------
nosy: +neologix
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18748>
_______________________________________

From report at bugs.python.org  Fri Aug 16 14:38:01 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Aug 2013 12:38:01 +0000
Subject: [issue18673] Add and use O_TMPFILE for Linux 3.11
In-Reply-To: <1375818220.16.0.883591943761.issue18673@psf.upfronthosting.co.za>
Message-ID: <3cGkZw2lLXzSZT@mail.python.org>


Roundup Robot added the comment:

New changeset f6034602410c by Christian Heimes in branch 'default':
Issue #18673: Add O_TMPFILE to os module. O_TMPFILE requires Linux kernel
http://hg.python.org/cpython/rev/f6034602410c

New changeset 815b7bb3b08d by Christian Heimes in branch 'default':
Issue #18673: Add versionchanged to docs
http://hg.python.org/cpython/rev/815b7bb3b08d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18673>
_______________________________________

From report at bugs.python.org  Fri Aug 16 14:53:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 12:53:23 +0000
Subject: [issue18748] libgcc_s.so.1 must be installed for pthread_cancel to
 work
In-Reply-To: <1376572242.37.0.931026549367.issue18748@psf.upfronthosting.co.za>
Message-ID: <1376657603.64.0.751497245252.issue18748@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Perhaps the only thing we could do would be try to "preload" libgcc by calling one of those APIs at startup? But I'm not sure it's a good idea to add such a platform-specific hack (for what is arguably an obscure and rare issue).

----------
nosy: +pitrou
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18748>
_______________________________________

From report at bugs.python.org  Fri Aug 16 14:56:28 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Aug 2013 12:56:28 +0000
Subject: [issue18673] Add O_TMPFILE to os module
In-Reply-To: <1375818220.16.0.883591943761.issue18673@psf.upfronthosting.co.za>
Message-ID: <1376657788.84.0.0487825104647.issue18673@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I have added O_TMPFILE to the os module.

I like to hold off with the actual use of O_TMPFILE in tempfile until Python 3.5. The feature is too new and I don't have any way to test it. Some people have reported file system corruption in 3.11-rc4, too.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
title: Add and use O_TMPFILE for Linux 3.11 -> Add O_TMPFILE to os module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18673>
_______________________________________

From report at bugs.python.org  Fri Aug 16 15:00:43 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Aug 2013 13:00:43 +0000
Subject: [issue18748] libgcc_s.so.1 must be installed for pthread_cancel to
 work
In-Reply-To: <1376572242.37.0.931026549367.issue18748@psf.upfronthosting.co.za>
Message-ID: <1376658043.03.0.402283850392.issue18748@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18748>
_______________________________________

From report at bugs.python.org  Fri Aug 16 15:03:14 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Aug 2013 13:03:14 +0000
Subject: [issue18368] PyOS_StdioReadline() leaks memory when realloc() fails
In-Reply-To: <1373054563.49.0.685653845765.issue18368@psf.upfronthosting.co.za>
Message-ID: <1376658194.51.0.477070263083.issue18368@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18368>
_______________________________________

From report at bugs.python.org  Fri Aug 16 15:10:03 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 13:10:03 +0000
Subject: [issue18740] str is number methods don't recognize '.'
In-Reply-To: <1376499343.4.0.632911217056.issue18740@psf.upfronthosting.co.za>
Message-ID: <1376658603.66.0.393326209655.issue18740@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> it seems try/except is still the best way.  :-/

Indeed: http://docs.python.org/dev/glossary#term-eafp

----------
nosy: +ezio.melotti
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18740>
_______________________________________

From report at bugs.python.org  Fri Aug 16 15:11:18 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Aug 2013 13:11:18 +0000
Subject: [issue18748] libgcc_s.so.1 must be installed for pthread_cancel to
 work
In-Reply-To: <1376572242.37.0.931026549367.issue18748@psf.upfronthosting.co.za>
Message-ID: <1376658678.46.0.641669212909.issue18748@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Maries Ionel Cristian> ubuntu 12.04.2

What is the version of your libc library? Try something like "dpkg -l libc6".

--

Could this issue be related to this glibc issue?
http://sourceware.org/bugzilla/show_bug.cgi?id=2644

I ran your script on Python 3.4 in a shell loop: I'm unable to reproduce the issue. I'm running Fedora 18 with the glibc 2.16.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18748>
_______________________________________

From report at bugs.python.org  Fri Aug 16 15:14:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Aug 2013 13:14:45 +0000
Subject: [issue18748] libgcc_s.so.1 must be installed for pthread_cancel to
 work
In-Reply-To: <1376572242.37.0.931026549367.issue18748@psf.upfronthosting.co.za>
Message-ID: <1376658885.67.0.291877728366.issue18748@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh ok, I'm able to reproduce the issue with the system Python 3.3:

$ while true; do echo "loop"; python3.3 bug.py || break; done
loop
...
loop
libgcc_s.so.1 must be installed for pthread_cancel to work
Abandon (core dumped)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18748>
_______________________________________

From report at bugs.python.org  Fri Aug 16 15:24:28 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Aug 2013 13:24:28 +0000
Subject: [issue18750] '' % [1] doesn't fail
In-Reply-To: <1376586656.31.0.488715338617.issue18750@psf.upfronthosting.co.za>
Message-ID: <1376659468.59.0.837822815286.issue18750@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  The linked issue says the PyMappingCheck behavior is new in Python3, but this problem exists in Python2 (back to 2.4 at least) as well.  Perhaps it is a different bug in Python2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18750>
_______________________________________

From report at bugs.python.org  Fri Aug 16 15:28:01 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Aug 2013 13:28:01 +0000
Subject: [issue18753] [c]ElementTree.fromstring fails to parse
 <value>]]></value>
In-Reply-To: <1376641863.98.0.614514582932.issue18753@psf.upfronthosting.co.za>
Message-ID: <1376659681.14.0.550420451222.issue18753@psf.upfronthosting.co.za>


R. David Murray added the comment:

Why do you think this is a bug?  (You may well be right; I'm not familiar with the intricacies of XML. But on its face the behavior looks reasonable.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18753>
_______________________________________

From report at bugs.python.org  Fri Aug 16 15:28:34 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 16 Aug 2013 13:28:34 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376659714.45.0.127474841484.issue18720@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Great catch, Charles-Fran?ois, thanks. It's actually an interesting example in favor of the approach - it's very nice to see descriptive family names in the data returned by getaddrinfo, instead of obtuse numeric values.

The attached patch fixes it in a similar vein to what was done for the family accessor: getaddrinfo is overridden in Python and does the necessary conversion. User code is unaffected. It has to rebuild the list (since those are tuples) but I don't think it matters in terms of performance for this specific function. As a bonus, getaddrinfo got a much nicer docstring :)

----

Note again that if this is acceptable, I'm going to similarly convert SOCK_* and post a full patch (with some documentation too).

----------
Added file: http://bugs.python.org/file31313/socket-intenum-af.4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Fri Aug 16 15:31:06 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 16 Aug 2013 13:31:06 +0000
Subject: [issue18750] '' % [1] doesn't fail
In-Reply-To: <1376586656.31.0.488715338617.issue18750@psf.upfronthosting.co.za>
Message-ID: <1376659866.21.0.160954772051.issue18750@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

The code looks basically the same in 2.7, and there PyMapping_Check looks for __getitem__, so maybe issue 5945 is just incorrect in its analysis.

In any event, I'm not sure this is worth fixing. There are lots of little corner cases that could be broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18750>
_______________________________________

From report at bugs.python.org  Fri Aug 16 15:36:35 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 16 Aug 2013 13:36:35 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376660195.9.0.760904911914.issue18720@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Looks nice:

>>> for t in socket.getaddrinfo('www.google.com', 'http'):
...   t
... 
(<AddressFamily.AF_INET: 2>, 1, 6, '', ('74.125.239.112', 80))
(<AddressFamily.AF_INET: 2>, 2, 17, '', ('74.125.239.112', 80))
(<AddressFamily.AF_INET: 2>, 1, 6, '', ('74.125.239.116', 80))
(<AddressFamily.AF_INET: 2>, 2, 17, '', ('74.125.239.116', 80))
(<AddressFamily.AF_INET: 2>, 1, 6, '', ('74.125.239.113', 80))
(<AddressFamily.AF_INET: 2>, 2, 17, '', ('74.125.239.113', 80))
(<AddressFamily.AF_INET: 2>, 1, 6, '', ('74.125.239.115', 80))
(<AddressFamily.AF_INET: 2>, 2, 17, '', ('74.125.239.115', 80))
(<AddressFamily.AF_INET: 2>, 1, 6, '', ('74.125.239.114', 80))
(<AddressFamily.AF_INET: 2>, 2, 17, '', ('74.125.239.114', 80))
(<AddressFamily.AF_INET6: 10>, 1, 6, '', ('2607:f8b0:4005:800::1011', 80, 0, 0))
(<AddressFamily.AF_INET6: 10>, 2, 17, '', ('2607:f8b0:4005:800::1011', 80, 0, 0))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Fri Aug 16 15:40:04 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Aug 2013 13:40:04 +0000
Subject: [issue18754] Run Python child processes in isolated mode in the test
 suite?
Message-ID: <1376660404.79.0.733501229055.issue18754@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python 3.4 has a new command line option to run Python in isolated mode: -I.

IMO it would be nice to use this option to make the test suite more independant of the user configuration and the environment.

Attached patch modifies the test.script_helper module to use the new -I option.

Some tests rely on the current directory added to sys.path, so I had to add a python_isolated=False option to script_helper for these tests.

----------
components: Tests
files: test_isolated.patch
keywords: patch
messages: 195331
nosy: christian.heimes, haypo
priority: normal
severity: normal
status: open
title: Run Python child processes in isolated mode in the test suite?
versions: Python 3.4
Added file: http://bugs.python.org/file31314/test_isolated.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18754>
_______________________________________

From report at bugs.python.org  Fri Aug 16 15:40:49 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Aug 2013 13:40:49 +0000
Subject: [issue18296] test_os.test_trailers() is failing on AMD64 FreeBSD 9.0
 dtrace 3.x
In-Reply-To: <1372119942.09.0.162654139201.issue18296@psf.upfronthosting.co.za>
Message-ID: <1376660449.26.0.411273191385.issue18296@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The test does now pass with the patch, so I close the issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18296>
_______________________________________

From report at bugs.python.org  Fri Aug 16 16:10:11 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 16 Aug 2013 14:10:11 +0000
Subject: [issue16799] start using argparse.Namespace in regrtest
In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za>
Message-ID: <1376662211.85.0.748058315438.issue16799@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Looks pretty good, Serhiy. I left some comments in Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16799>
_______________________________________

From report at bugs.python.org  Fri Aug 16 16:34:55 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Aug 2013 14:34:55 +0000
Subject: [issue18755] imp read functions do not try to re-open files that have
 been closed from previous reads
Message-ID: <1376663695.08.0.173153451138.issue18755@psf.upfronthosting.co.za>


New submission from Brett Cannon:

imp._HackedGetData doesn't check if the file it cached from its constructor is still open or not. Since the path had previously been stored it would make sense to try re-opening the file if the file object has already been closed.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 195334
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: imp read functions do not try to re-open files that have been closed from previous reads
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18755>
_______________________________________

From report at bugs.python.org  Fri Aug 16 16:52:16 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 16 Aug 2013 14:52:16 +0000
Subject: [issue18745] Test enum in test_json is ignorant of infinity value
In-Reply-To: <1376553540.47.0.197538167938.issue18745@psf.upfronthosting.co.za>
Message-ID: <1376664736.89.0.203858322562.issue18745@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18745>
_______________________________________

From report at bugs.python.org  Fri Aug 16 16:53:22 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 16 Aug 2013 14:53:22 +0000
Subject: [issue18734] Berkeley DB versions 4.4-4.9 are not discovered by
 setup.py
In-Reply-To: <1376450123.08.0.865805118992.issue18734@psf.upfronthosting.co.za>
Message-ID: <1376664802.25.0.220124003699.issue18734@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

I confirm this. The patch for 5.3 support created a regression. And, in fact, it is not working at all (it missed the 5.x libraries anyway).

Reopening the old bug.

In the meantime, please check http://www.jcea.es/programacion/pybsddb.htm

----------
dependencies: +update the bsddb module do build with db 5.x versions
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18734>
_______________________________________

From report at bugs.python.org  Fri Aug 16 16:53:46 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 16 Aug 2013 14:53:46 +0000
Subject: [issue18734] Berkeley DB versions 4.4-4.9 are not discovered by
 setup.py
In-Reply-To: <1376450123.08.0.865805118992.issue18734@psf.upfronthosting.co.za>
Message-ID: <1376664826.9.0.37633533124.issue18734@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18734>
_______________________________________

From report at bugs.python.org  Fri Aug 16 16:54:01 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 16 Aug 2013 14:54:01 +0000
Subject: [issue17477] update the bsddb module do build with db 5.x versions
In-Reply-To: <1363671295.4.0.641867038298.issue17477@psf.upfronthosting.co.za>
Message-ID: <1376664841.12.0.42168392929.issue17477@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

This patch is incorrect.

It doesn't compile with Berkeley DB 5.x at all, and it doesn't allow to compile against 4.4-4.9 (previously supported). So currently it is a bit regression.

Check bug #18734.

----------
nosy: +Eddie.Stanley
resolution: fixed -> 
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17477>
_______________________________________

From report at bugs.python.org  Fri Aug 16 17:00:35 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 16 Aug 2013 15:00:35 +0000
Subject: [issue17477] update the bsddb module do build with db 5.x versions
In-Reply-To: <1363671295.4.0.641867038298.issue17477@psf.upfronthosting.co.za>
Message-ID: <1376665235.57.0.236764766897.issue17477@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Note also that reusing my pybsddb project you are dropping support for several old releases of Berkeley DB that where supported by Python <2.7.4.

If somebody were using it, they are left dead in the water, just because doing a "minor" Python upgrade.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17477>
_______________________________________

From report at bugs.python.org  Fri Aug 16 17:21:38 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Aug 2013 15:21:38 +0000
Subject: [issue18756] os.urandom() fails under high load
Message-ID: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I have seen complains from e.g. Tarek that os.urandom() fails under high load: https://twitter.com/tarek_ziade/status/362281268215418880

The problem is caused by file descriptor limits. os.urandom() opens /dev/urandom for every call. How about os.urandom() uses a persistent file descriptor? That should eliminate the error. It may alsos speed up os.urandom() because a persistent FD gets rid of open() and close() syscalls.

* open /dev/urandom on first call of os.urandom() and store the fd in a static var
* invalidate, close fd on read() -> EINVAL; open /dev/urandom again
* close fd when interpreter shuts down

----------
components: Extension Modules
messages: 195338
nosy: christian.heimes, haypo, hynek, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: os.urandom() fails under high load
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 17:30:57 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Aug 2013 15:30:57 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376667057.94.0.579949604711.issue18756@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I have seen complains from e.g. Tarek that os.urandom() fails under high load: https://twitter.com/tarek_ziade/status/362281268215418880

dev_urandom_python() should handle ENFILE and ENOENT differently to raise a different exception. Or it should always call PyErr_SetFromErrno(PyExc_OSError); ?

Can tarek tell us more about its usecases: is he directly calling os.urandom() or does he use the random module? How many threads?

> How about os.urandom() uses a persistent file descriptor?

os.urandom() is called at Python startup to generate a "secret key" for random hash. If the file descriptor is never closed, the next file descriptor will be 4 instead of the expect 3.

Always keeping an internal file descriptor open may have unexpected effects like leaking a file descriptor to a child process... (see the PEP 446, not implemented yet).

I'm ok to keep a fd open if the user controls the lifetime of the object (lifetime of the fd). For example, I expect that rng = SystemRandom() opens /dev/urandom when the object is created, and closes it when the object is destroyed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 17:34:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 15:34:41 +0000
Subject: [issue18743] References to non-existant "StringIO" module
In-Reply-To: <1376542911.78.0.658455842148.issue18743@psf.upfronthosting.co.za>
Message-ID: <1376667281.13.0.495784976605.issue18743@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch. Actually this is a small part of larger problem for which I will open several separated issues.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31315/doc_StringIO_refs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18743>
_______________________________________

From report at bugs.python.org  Fri Aug 16 17:39:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 15:39:19 +0000
Subject: [issue18618] Need an atexit.register equivalent that also works in
 subinterps
In-Reply-To: <1375379263.55.0.273685957163.issue18618@psf.upfronthosting.co.za>
Message-ID: <1376667559.73.0.756635248641.issue18618@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18618>
_______________________________________

From report at bugs.python.org  Fri Aug 16 17:40:13 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 15:40:13 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376667613.88.0.312182705513.issue18756@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I don't think that's bug in os.urandom(). If os.urandom() doesn't fail, something else will fail soon after.
OTOH, the error is clearly misleading. The NotImplementedError should only be raised for certain errnos (such as ENOENT, ENODEV, ENXIO and EACCES), not all of them.

----------
nosy: +neologix, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 17:47:44 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 15:47:44 +0000
Subject: [issue18748] libgcc_s.so.1 must be installed for pthread_cancel to
 work
In-Reply-To: <1376657603.64.0.751497245252.issue18748@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2FCDpRfuKWMFiE2W-hgvSK4h=Z8sCX1bR4-jy+N9nqEQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Perhaps the only thing we could do would be try to "preload" libgcc by
> calling one of those APIs at startup?

Yeah, I was thinking about doing this in PyThread_init_thread() but...

> But I'm not sure it's a good idea to
> add such a platform-specific hack (for what is arguably an obscure and rare
> issue).

then thought the exact same thing.

Also, this exact problem can possibly show up anywhere dlopen() is
used (a grep through glibc code shows at least an occurrence in
nsswitch-related code).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18748>
_______________________________________

From report at bugs.python.org  Fri Aug 16 17:52:06 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 16 Aug 2013 15:52:06 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <1375531895.31.0.501848123953.issue18643@psf.upfronthosting.co.za>
Message-ID: <1376668326.3.0.682179152484.issue18643@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

Do you mean you want to use a pure python implementation on Unix?

Then you would have to deal with AF_UNIX (which is the default family for socketpair() currently).  A pure python implementation which deals with AF_UNIX would have to temporarily create a listening socket on the file system and deal with races like tempfile.mkstemp() does.  I think it is simpler to only use the pure python implementation on Windows.

BTW, it is possible for another process to connect to the address we temporily bind to.  Neither my version nor the one in tulip handle that correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Fri Aug 16 17:57:55 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Aug 2013 15:57:55 +0000
Subject: [issue18754] Run Python child processes in isolated mode in the test
 suite?
In-Reply-To: <1376660404.79.0.733501229055.issue18754@psf.upfronthosting.co.za>
Message-ID: <1376668675.76.0.515845732184.issue18754@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Haven't looked at the patch but the motivation behind it sounds good to me.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18754>
_______________________________________

From report at bugs.python.org  Fri Aug 16 17:59:17 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 16 Aug 2013 15:59:17 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376668757.65.0.762578105766.issue18756@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

I agree with Antoine. Exhausting the FDs is not the problem, the problem is the misleading error.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:02:46 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 16 Aug 2013 16:02:46 +0000
Subject: [issue18743] References to non-existant "StringIO" module
In-Reply-To: <1376542911.78.0.658455842148.issue18743@psf.upfronthosting.co.za>
Message-ID: <1376668966.25.0.564105910187.issue18743@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Patch is incomplete. I found this error while reading "unittest.mock", that you are not patching.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18743>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:03:31 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Aug 2013 16:03:31 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376669011.74.0.678923916383.issue18709@psf.upfronthosting.co.za>


Christian Heimes added the comment:

For the record PHP has assigned CVE-2013-4248 for the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:19:12 2013
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 16 Aug 2013 16:19:12 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376669952.75.0.874930027417.issue18756@psf.upfronthosting.co.za>


Tarek Ziad? added the comment:

> If os.urandom() doesn't fail, something else will fail soon after.

the random pool can be exhausted, but this is not "soon after" I think. In Linux and Mac OS X, ulimit -n defaults to 512 and 256.

It's very easy to reach that limit if you write a web app that uses this API.

> I agree with Antoine. Exhausting the FDs is not the problem,

Do you suggest that we should not use os.urandom on high load ?

Opening an FD on every call sounds under optimal, I am not seeing any drawback not to try to optimize that API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:22:54 2013
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 16 Aug 2013 16:22:54 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376670174.66.0.354097807535.issue18756@psf.upfronthosting.co.za>


Tarek Ziad? added the comment:

> Can tarek tell us more about its usecases: is he directly calling os.urandom() or does he use the random module? How many threads?

I was using ws4py inside greenlets. ws4py uses os.urandom() to generate some keys. So one single thread, many greenlets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:24:23 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 16:24:23 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376669952.75.0.874930027417.issue18756@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0dFWCCmoi6tZW6U1eJJ-AL-TKFu6J0LjPkGrbZpwPqXQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

>> If os.urandom() doesn't fail, something else will fail soon after.
>
> the random pool can be exhausted, but this is not "soon after" I think. In
> Linux and Mac OS X, ulimit -n defaults to 512 and 256.

I don't think he's referring to the entropy pool, but to RLIMIT_NOFILE.
You'll likely hit EMFILE sooner or later, e.g. on socket(), open()...

> It's very easy to reach that limit if you write a web app that uses this
> API.
>
>> I agree with Antoine. Exhausting the FDs is not the problem,
>
> Do you suggest that we should not use os.urandom on high load ?

What does high load mean?
If you mean many concurrent threads, then you should probably go for
the random module, no?

> Opening an FD on every call sounds under optimal, I am not seeing any
> drawback not to try to optimize that API.

Well, first we'll have to make the code thread-safe, if we want to
keep a persistent FD open. Which means we'll have to add a lock, which
is likely to reduce concurrency, and overall throughput.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:26:19 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Aug 2013 16:26:19 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376669952.75.0.874930027417.issue18756@psf.upfronthosting.co.za>
Message-ID: <520E52AA.5090208@cheimes.de>


Christian Heimes added the comment:

> Tarek Ziad? added the comment:
> 
>> If os.urandom() doesn't fail, something else will fail soon after.
> 
> the random pool can be exhausted, but this is not "soon after" I think. In Linux and Mac OS X, ulimit -n defaults to 512 and 256.

It's highly unlikely that you are every going to exhaust the CPRNG to a
point were it is no longer cryptographically secure. Thomas Ptacek
pointed me to http://security.stackexchange.com/a/3939 yesterday.

>> I agree with Antoine. Exhausting the FDs is not the problem,
> 
> Do you suggest that we should not use os.urandom on high load ?
> 
> Opening an FD on every call sounds under optimal, I am not seeing any drawback not to try to optimize that API.

The drawback is a slightly more complicated implementation that has to
deal with invalid FDs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:27:03 2013
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 16 Aug 2013 16:27:03 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376670423.39.0.597307495449.issue18756@psf.upfronthosting.co.za>


Tarek Ziad? added the comment:

> What does high load mean?

a web app with a few hundreds concurrent requests.

> If you mean many concurrent threads, then you should probably go for
the random module, no?

I use greenlets. But, I don't know - are you suggesting os.urandom() should be marked in the documentation as "DOES NOT SCALE" and I should use another API ? Which one ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:33:19 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 16:33:19 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376670423.39.0.597307495449.issue18756@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2npW4xk=MGVY+a-phou4z0-4Xjh8-Og8m=ML3ppxq8PQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

2013/8/16, Tarek Ziad? <report at bugs.python.org>:
> I use greenlets. But, I don't know - are you suggesting os.urandom() should
> be marked in the documentation as "DOES NOT SCALE" and I should use another
> API ? Which one ?

Well, even with greenlets, I assume you're using at least one FD
(socket) per client, no?
So you can get EMFILE on socket() just as on os.urandom(). The only
difference is that sockets are long-lived, whereas os.urandom() only
opens a FD for a couple ms. So os.urandom() isn't your biggest problem
here.
I'd suggest you to just open '/dev/urandom' once, and then make all
your threads/green-threads read from it.
IMO os.urandom() is a really poor API ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:38:02 2013
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 16 Aug 2013 16:38:02 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376671082.1.0.874272119893.issue18756@psf.upfronthosting.co.za>


Tarek Ziad? added the comment:

> Well, even with greenlets, I assume you're using at least one FD
(socket) per client, no?
> So you can get EMFILE on socket() just as on os.urandom(). 

I do many calls on urandom() so that's the FD bottleneck.

> So os.urandom() isn't your biggest problem here.

Of course it is. But it looks like you know better without having looked at the code. :)

> I'd suggest you to just open '/dev/urandom' once, 
> and then make all your threads/green-threads read from it.

Let me know how to do this without being able to prevent the API to close the FD everytime.

> IMO os.urandom() is a really poor API ;-)

Then we should improve it or deprecate it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:38:47 2013
From: report at bugs.python.org (Catherine Devlin)
Date: Fri, 16 Aug 2013 16:38:47 +0000
Subject: [issue1666318] shutil.copytree doesn't give control over directory
 permissions
Message-ID: <1376671127.72.0.0349578958043.issue1666318@psf.upfronthosting.co.za>


Catherine Devlin added the comment:

Attaching new patch incorporating Vajrasky's suggestion

----------
Added file: http://bugs.python.org/file31316/test1666318.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1666318>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:43:31 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Aug 2013 16:43:31 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <CAH_1eM0dFWCCmoi6tZW6U1eJJ-AL-TKFu6J0LjPkGrbZpwPqXQ@mail.gmail.com>
Message-ID: <520E56B2.70209@cheimes.de>


Christian Heimes added the comment:

Am 16.08.2013 18:24, schrieb Charles-Fran?ois Natali:
> Well, first we'll have to make the code thread-safe, if we want to
> keep a persistent FD open. Which means we'll have to add a lock, which
> is likely to reduce concurrency, and overall throughput.

Why locking? /dev/urandom is a pseudo char device. You can have multiple
readers on the same fd without any locking. Did you know that Java keeps
one persistent fd to /dev/urandom?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:43:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 16:43:45 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376671082.1.0.874272119893.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376671415.2510.2.camel@fsol>


Antoine Pitrou added the comment:

> > Well, even with greenlets, I assume you're using at least one FD
> (socket) per client, no?
> > So you can get EMFILE on socket() just as on os.urandom(). 
> 
> I do many calls on urandom() so that's the FD bottleneck.

Unless you're doing many calls *in parallel* it's unlikely to be a
bottleneck.
At worse you can write your own /dev/urandom reading code, with a shared
fd amongst all your threads / greenlets.

os.urandom() is a convenience function, it doesn't have to be extremely
optimized.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:44:19 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 16:44:19 +0000
Subject: [issue18706] test failure in test_codeccallbacks
In-Reply-To: <1376179395.42.0.0457635695026.issue18706@psf.upfronthosting.co.za>
Message-ID: <1376671459.63.0.247956061169.issue18706@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18706>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:47:14 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 16:47:14 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376671082.1.0.874272119893.issue18756@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3OGdFTLJXemgkiKtHDiDmdfVJvLKSsQueOM9nONDFs5A@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> I do many calls on urandom() so that's the FD bottleneck.
>
>> So os.urandom() isn't your biggest problem here.
>
> Of course it is. But it looks like you know better without having looked at
> the code. :)

So please explain me :-)
os.urandom() can only be called by one thread/greenlet at a time.
So I assumed you're using a per-client thread/greenlet, and so a
per-client socket. So, you have O(N) open sockets, which are
long-lived. OTOH, you can only have so many threads inside
os.urandom() at a time, since it's short lived, and the FD is closed
as soon as urandom() returns. So I would assume that you have
asymptotically at least as many open sockets than FDs open to
os.urandom.

>> I'd suggest you to just open '/dev/urandom' once,
>> and then make all your threads/green-threads read from it.
>
> Let me know how to do this without being able to prevent the API to close
> the FD everytime.

Simply open('/dev/urandom', 'rb').

>> IMO os.urandom() is a really poor API ;-)
>
> Then we should improve it or deprecate it.

I don't think it can be fixed. I think Christian's working on a PEP
for random number generators, which would probably make it easier,
although I din't have a look at it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:48:27 2013
From: report at bugs.python.org (Kees Bos)
Date: Fri, 16 Aug 2013 16:48:27 +0000
Subject: [issue18753] [c]ElementTree.fromstring fails to parse
 <value>]]></value>
In-Reply-To: <1376641863.98.0.614514582932.issue18753@psf.upfronthosting.co.za>
Message-ID: <1376671707.02.0.77364460266.issue18753@psf.upfronthosting.co.za>


Kees Bos added the comment:

I'm not an expert, but from: http://www.w3.org/TR/REC-xml/#NT-AttValue

	AttValue ::= '"' ([^<&"] | Reference)* '"' | "'" ([^<&'] | Reference)* "'"

which I read as: Any Reference character is valid, except & and <, which are used for escaping and closing the element.

The sequence <value>]]></value> also valdates as well-formed at http://www.xmlvalidation.com/

The sequence <value>]></value> parses OK (So, it's only with a double ] and > )

It's probably related to parsing <![CDATA[ ... ]]> (i.e. I guess when the parser detects ]]> it 
assumes / requires the state of <![CDATA[ which is, of course, not true)

The sequence <value><![CDATA[foo]]></value> is parsed correctly:
>>> ET.fromstring('<value><![CDATA[foo]]></value>').text
'foo'


BTW, lxml.etree.fromstring fails also and so does http://www.w3schools.com/xml/xml_validator.asp

I'll ask around on the lxml mailinglist what they think about this behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18753>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:48:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 16:48:31 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <520E56B2.70209@cheimes.de>
Message-ID: <1376671703.2510.3.camel@fsol>


Antoine Pitrou added the comment:

> Am 16.08.2013 18:24, schrieb Charles-Fran?ois Natali:
> > Well, first we'll have to make the code thread-safe, if we want to
> > keep a persistent FD open. Which means we'll have to add a lock, which
> > is likely to reduce concurrency, and overall throughput.
> 
> Why locking? /dev/urandom is a pseudo char device. You can have multiple
> readers on the same fd without any locking.

You must put a lock around the open() call, though, to avoid calling it
several times and losing an fd.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:51:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 16:51:58 +0000
Subject: [issue18753] [c]ElementTree.fromstring fails to parse
 <value>]]></value>
In-Reply-To: <1376641863.98.0.614514582932.issue18753@psf.upfronthosting.co.za>
Message-ID: <1376671918.76.0.625622983165.issue18753@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +eli.bendersky, scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18753>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:54:32 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Aug 2013 16:54:32 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <CAH_1eM3OGdFTLJXemgkiKtHDiDmdfVJvLKSsQueOM9nONDFs5A@mail.gmail.com>
Message-ID: <520E5947.2000405@cheimes.de>


Christian Heimes added the comment:

Am 16.08.2013 18:47, schrieb Charles-Fran?ois Natali:
> I don't think it can be fixed. I think Christian's working on a PEP
> for random number generators, which would probably make it easier,
> although I din't have a look at it.

In the light of the recent Android issue with PRNGs [1] I don't think
that Python should roll out its own CPRNG. I'd rather use the operation
system's CPRNG or OpenSSL's CPRNG. After all we aren't crypto experts.
I'd rather point my finger to OpenSSL than take the blame for a faulty
CPRNG.

[1] http://bitcoin.org/en/alert/2013-08-11-android

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:54:41 2013
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 16 Aug 2013 16:54:41 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376672081.94.0.87608927473.issue18756@psf.upfronthosting.co.za>


Tarek Ziad? added the comment:

> Unless you're doing many calls *in parallel* it's unlikely to be a
bottleneck.

That's what we're saying since message 1. Antoine, allo quoi! :)

> os.urandom() is a convenience function, it doesn't have to be extremely
optimized

I suggest that you tell it the documentation then, and explain that it does not scale and people should write their own thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:56:54 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 16:56:54 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376671703.2510.3.camel@fsol>
Message-ID: <CAH_1eM0N1FEgapmiszxTUsHB-0AVz2TMu=Ryfv68zbc9Lbc45w@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

>> Why locking? /dev/urandom is a pseudo char device. You can have multiple
>> readers on the same fd without any locking.
>
> You must put a lock around the open() call, though, to avoid calling it
> several times and losing an fd.

Exactly (unless the FD is open during the module initialization,
instead of using lazy-open upon first os.urandom() call).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 18:58:47 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 16:58:47 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <520E5947.2000405@cheimes.de>
Message-ID: <CAH_1eM2V6VhNA7b0g15z8A=otgrOWqJYQgE27=K1KUqnDrYc2Q@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> In the light of the recent Android issue with PRNGs [1] I don't think
> that Python should roll out its own CPRNG. I'd rather use the operation
> system's CPRNG or OpenSSL's CPRNG. After all we aren't crypto experts.
> I'd rather point my finger to OpenSSL than take the blame for a faulty
> CPRNG.

Yeah, sure.
But it would be nice to have an API similar to the random module (i.e.
a Random ABC, which could have several implementations, among which an
/dev/urandom backed one). The underlying FD lifetime would be tied to
the Random object lifetime, and we couldn't have to open/close it at
each call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:06:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 17:06:34 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376672794.42.0.541120988211.issue18756@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Attaching a patch to make error reporting better.

----------
keywords: +patch
Added file: http://bugs.python.org/file31317/urandom_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:08:58 2013
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 16 Aug 2013 17:08:58 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376672938.21.0.0587923814096.issue18756@psf.upfronthosting.co.za>


Tarek Ziad? added the comment:

> So please explain me :-).

it sounded like you did not really want any explanation 

>  os.urandom() can only be called by one thread/greenlet at a time.

do you mean that we cannot have two parallel calls of that function ?
e.g. two opened FD at the same time ?

> So I would assume that you have asymptotically at least as many open sockets than FDs open to os.urandom.

a web socket application that spawns one socket per connection, then uses a lib that calls many times os.urandom(), will generate most of its FDs on os urandom

but since you said that os.urandom() should not be used in the first place - that's what I will keep in mind

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:13:08 2013
From: report at bugs.python.org (Donald Stufft)
Date: Fri, 16 Aug 2013 17:13:08 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376673188.24.0.574950524663.issue18756@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Just to be explicit, ``open("/dev/urandom")`` only works on POSIX platforms while ``os.usrandom`` should work on any supported platform that has an OS level source of randomness. So advocating *for* simply using ``open()`` is probably a bad idea unless the target OS is only POSIX.

----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:14:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 17:14:27 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376673267.42.0.917261012532.issue18756@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Good point, Donald. os.urandom() is the only (simple) way to access the Windows randomness pool.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:17:34 2013
From: report at bugs.python.org (Donald Stufft)
Date: Fri, 16 Aug 2013 17:17:34 +0000
Subject: [issue16190] Misleading warning in random module docs
In-Reply-To: <1349885590.41.0.193272073786.issue16190@psf.upfronthosting.co.za>
Message-ID: <1376673454.41.0.591145811676.issue16190@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald.stufft at gmail.com>:


----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16190>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:21:35 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Aug 2013 17:21:35 +0000
Subject: [issue16190] Misleading warning in random module docs
In-Reply-To: <1349885590.41.0.193272073786.issue16190@psf.upfronthosting.co.za>
Message-ID: <3cGrt641G8z7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset 9df0501fab35 by Antoine Pitrou in branch '3.3':
Issue #16190: fix random module recommendation to use ssl.RAND_bytes().
http://hg.python.org/cpython/rev/9df0501fab35

New changeset 04b50a1eb013 by Antoine Pitrou in branch 'default':
Issue #16190: fix random module recommendation to use ssl.RAND_bytes().
http://hg.python.org/cpython/rev/04b50a1eb013

New changeset 48b618a9ad10 by Antoine Pitrou in branch '2.7':
Issue #16190: fix random module recommendation to use ssl.RAND_bytes().
http://hg.python.org/cpython/rev/48b618a9ad10

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16190>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:21:54 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 16 Aug 2013 17:21:54 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376673714.28.0.834448112972.issue18756@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:22:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 17:22:25 +0000
Subject: [issue16190] Misleading warning in random module docs
In-Reply-To: <1349885590.41.0.193272073786.issue16190@psf.upfronthosting.co.za>
Message-ID: <1376673745.51.0.730086974202.issue16190@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Done.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16190>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:29:08 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 17:29:08 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376672794.42.0.541120988211.issue18756@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM313AZs-o=Xm6J_mxo1MRqEdo7iA8N2FWXkv0Zuzg4QfA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Attaching a patch to make error reporting better.

Why didn't you include ENODEV?
Apparently it can be reported in some corner cases, e.g. in this patch:
http://lfs-matrix.net/patches/downloads/linux/linux-2.6.14.2-pseudo_random-1.patch

Otherwise, wouldn't self.addCleanup be simpler than the large
try/finally block in the test (but it's not available on 2.7)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:32:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 17:32:28 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <CAH_1eM313AZs-o=Xm6J_mxo1MRqEdo7iA8N2FWXkv0Zuzg4QfA@mail.gmail.com>
Message-ID: <1376674336.2510.6.camel@fsol>


Antoine Pitrou added the comment:

> Why didn't you include ENODEV?
> Apparently it can be reported in some corner cases, e.g. in this patch:
> http://lfs-matrix.net/patches/downloads/linux/linux-2.6.14.2-pseudo_random-1.patch

That isn't mentioned in the POSIX open() spec:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html

However ENODEV still seems to be a standard errno constant, so why not:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html

> Otherwise, wouldn't self.addCleanup be simpler than the large
> try/finally block in the test (but it's not available on 2.7)?

The problem is if some code tries to create a fd before the cleanup
callback is called. With a try/finally block we're guaranteed not to
have such a problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:33:44 2013
From: report at bugs.python.org (Donald Stufft)
Date: Fri, 16 Aug 2013 17:33:44 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376674424.89.0.141447255493.issue18756@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Looking at random.SystemRandom it appears it would suffer from the same FD exhaustion problem.

So as of right now afaik none of the sources of cryptographically secure random in the python stdlib offer a way to open a persistent FD. The primary question on my mind is if os.urandom can't be modified to maintain a persistent FD can Python offer a urandom class that *will* maintain a persistent FD?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:36:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Aug 2013 17:36:30 +0000
Subject: [issue1666318] shutil.copytree doesn't give control over directory
 permissions
Message-ID: <3cGsCK2pShz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset c388e93879c4 by Antoine Pitrou in branch '3.3':
Issue #1666318: Add a test that shutil.copytree() retains directory permissions.
http://hg.python.org/cpython/rev/c388e93879c4

New changeset 8906713d5704 by Antoine Pitrou in branch 'default':
Issue #1666318: Add a test that shutil.copytree() retains directory permissions.
http://hg.python.org/cpython/rev/8906713d5704

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1666318>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:37:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 17:37:38 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376674424.89.0.141447255493.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376674650.2510.7.camel@fsol>


Antoine Pitrou added the comment:

> So as of right now afaik none of the sources of cryptographically
> secure random in the python stdlib offer a way to open a persistent
> FD. The primary question on my mind is if os.urandom can't be modified
> to maintain a persistent FD can Python offer a urandom class that
> *will* maintain a persistent FD?

Well, if we want to offer such a facility, let's bundle it in
os.urandom(). It would be suboptimal to have two slightly different
implementations of the same thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:38:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 17:38:07 +0000
Subject: [issue1666318] shutil.copytree doesn't give control over directory
 permissions
Message-ID: <1376674687.26.0.0199019846167.issue1666318@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Patch committed to 3.3 and 3.4. Thank you very much!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1666318>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:41:32 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 17:41:32 +0000
Subject: [issue18701] Remove outdated PY_VERSION_HEX checks
In-Reply-To: <1376130113.84.0.145821919316.issue18701@psf.upfronthosting.co.za>
Message-ID: <1376674892.76.0.615360331157.issue18701@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18701>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:43:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 17:43:35 +0000
Subject: [issue18757] Fix internal references for concurrent modules
Message-ID: <1376675015.24.0.101209198038.issue18757@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in the documentation of concurrent modules: threading, multiprocessing, concurrent.futures, subprocess, queue, and select.

----------
assignee: docs at python
components: Documentation
messages: 195378
nosy: bquinlan, docs at python, jnoller, pitrou, rhettinger, sbt, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix internal references for concurrent modules
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18757>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:44:56 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Aug 2013 17:44:56 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
 iterable)
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1376675096.92.0.0483806559999.issue18652@psf.upfronthosting.co.za>


R. David Murray added the comment:

For what it is worth, I am currently writing some email tests and it would certainly be convenient to have this.  Of course I *can* define it locally in the the test file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18652>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:46:49 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 17:46:49 +0000
Subject: [issue18757] Fix internal references for concurrent modules
In-Reply-To: <1376675015.24.0.101209198038.issue18757@psf.upfronthosting.co.za>
Message-ID: <1376675209.61.0.306915736914.issue18757@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Serhiy, seems you forgot to attach a patch.

----------
nosy: +ezio.melotti
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18757>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:50:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 17:50:16 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376675416.61.0.508929144069.issue18756@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Attached patch to make os.urandom's fd persistent.

----------
type: behavior -> resource usage
Added file: http://bugs.python.org/file31318/persistent_urandom_fd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 19:53:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 17:53:56 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376675636.59.0.769682143449.issue18756@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Updated error handling patch testing for ENODEV.

----------
Added file: http://bugs.python.org/file31319/urandom_error2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:00:47 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 18:00:47 +0000
Subject: [issue16463] testConnectTimeout of test_timeout
 TCPTimeoutTestCasefailures fails intermittently
In-Reply-To: <1352757217.25.0.912881014186.issue16463@psf.upfronthosting.co.za>
Message-ID: <1376676047.57.0.144299134707.issue16463@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


Added file: http://bugs.python.org/file31320/connect_timeout-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16463>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:07:49 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 18:07:49 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1376676469.22.0.40031309686.issue18704@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Can't this be developed as an external extension?
I don't see a reason to include it in the stdlib, especially if it requires other dependencies (like the pep8 module).

----------
nosy: +ezio.melotti
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:13:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 18:13:34 +0000
Subject: [issue16799] start using argparse.Namespace in regrtest
In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za>
Message-ID: <1376676814.77.0.993299508557.issue16799@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for the review Eli. Could you please review issue17974 while I will write tests?

As for a duplication I think about using vars():


def main(tests=None, testdir=None, verbose=0, quiet=False, ...):
    return _main(**vars())

def _main(tests, testdir, **kwargs):
    ns = argparse.Namespace(**kwargs)
    ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16799>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:13:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 18:13:49 +0000
Subject: [issue16799] start using argparse.Namespace in regrtest
In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za>
Message-ID: <1376676829.28.0.142164811283.issue16799@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16799>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:14:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 18:14:27 +0000
Subject: [issue16799] start using argparse.Namespace in regrtest
In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za>
Message-ID: <1376676867.94.0.784116085059.issue16799@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16799>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:17:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 18:17:26 +0000
Subject: [issue18743] References to non-existant "StringIO" module
In-Reply-To: <1376542911.78.0.658455842148.issue18743@psf.upfronthosting.co.za>
Message-ID: <1376677046.02.0.0290662288718.issue18743@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't see StringIO in Doc/library/unittest.mock.rst.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18743>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:31:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 18:31:53 +0000
Subject: [issue18743] References to non-existant "StringIO" module
In-Reply-To: <1376542911.78.0.658455842148.issue18743@psf.upfronthosting.co.za>
Message-ID: <1376677913.74.0.879800207905.issue18743@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, I missed it. Here is completed patch.

----------
Added file: http://bugs.python.org/file31321/doc_StringIO_refs_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18743>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:33:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Aug 2013 18:33:42 +0000
Subject: [issue18707] the readme should also talk about how to build doc.
In-Reply-To: <1376203024.02.0.197448582438.issue18707@psf.upfronthosting.co.za>
Message-ID: <3cGtTK6XpNz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 6bc88d61f302 by Ezio Melotti in branch '2.7':
#18707: point to Doc/README.txt in the README file.  Patch by Madison May.
http://hg.python.org/cpython/rev/6bc88d61f302

New changeset 477a143bfbfd by Ezio Melotti in branch '3.3':
#18707: point to Doc/README.txt in the README file.  Patch by Madison May.
http://hg.python.org/cpython/rev/477a143bfbfd

New changeset 96c51207e7cd by Ezio Melotti in branch 'default':
#18707: merge with 3.3.
http://hg.python.org/cpython/rev/96c51207e7cd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18707>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:34:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 18:34:26 +0000
Subject: [issue18757] Fix internal references for concurrent modules
In-Reply-To: <1376675015.24.0.101209198038.issue18757@psf.upfronthosting.co.za>
Message-ID: <1376678066.4.0.794939524515.issue18757@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry. It is here.

----------
keywords: +patch
Added file: http://bugs.python.org/file31322/refs.concurrect.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18757>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:34:28 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 18:34:28 +0000
Subject: [issue18707] the readme should also talk about how to build doc.
In-Reply-To: <1376203024.02.0.197448582438.issue18707@psf.upfronthosting.co.za>
Message-ID: <1376678068.95.0.402752793942.issue18707@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18707>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:35:05 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Aug 2013 18:35:05 +0000
Subject: [issue16190] Misleading warning in random module docs
In-Reply-To: <1349885590.41.0.193272073786.issue16190@psf.upfronthosting.co.za>
Message-ID: <1376678105.06.0.802199109163.issue16190@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Why did you remove reference to ssl.RAND_bytes() on Python 3.3 from the notice?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16190>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:38:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 18:38:47 +0000
Subject: [issue16190] Misleading warning in random module docs
In-Reply-To: <1349885590.41.0.193272073786.issue16190@psf.upfronthosting.co.za>
Message-ID: <1376678327.61.0.566047884703.issue16190@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

As far as I understand, os.urandom() is fine for the task. There's no point in mentioning ssl.RAND_bytes() just because it exists, IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16190>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:38:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 18:38:58 +0000
Subject: [issue18758] Fix internal references in the documentation
Message-ID: <1376678338.7.0.979265810368.issue18758@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

This is a meta issue for fixing broken references in the documentation. I will open a child issues for some groups of modules and finally provide a patch for rest files.

----------
assignee: docs at python
components: Documentation
messages: 195392
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix internal references in the documentation
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18758>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:39:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 18:39:56 +0000
Subject: [issue18758] Fix internal references in the documentation
In-Reply-To: <1376678338.7.0.979265810368.issue18758@psf.upfronthosting.co.za>
Message-ID: <1376678396.35.0.0668983458642.issue18758@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Fix internal references for concurrent modules, References to non-existant "StringIO" module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18758>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:42:48 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 18:42:48 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376675636.59.0.769682143449.issue18756@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2fHYgjTyoXBeORjTnNQFtzG9K8_4h+Gq8NdMrU5DsP6Q@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Updated error handling patch testing for ENODEV.

LGTM, you can apply to 2.7 and 3.x (I just hope all those errnos are
available on every POSIX platform ;-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:52:05 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Aug 2013 18:52:05 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <3cGttX4hM0z7Ljp@mail.python.org>


Roundup Robot added the comment:

New changeset 193bcc12575d by Antoine Pitrou in branch '3.3':
Issue #18756: Improve error reporting in os.urandom() when the failure is due to something else than /dev/urandom not existing.
http://hg.python.org/cpython/rev/193bcc12575d

New changeset fe949918616c by Antoine Pitrou in branch 'default':
Issue #18756: Improve error reporting in os.urandom() when the failure is due to something else than /dev/urandom not existing.
http://hg.python.org/cpython/rev/fe949918616c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:54:18 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Aug 2013 18:54:18 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <3cGtx62Nv6z7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset ec296a36156b by Antoine Pitrou in branch '2.7':
Issue #18756: Improve error reporting in os.urandom() when the failure is due to something else than /dev/urandom not existing.
http://hg.python.org/cpython/rev/ec296a36156b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 20:54:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 18:54:59 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376679299.08.0.788404142816.issue18756@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, committed. We're left with the persistent fd patch for 3.4.

----------
stage: needs patch -> patch review
versions:  -Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 21:09:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 19:09:01 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376680141.85.0.812583874786.issue18720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Besides some nitpicks which I have left on Rietveld the patch LGTM.

I guess the _family_converter idiom will be popular enough. Perhaps we will add some helper just to the Enum class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Fri Aug 16 21:09:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 19:09:38 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376680178.04.0.137866587423.issue18756@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Updated patch for persistent fd.

----------
Added file: http://bugs.python.org/file31323/persistent_urandom_fd2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 21:13:14 2013
From: report at bugs.python.org (Kees Bos)
Date: Fri, 16 Aug 2013 19:13:14 +0000
Subject: [issue18753] [c]ElementTree.fromstring fails to parse
 <value>]]></value>
In-Reply-To: <1376641863.98.0.614514582932.issue18753@psf.upfronthosting.co.za>
Message-ID: <1376680394.97.0.235830104655.issue18753@psf.upfronthosting.co.za>


Kees Bos added the comment:

OK. I got clarification from the lxml list. It's not a bug. And it's sepcified in section 2.4 (http://www.w3.org/TR/REC-xml/#syntax):

The ampersand character (&) and the left angle bracket (<) MUST NOT appear in their literal form, except when used as markup delimiters, or within a comment, a processing instruction, or a CDATA section. If they are needed elsewhere, they MUST be escaped using either numeric character references or the strings " &amp; " and " &lt; " respectively. The right angle bracket (>) may be represented using the string " &gt; ", and MUST, for compatibility, be escaped using either " &gt; " or a character reference when it appears in the string " ]]> " in content, when that string is not marking the end of a CDATA section.

In the content of elements, character data is any string of characters which does not contain the start-delimiter of any markup and does not include the CDATA-section-close delimiter, " ]]> ". In a CDATA section, character data is any string of characters not including the CDATA-section-close delimiter, " ]]> ".


Sorry for the confusion and taking your time for a bogus report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18753>
_______________________________________

From report at bugs.python.org  Fri Aug 16 21:13:34 2013
From: report at bugs.python.org (Kees Bos)
Date: Fri, 16 Aug 2013 19:13:34 +0000
Subject: [issue18753] [c]ElementTree.fromstring fails to parse
 <value>]]></value>
In-Reply-To: <1376641863.98.0.614514582932.issue18753@psf.upfronthosting.co.za>
Message-ID: <1376680414.98.0.931921482794.issue18753@psf.upfronthosting.co.za>


Changes by Kees Bos <k.bos at capitar.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18753>
_______________________________________

From report at bugs.python.org  Fri Aug 16 21:19:10 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Aug 2013 19:19:10 +0000
Subject: [issue18753] [c]ElementTree.fromstring fails to parse
 <value>]]></value>
In-Reply-To: <1376641863.98.0.614514582932.issue18753@psf.upfronthosting.co.za>
Message-ID: <1376680750.29.0.407907800796.issue18753@psf.upfronthosting.co.za>


R. David Murray added the comment:

Not a problem, these things are often subtle.  And now there is a record of it in the tracker if anyone else questions it in the future.

----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18753>
_______________________________________

From report at bugs.python.org  Fri Aug 16 21:22:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 19:22:35 +0000
Subject: [issue18759] Fix internal doc references for logging package
Message-ID: <1376680954.66.0.549191685954.issue18759@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in the documentation of the logging package.

----------
assignee: docs at python
components: Documentation
files: refs.logging.diff
keywords: patch
messages: 195401
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka, vinay.sajip
priority: normal
severity: normal
stage: patch review
status: open
title: Fix internal doc references for logging package
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31324/refs.logging.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18759>
_______________________________________

From report at bugs.python.org  Fri Aug 16 21:27:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 19:27:26 +0000
Subject: [issue16105] Pass read only FD to signal.set_wakeup_fd
In-Reply-To: <1349125559.77.0.651840030069.issue16105@psf.upfronthosting.co.za>
Message-ID: <1376681246.48.0.514569444479.issue16105@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Updated patch using PyErr_WriteUnraisable().

----------
stage:  -> patch review
Added file: http://bugs.python.org/file31325/wakeup_fd_error2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16105>
_______________________________________

From report at bugs.python.org  Fri Aug 16 21:34:45 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 19:34:45 +0000
Subject: [issue18758] Fix internal references in the documentation
In-Reply-To: <1376678338.7.0.979265810368.issue18758@psf.upfronthosting.co.za>
Message-ID: <1376681685.31.0.119940554602.issue18758@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Note that not all the targets should be converted to links.  They should be converted only if the link is useful, and usually redundant links are not necessary (e.g. if the same target is repeated several times in the same paragraph/section).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18758>
_______________________________________

From report at bugs.python.org  Fri Aug 16 21:38:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 19:38:19 +0000
Subject: [issue18760] Fix internal doc references for the xml package
Message-ID: <1376681899.06.0.47911099673.issue18760@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in the documentation of the xml package.

----------
assignee: docs at python
components: Documentation
messages: 195404
nosy: christian.heimes, docs at python, eli.bendersky, eric.araujo, ezio.melotti, georg.brandl, scoder, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix internal doc references for the xml package
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18760>
_______________________________________

From report at bugs.python.org  Fri Aug 16 21:39:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 19:39:36 +0000
Subject: [issue18758] Fix internal references in the documentation
In-Reply-To: <1376678338.7.0.979265810368.issue18758@psf.upfronthosting.co.za>
Message-ID: <1376681976.28.0.115012556681.issue18758@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Fix internal doc references for logging package, Fix internal doc references for the xml package

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18758>
_______________________________________

From report at bugs.python.org  Fri Aug 16 21:41:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 19:41:02 +0000
Subject: [issue18758] Fix internal references in the documentation
In-Reply-To: <1376678338.7.0.979265810368.issue18758@psf.upfronthosting.co.za>
Message-ID: <1376682062.44.0.107758515694.issue18758@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In such case perhaps links should be explicitly prohibited (with '!' mark).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18758>
_______________________________________

From report at bugs.python.org  Fri Aug 16 21:44:01 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 16 Aug 2013 19:44:01 +0000
Subject: [issue18716] Deprecate the formatter module
In-Reply-To: <1376334968.93.0.863346638514.issue18716@psf.upfronthosting.co.za>
Message-ID: <1376682241.7.0.943395844679.issue18716@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18716>
_______________________________________

From report at bugs.python.org  Fri Aug 16 21:47:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 19:47:32 +0000
Subject: [issue18761] Fix internal doc references for the email package
Message-ID: <1376682451.08.0.523486132403.issue18761@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a preliminary patch (long lines are not wrapped yet) which fixes internal references in the documentation of the email package.

----------
assignee: docs at python
components: Documentation
files: refs.email.diff
keywords: patch
messages: 195406
nosy: barry, docs at python, eric.araujo, ezio.melotti, georg.brandl, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix internal doc references for the email package
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31326/refs.email.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18761>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:04:17 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 20:04:17 +0000
Subject: [issue18715] Tests fail when run with coverage
In-Reply-To: <1376334932.92.0.162234474623.issue18715@psf.upfronthosting.co.za>
Message-ID: <1376683457.65.0.746841345374.issue18715@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

It's probably better to open a separate issue for each test module that is failing, possibly by keeping this as a meta-issue.

----------
nosy: +ezio.melotti
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18715>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:15:48 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 20:15:48 +0000
Subject: [issue18718] datetime documentation contradictory on leap second
 support
In-Reply-To: <1376339376.74.0.0279691228671.issue18718@psf.upfronthosting.co.za>
Message-ID: <1376684148.7.0.160516085216.issue18718@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Can this be closed?

----------
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18718>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:16:47 2013
From: report at bugs.python.org (David Wolever)
Date: Fri, 16 Aug 2013 20:16:47 +0000
Subject: [issue18718] datetime documentation contradictory on leap second
 support
In-Reply-To: <1376339376.74.0.0279691228671.issue18718@psf.upfronthosting.co.za>
Message-ID: <1376684207.97.0.267323379708.issue18718@psf.upfronthosting.co.za>


David Wolever added the comment:

D'oh, yes, it can (and I've closed it now).

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18718>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:19:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 20:19:40 +0000
Subject: [issue18762] error in test_multiprocessing_forkserver
Message-ID: <1376684380.66.0.0393627862698.issue18762@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

One buildbot has exhibited (sporadic?) errors in test_multiprocessing_forkserver:

http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/4823/steps/test/logs/stdio

----------
components: Library (Lib), Tests
messages: 195410
nosy: pitrou, sbt
priority: normal
severity: normal
status: open
title: error in test_multiprocessing_forkserver
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18762>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:20:59 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 20:20:59 +0000
Subject: [issue18729] In unittest.TestLoader.discover doc select the name of
 load_tests function
In-Reply-To: <1376418287.73.0.835584535115.issue18729@psf.upfronthosting.co.za>
Message-ID: <1376684459.92.0.752882961466.issue18729@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, michael.foord
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18729>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:29:19 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 20:29:19 +0000
Subject: [issue18731] Increased test coverage for uu and telnet
Message-ID: <1376684959.39.0.262767265237.issue18731@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18731>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:29:26 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Aug 2013 20:29:26 +0000
Subject: [issue18743] References to non-existant "StringIO" module
In-Reply-To: <1376542911.78.0.658455842148.issue18743@psf.upfronthosting.co.za>
Message-ID: <1376684966.82.0.209331927031.issue18743@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

LGTM

----------
nosy: +terry.reedy
stage: patch review -> commit review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18743>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:31:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Aug 2013 20:31:21 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za>
Message-ID: <3cGx5467VNzRhQ@mail.python.org>


Roundup Robot added the comment:

New changeset be5481bf4c57 by Antoine Pitrou in branch 'default':
Fix the default placeholder in textwrap.shorten() to be " [...]".
http://hg.python.org/cpython/rev/be5481bf4c57

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18585>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:31:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 20:31:54 +0000
Subject: [issue18585] Add a text truncation function
In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za>
Message-ID: <1376685114.16.0.99100739477.issue18585@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(Ezio noticed that I had left the placeholder as " (...)". This is now fixed.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18585>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:37:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 20:37:46 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376685466.63.0.944181542392.issue18756@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Updated patch after Christian's comments.

----------
Added file: http://bugs.python.org/file31327/persistent_urandom_fd3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:39:00 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 20:39:00 +0000
Subject: [issue18736] Invalid charset in HTML pages inside documentation in
 CHM format
In-Reply-To: <1376481546.2.0.725412367622.issue18736@psf.upfronthosting.co.za>
Message-ID: <1376685540.19.0.526989563886.issue18736@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This is a problem with Sphinx and should be reported upstream.
These encondings are defined in the htmlhelp builder and they are recognized by Python, but indeed they shouldn't end up in the meta tag.

----------
assignee: docs at python -> georg.brandl
nosy: +ezio.melotti, georg.brandl
status: open -> pending
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18736>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:45:44 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Aug 2013 20:45:44 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376685944.35.0.830122744909.issue18756@psf.upfronthosting.co.za>


Christian Heimes added the comment:

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:46:45 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 20:46:45 +0000
Subject: [issue18741] Fix typos/spelling mistakes in Lib/*/*/.py files
In-Reply-To: <1376515284.41.0.228001908428.issue18741@psf.upfronthosting.co.za>
Message-ID: <1376686005.93.0.666754778191.issue18741@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18741>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:47:36 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 20:47:36 +0000
Subject: [issue18705] Fix typos/spelling mistakes in Lib/*.py files
In-Reply-To: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>
Message-ID: <1376686056.26.0.347750869316.issue18705@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

See also #18741.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18705>
_______________________________________

From report at bugs.python.org  Fri Aug 16 22:59:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 20:59:35 +0000
Subject: [issue18744] pathological performance using tarfile
In-Reply-To: <1376544025.63.0.959353089302.issue18744@psf.upfronthosting.co.za>
Message-ID: <1376686775.42.0.915162102884.issue18744@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for the script Richard.

If you say about performance degradation when extracting a tarfile in changed order this behavior is expected. When you read a gzip file in random order you need seek in it. A gzip file is a singe-direction road. For seeking in a gzip file you need decompress all data between you current position (or from the file start) and target position. In case of random order you need decompress 1/3 tarfile in the mean for every extracted file.

THe tarfile module can't do anything with this. It can't first extract all file in the memory because uncompressed file can be too big. It can't resort a list of extracted file in natural order because it can change semantic (a tarfile can contains duplicates and symlinks). Just don't do this. Don't extract a large number of files from compressed tarfile in changed order.

----------
nosy: +nadeem.vawda, r.david.murray
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18744>
_______________________________________

From report at bugs.python.org  Fri Aug 16 23:08:42 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Aug 2013 21:08:42 +0000
Subject: [issue17628] str==str: compare the first character before calling
 memcmp()
In-Reply-To: <1365024552.84.0.0461498193244.issue17628@psf.upfronthosting.co.za>
Message-ID: <1376687322.23.0.12295164921.issue17628@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, there are two distinct issues.  As everyone has noted here, accessing memory in non-sequential order is a performance killer.

The other issue (the one I was working on) is that early-out first-char or last-char tests are a waste (almost never executed) if we already know that the string hashes match (i.e. in the string equality calls from the  dict and set lookup routines).  If the hashes match, the odds are 2**64 to 1 if favor of the strings being equal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17628>
_______________________________________

From report at bugs.python.org  Fri Aug 16 23:13:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Aug 2013 21:13:15 +0000
Subject: [issue18743] References to non-existant "StringIO" module
In-Reply-To: <1376542911.78.0.658455842148.issue18743@psf.upfronthosting.co.za>
Message-ID: <3cGy1R1gYzz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset b23ad357c214 by Serhiy Storchaka in branch '3.3':
Issue #18743: Fix references to non-existant "StringIO" module.
http://hg.python.org/cpython/rev/b23ad357c214

New changeset 3acbd7aca856 by Serhiy Storchaka in branch 'default':
Issue #18743: Fix references to non-existant "StringIO" module.
http://hg.python.org/cpython/rev/3acbd7aca856

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18743>
_______________________________________

From report at bugs.python.org  Fri Aug 16 23:14:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 21:14:02 +0000
Subject: [issue16463] testConnectTimeout of test_timeout
 TCPTimeoutTestCasefailures fails intermittently
In-Reply-To: <1352757217.25.0.912881014186.issue16463@psf.upfronthosting.co.za>
Message-ID: <1376687642.58.0.4589018634.issue16463@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16463>
_______________________________________

From report at bugs.python.org  Fri Aug 16 23:16:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 21:16:39 +0000
Subject: [issue18758] Fix internal references in the documentation
In-Reply-To: <1376678338.7.0.979265810368.issue18758@psf.upfronthosting.co.za>
Message-ID: <1376687799.43.0.73509402702.issue18758@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Fix internal doc references for the email package

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18758>
_______________________________________

From report at bugs.python.org  Fri Aug 16 23:18:05 2013
From: report at bugs.python.org (Felipe Cruz)
Date: Fri, 16 Aug 2013 21:18:05 +0000
Subject: [issue16105] Pass read only FD to signal.set_wakeup_fd
In-Reply-To: <1349125559.77.0.651840030069.issue16105@psf.upfronthosting.co.za>
Message-ID: <1376687885.07.0.0240833045523.issue16105@psf.upfronthosting.co.za>


Felipe Cruz added the comment:

Looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16105>
_______________________________________

From report at bugs.python.org  Fri Aug 16 23:22:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Aug 2013 21:22:16 +0000
Subject: [issue16463] testConnectTimeout of test_timeout
 TCPTimeoutTestCasefailures fails intermittently
In-Reply-To: <1352757217.25.0.912881014186.issue16463@psf.upfronthosting.co.za>
Message-ID: <3cGyCq5jf6z7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 5880c7d33e13 by Charles-Fran?ois Natali in branch '3.3':
Issue #16463: Fix a transient test_timeout failure.
http://hg.python.org/cpython/rev/5880c7d33e13

New changeset 5d4fe1da2c90 by Charles-Fran?ois Natali in branch 'default':
Issue #16463: Fix a transient test_timeout failure.
http://hg.python.org/cpython/rev/5d4fe1da2c90

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16463>
_______________________________________

From report at bugs.python.org  Fri Aug 16 23:37:04 2013
From: report at bugs.python.org (K Richard Pixley)
Date: Fri, 16 Aug 2013 21:37:04 +0000
Subject: [issue18744] pathological performance using tarfile
In-Reply-To: <1376544025.63.0.959353089302.issue18744@psf.upfronthosting.co.za>
Message-ID: <1376689024.8.0.57393226484.issue18744@psf.upfronthosting.co.za>


K Richard Pixley added the comment:

I see your point.

The alternative would be to limit the size of archive that can be extracted from to the size of virtual memory, which is essentially what I'm doing manually.  Either way, someone will be surprised.  I'm not which which way will result in the least surprise since I suspect that far more people will be extracting from compressed archives than will be extracting very large archives.  The failure mode with limited file size seems much less frequent but also much more annoying.  In comparison, the failure, (and the pathological case is effectively a failure), reading compressed archives seems much more common to me, although granted, not completely a total failure.

I think this should be mentioned in the doc because I, at least, was extremely surprised by this behavior and it cost me some time to track it down.  I might suggest something along the lines of:

Be careful when working with compressed archives.  In order to support the largest file sizes possible, some approaches may result in pathological behavior causing the original archive to be decompressed, in full, many times.  You should be able to avoid this behavior if you traverse the TarInfo items in file order.  You might also consider decompressing the archive first, in memory, and then handing the memory copy to tarfile for processing.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18744>
_______________________________________

From report at bugs.python.org  Fri Aug 16 23:37:29 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 21:37:29 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376659714.45.0.127474841484.issue18720@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2jC-APENTmND_aN5M-+XuEw-qX9j2q0Yevo70vTrLoRw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> The attached patch fixes it in a similar vein to what was done for the
> family accessor: getaddrinfo is overridden in Python and does the necessary
> conversion.

Am I the only one thinking that wrapping every C function with a
Python counterpart to perform enum conversions is tedious, ugly and
error-prone :-\

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Fri Aug 16 23:44:58 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Aug 2013 21:44:58 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376689498.34.0.52062039123.issue18720@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I wonder how much of an performance issue these wrappers are going to be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Fri Aug 16 23:50:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Aug 2013 21:50:29 +0000
Subject: [issue18701] Remove outdated PY_VERSION_HEX checks
In-Reply-To: <1376130113.84.0.145821919316.issue18701@psf.upfronthosting.co.za>
Message-ID: <3cGyrN5l4zzPNV@mail.python.org>


Roundup Robot added the comment:

New changeset a04d957c8d07 by Serhiy Storchaka in branch 'default':
Issue #18701: Remove support of old CPython versions (<3.0) from C code.
http://hg.python.org/cpython/rev/a04d957c8d07

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18701>
_______________________________________

From report at bugs.python.org  Fri Aug 16 23:55:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 21:55:44 +0000
Subject: [issue18744] pathological performance using tarfile
In-Reply-To: <1376544025.63.0.959353089302.issue18744@psf.upfronthosting.co.za>
Message-ID: <1376690144.69.0.313597234283.issue18744@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think in most cases peoples extracts archives in natural order and don't have a failure.

But adding a warning looks reasonable.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
stage:  -> needs patch
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18744>
_______________________________________

From report at bugs.python.org  Fri Aug 16 23:56:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 21:56:15 +0000
Subject: [issue18701] Remove outdated PY_VERSION_HEX checks
In-Reply-To: <1376130113.84.0.145821919316.issue18701@psf.upfronthosting.co.za>
Message-ID: <1376690175.75.0.978207743987.issue18701@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Your commit forgot to remove sqlitecompat.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18701>
_______________________________________

From report at bugs.python.org  Fri Aug 16 23:57:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 21:57:40 +0000
Subject: [issue18741] Fix typos/spelling mistakes in Lib/*/*/.py files
In-Reply-To: <1376515284.41.0.228001908428.issue18741@psf.upfronthosting.co.za>
Message-ID: <1376690260.49.0.819274395805.issue18741@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18741>
_______________________________________

From report at bugs.python.org  Fri Aug 16 23:57:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 21:57:50 +0000
Subject: [issue18705] Fix typos/spelling mistakes in Lib/*.py files
In-Reply-To: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>
Message-ID: <1376690270.11.0.481837700013.issue18705@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18705>
_______________________________________

From report at bugs.python.org  Sat Aug 17 00:03:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 22:03:22 +0000
Subject: [issue18701] Remove outdated PY_VERSION_HEX checks
In-Reply-To: <1376130113.84.0.145821919316.issue18701@psf.upfronthosting.co.za>
Message-ID: <1376690602.09.0.690869338191.issue18701@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, I forgot that this patch need `hg import` instead of `patch --merge -p1`.

Thank you Antoine.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18701>
_______________________________________

From report at bugs.python.org  Sat Aug 17 00:04:09 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Aug 2013 22:04:09 +0000
Subject: [issue18701] Remove outdated PY_VERSION_HEX checks
In-Reply-To: <1376130113.84.0.145821919316.issue18701@psf.upfronthosting.co.za>
Message-ID: <3cGz890cB9z7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 2150c7d6426c by Serhiy Storchaka in branch 'default':
Issue #18701: Remove sqlitecompat.h.
http://hg.python.org/cpython/rev/2150c7d6426c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18701>
_______________________________________

From report at bugs.python.org  Sat Aug 17 00:04:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 22:04:47 +0000
Subject: [issue18757] Fix internal references for concurrent modules
In-Reply-To: <1376675015.24.0.101209198038.issue18757@psf.upfronthosting.co.za>
Message-ID: <1376690687.57.0.338470775907.issue18757@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is updated patch. Thank Ezio for found errors.

----------
Added file: http://bugs.python.org/file31328/refs.concurrect.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18757>
_______________________________________

From report at bugs.python.org  Sat Aug 17 00:07:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 22:07:56 +0000
Subject: [issue18705] Fix typos/spelling mistakes in Lib/*.py files
In-Reply-To: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>
Message-ID: <1376690876.37.0.447850262721.issue18705@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm not spelling expert Antoine. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18705>
_______________________________________

From report at bugs.python.org  Sat Aug 17 00:23:55 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 22:23:55 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
Message-ID: <1376691835.07.0.666456900735.issue18763@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Currently, when passed close_fds=True, the subprocess module closes FDs before calling preexec_fn (if provided). This can be an issue if preexec_fn opens some file descriptors, which would then be inherited in the child process.
Here's a patch with test.

----------
components: Library (Lib)
keywords: needs review, patch
messages: 195434
nosy: gregory.p.smith, neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: subprocess: file descriptors should be closed after preexec_fn is called
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Sat Aug 17 00:25:34 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 22:25:34 +0000
Subject: [issue16463] testConnectTimeout of test_timeout
 TCPTimeoutTestCasefailures fails intermittently
In-Reply-To: <1352757217.25.0.912881014186.issue16463@psf.upfronthosting.co.za>
Message-ID: <1376691934.98.0.306624301485.issue16463@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Should be fixed now!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16463>
_______________________________________

From report at bugs.python.org  Sat Aug 17 00:53:36 2013
From: report at bugs.python.org (Lenard Lindstrom)
Date: Fri, 16 Aug 2013 22:53:36 +0000
Subject: [issue13797] Allow objects implemented in pure Python to export PEP
 3118 buffers
In-Reply-To: <1326709751.32.0.965094376059.issue13797@psf.upfronthosting.co.za>
Message-ID: <1376693616.56.0.00933742700547.issue13797@psf.upfronthosting.co.za>


Lenard Lindstrom added the comment:

A fourth way to add __getbuffer__ and __releasebuffer__ special methods to a Python class is through a new base class/mixin. The Py_buffer struct pointer passed to __getbuffer__ and __releasebuffer__ is wrapped with another special object type, which exposes the C struct fields as attributes. The base class is a direct subclass of object. Both the base and wrapper classes are implemented in an extension module. 

The use case is unit testing. A memoryview object may be adequate for simple C-contiguous arrays, but fails with F-contiguous or any non-contiguous array. It cannot export any arbitrary view, especially a deliberately invalid view, useful for testing error handlers.

My implementation is at https://bitbucket.org/llindstrom/newbuffer . It is used in Pygame 1.9.2 unit tests: https://bitbucket.org/pygame/pygame . The newbuffer module exports two classes, BufferMixin and Py_buffer. The BufferMixin class adds bf_getbuffer and bf_releasebuffer slot functions to base class PyObject, nothing more. The Py_buffer class is low level, exposing pointer fields as integer addresses. It is designed for use with ctypes and is modelled on ctypes.Structure.

Some limitations. In a class declaration, BufferMixin must be first in the inheritance list for the subclass to inherit the PEP 3118 interface. A buffer interface cannot be added to a builtin.

I suggest this is a practical alternative to the three previously proposed solutions to this issue. This option takes its precedence from the ctypes module, which adds dangerous memory level access to Python, but optionally. It does not require modification of the base code, only an addition to the standard library. Finally, this approach has been demonstrated in a real-world application.

----------
nosy: +kermode
Added file: http://bugs.python.org/file31329/llindstrom-newbuffer-0dd8ba1c2c2c.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13797>
_______________________________________

From report at bugs.python.org  Sat Aug 17 01:00:26 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 23:00:26 +0000
Subject: [issue18760] Fix internal doc references for the xml package
In-Reply-To: <1376681899.06.0.47911099673.issue18760@psf.upfronthosting.co.za>
Message-ID: <1376694026.07.0.479229363299.issue18760@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18760>
_______________________________________

From report at bugs.python.org  Sat Aug 17 01:05:23 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Aug 2013 23:05:23 +0000
Subject: [issue18758] Fix internal references in the documentation
In-Reply-To: <1376678338.7.0.979265810368.issue18758@psf.upfronthosting.co.za>
Message-ID: <1376694323.91.0.207622183004.issue18758@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

That's probably not worth it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18758>
_______________________________________

From report at bugs.python.org  Sat Aug 17 01:11:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Aug 2013 23:11:12 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <3cH0dW3hD0zSv7@mail.python.org>


Roundup Robot added the comment:

New changeset c9f073e593b0 by Christian Heimes in branch '3.3':
Issue #18709: Fix CVE-2013-4238. The SSL module now handles NULL bytes
http://hg.python.org/cpython/rev/c9f073e593b0

New changeset 7a0f398d1a5c by Christian Heimes in branch 'default':
Issue #18709: Fix CVE-2013-4238. The SSL module now handles NULL bytes
http://hg.python.org/cpython/rev/7a0f398d1a5c

New changeset bd2360476bdb by Christian Heimes in branch '2.7':
Issue #18709: Fix CVE-2013-4238. The SSL module now handles NULL bytes
http://hg.python.org/cpython/rev/bd2360476bdb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Sat Aug 17 01:16:30 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Aug 2013 23:16:30 +0000
Subject: [issue18764] The pdb print command prints repr instead of str in
 python3
Message-ID: <1376694990.04.0.946395407142.issue18764@psf.upfronthosting.co.za>


New submission from R. David Murray:

In 2.7:

>>> import pdb
>>> from email import message_from_string as m
>>> x = m("To: me\nfrom: you\n\ntest\n")
>>> pdb.set_trace()
--Return--
> <stdin>(1)<module>()->None
(Pdb) print x
>From nobody Fri Aug 16 19:06:58 2013
To: me
from: you

test


In 3.4:

>>> import pdb
>>> from email import message_from_string as m
>>> x = m("To: me\nfrom: you\n\ntest\n")
>>> pdb.set_trace()
--Return--
> <stdin>(1)<module>()->None
(Pdb) print x
<email.message.Message object at 0xb707b92c>


Since the print command masks the print function, it is difficult (though
not impossible) to actually get the print representation of something:

(Pdb) print(str(x))
'To: me\nfrom: you\n\ntest\n'
(Pdb) not print(x)
To: me
from: you

test

True


Because print is a function rather than a statement in python3, it might be better to just drop the print command from pdb.  Someone working in Python3 is likely to type "print(...)" at the python3 pdb command line and expect it to work like the print function.

----------
components: Library (Lib)
keywords: easy
messages: 195439
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: The pdb print command prints repr instead of str in python3
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18764>
_______________________________________

From report at bugs.python.org  Sat Aug 17 01:22:25 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Aug 2013 23:22:25 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376695345.03.0.571531564533.issue18709@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I have applied the patch to 2.7, 3.3 and 3.4.

Barry, Benjamin, Georg:
Are you going to apply the patches yourselves?

----------
nosy: +benjamin.peterson, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Sat Aug 17 01:22:54 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Aug 2013 23:22:54 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376695374.1.0.741597565212.issue18709@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


Added file: http://bugs.python.org/file31330/CVE-2013-4238-py31.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Sat Aug 17 01:25:16 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Aug 2013 23:25:16 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1376695516.43.0.850098341073.issue18709@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


Added file: http://bugs.python.org/file31331/CVE-2013-4238-py32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Sat Aug 17 01:34:51 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 16 Aug 2013 23:34:51 +0000
Subject: [issue18759] Fix internal doc references for logging package
In-Reply-To: <1376680954.66.0.549191685954.issue18759@psf.upfronthosting.co.za>
Message-ID: <1376696091.73.0.959854793839.issue18759@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee: docs at python -> vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18759>
_______________________________________

From report at bugs.python.org  Sat Aug 17 01:36:25 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 16 Aug 2013 23:36:25 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1376696185.6.0.160437455997.issue18720@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Charles-Fran?ois: unfortunately, the alternative seems to be even more tedious and error prone. Internally, socketmodule.c really uses ints all over the place. Changing that to use IntEnum objects from Python would be very tedious and touch a lot more code.

Christian - I think that practically none. None of the touched places seems like a performance concern (even without realizing that these are sockets and *network operations* we're talking about here)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Sat Aug 17 01:37:03 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 16 Aug 2013 23:37:03 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1376691835.07.0.666456900735.issue18763@psf.upfronthosting.co.za>
Message-ID: <1376696223.73.0.411079841076.issue18763@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I don't see a patch attached, but I do not recall any good reason off the top of my head for preexec_fn to be called as late as it is.  Moving it up to be called before the fd closing loop makes sense as a bug fix.

All bets are off when it comes to safe behavior for preexec_fn users anyways. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Sat Aug 17 01:40:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Aug 2013 23:40:56 +0000
Subject: [issue18759] Fix internal doc references for logging package
In-Reply-To: <1376680954.66.0.549191685954.issue18759@psf.upfronthosting.co.za>
Message-ID: <3cH1Hr10ktzRTR@mail.python.org>


Roundup Robot added the comment:

New changeset aea67c35e3ce by Vinay Sajip in branch '2.7':
Issue #18759: Improved cross-references in logging documentation.
http://hg.python.org/cpython/rev/aea67c35e3ce

New changeset 80c475617608 by Vinay Sajip in branch '3.3':
Issue #18759: Improved cross-references in logging documentation.
http://hg.python.org/cpython/rev/80c475617608

New changeset 9580f237139f by Vinay Sajip in branch 'default':
Issue #18759: Merged updates from 3.3.
http://hg.python.org/cpython/rev/9580f237139f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18759>
_______________________________________

From report at bugs.python.org  Sat Aug 17 01:45:52 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 16 Aug 2013 23:45:52 +0000
Subject: [issue18765] unittest needs a way to launch pdb.post_mortem or other
 debug hooks
Message-ID: <1376696752.64.0.473845221037.issue18765@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

A few times now I've seen people write something that overrides and re-implements the unittest.TestCase run() method, copying most of the implementation but adding one feature:

The ability for pdb.post_mortem() to be called after every phase of execution iff an exception/error was caught (setUp(), the testMethod() call itself and tearDown()).

I really hate seeing people have to copy the run method implementation and modify it.

We could support this either by adding another debugHook() method to the TestCase API.  Proposal: it gets called within the except: clause surrounding each phase of test execution.

Turning on support for automatic pdb.post_mortem(), typically controlled via a flag or other environment configurable as it isn't desirable during automation:

  def debugHook(self):
    if SOMETHING_SAYS_TO_ENABLE_THIS:
      pdb.post_mortem()

no more copy and pasting the run() method.

----------
components: Library (Lib)
messages: 195444
nosy: gregory.p.smith, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest needs a way to launch pdb.post_mortem or other debug hooks
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18765>
_______________________________________

From report at bugs.python.org  Sat Aug 17 02:52:01 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 17 Aug 2013 00:52:01 +0000
Subject: [issue18706] test failure in test_codeccallbacks
In-Reply-To: <1376179395.42.0.0457635695026.issue18706@psf.upfronthosting.co.za>
Message-ID: <1376700721.07.0.52481823238.issue18706@psf.upfronthosting.co.za>


Eric Snow added the comment:

Regarding this:

>>> def f():
...     import html.entities
...     del sys.modules['html']
...
>>> f()
>>> import html.entities
>>> html.entities
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'entities'

This is due to the fact that the code to add the submodule to the package's namespace is associated with the import of the submodule, not the parent (aka, package).  So the import after calling f() happily bypasses all that since the submodule already exists in sys.modules.

skip loading the module: 

http://hg.python.org/cpython/file/default/Lib/importlib/_bootstrap.py#l1612

bind the submodule to the parent:

http://hg.python.org/cpython/file/default/Lib/importlib/_bootstrap.py#l1568

I wouldn't necessarily say the import machinery is acting weird.  Directly messing with sys.modules, particularly for submodules, isn't something the rest of the import code explicitly accommodates (outside of loaders).  In this case the code doing the removing needs to make sure submodules are removed too.

If anybody thinks we should support this sort of interaction with sys.modules then we could address it in another issue.  Outside of testing, what are the use cases for removing modules from sys.modules?  Regardless, a solution might be as simple as moving the parent-binding code in _find_and_load_unlocked() to _gcd_import().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18706>
_______________________________________

From report at bugs.python.org  Sat Aug 17 03:39:46 2013
From: report at bugs.python.org (Phil Webster)
Date: Sat, 17 Aug 2013 01:39:46 +0000
Subject: [issue18766] IDLE: Autocomplete in editor doesn't work for
 un-imported modules
Message-ID: <1376703586.47.0.0617094548794.issue18766@psf.upfronthosting.co.za>


New submission from Phil Webster:

If you open a new editor window in IDLE, some modules will autocomplete (re, os, other common modules used by IDLE) and others will not (textwrap, datetime, ...). The current solution is to run your module or type the imports into the shell window to get completions working, which is not very intuitive. I created a patch that checks the namespace and attempts to import the module automatically if it is not found.

----------
components: IDLE
files: autocomplete_unimported_1.patch
keywords: patch
messages: 195446
nosy: Todd.Rovito, philwebster, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Autocomplete in editor doesn't work for un-imported modules
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file31332/autocomplete_unimported_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18766>
_______________________________________

From report at bugs.python.org  Sat Aug 17 04:06:37 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 17 Aug 2013 02:06:37 +0000
Subject: [issue18745] Test enum in test_json is ignorant of infinity value
In-Reply-To: <1376553540.47.0.197538167938.issue18745@psf.upfronthosting.co.za>
Message-ID: <1376705197.8.0.984359964646.issue18745@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Tests look good to me.

----------
nosy: +barry, eli.bendersky
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18745>
_______________________________________

From report at bugs.python.org  Sat Aug 17 04:24:13 2013
From: report at bugs.python.org (Brian McLaughlin)
Date: Sat, 17 Aug 2013 02:24:13 +0000
Subject: [issue18767] csv documentation does not note default quote constant
Message-ID: <1376706253.43.0.482794872786.issue18767@psf.upfronthosting.co.za>


New submission from Brian McLaughlin:

Documentation should note default quoting behavior of the csv module is csv.QUOTE_MINIMAL

http://hg.python.org/cpython/file/tip/Modules/_csv.c#l420

----------
assignee: docs at python
components: Documentation
files: doc.patch
keywords: patch
messages: 195448
nosy: bemclaugh, docs at python
priority: normal
severity: normal
status: open
title: csv documentation does not note default quote constant
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31333/doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18767>
_______________________________________

From report at bugs.python.org  Sat Aug 17 08:06:57 2013
From: report at bugs.python.org (Simon Charette)
Date: Sat, 17 Aug 2013 06:06:57 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1376719617.96.0.0967935267878.issue11798@psf.upfronthosting.co.za>


Changes by Simon Charette <charette.s at gmail.com>:


----------
nosy: +charettes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sat Aug 17 08:48:40 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 17 Aug 2013 06:48:40 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376722120.58.0.589992938776.issue18606@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

To anyone waiting for me to respond to rietveld reviews, I'm trying, I really am, but I keep getting a django traceback.

This seems to have been reported before, three months ago:

http://psf.upfronthosting.co.za/roundup/meta/issue517

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Sat Aug 17 09:46:46 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Aug 2013 07:46:46 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376685944.35.0.830122744909.issue18756@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa0nKMj7VdzChB+ug_yZ8L86TRRWdgY3toSgm1700nJ3Q@mail.gmail.com>


STINNER Victor added the comment:

Tarek: try to use ssl.RAND_bytes(), it is secure, fast and don't use a file
descriptor.

IMO if something can be improved, it is in the random.SystemRandom() class:
it can keep the FD open. Does the class have a method to generate random
bytes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Sat Aug 17 09:55:01 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 17 Aug 2013 07:55:01 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376726101.58.0.364501057625.issue18712@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Just mentioning it here again, but "type(a).__index__(a)" is still not perfectly correct.  Attached is a case where it differs.

I think you get always the correct answer by evaluating "range(a).stop".  It's admittedly obscure...  For example:

    class A:
        def __index__(self):
            return -42**100

    a = A()
    print(range(a).stop)

----------
nosy: +arigo
Added file: http://bugs.python.org/file31334/x.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sat Aug 17 10:04:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Aug 2013 08:04:20 +0000
Subject: [issue18767] csv documentation does not note default quote constant
In-Reply-To: <1376706253.43.0.482794872786.issue18767@psf.upfronthosting.co.za>
Message-ID: <1376726660.2.0.220192868034.issue18767@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, it does say that QUOTE_MINIMAL is the default for the dialect 'quoting' attribute.  What it doesn't say is that the default dialect (excel) is exactly the documented default values for all the dialect parameters.  (Although having said that, I'm not 100% sure it is true, I didn't fully check the correspondence).

----------
nosy: +r.david.murray
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18767>
_______________________________________

From report at bugs.python.org  Sat Aug 17 10:17:12 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 17 Aug 2013 08:17:12 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1376727432.64.0.545596034198.issue18756@psf.upfronthosting.co.za>


Donald Stufft added the comment:

haypo: It's been suggested by a number of security professionals that using the OpenSSL random (or really any random) instead of urandom is likely to be a smarter idea. The likelyhood that urandom is broken is far less than any other source of random. This can be seen in the recent issues on the Android platform. This is not to say that there's a reason to believe that OpenSSL is broken currently, but that the chances are higher for it to be than /dev/urandom. An example of when this happened was http://www.debian.org/security/2008/dsa-1571.

There's no reason to believe that OpenSSL is wrong right now, but the chances of OpenSSL being wrong are greater than the chances of /dev/urandom being

There's been a few threads on twitter about it in light of the Android SecureRandom issue (don't need to read these, just here for reference):
    - https://twitter.com/tqbf/status/368089082800246784
    - https://twitter.com/tqbf/status/367793231808843777
    - https://twitter.com/tqbf/status/368089362333827072



I don't think it actually matters if os.urandom or random.SystemRandom is the preferred interface that keeps the FD open but I do believe there should be one implementation that will use the OS source of random and maintain a persistent FD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Sat Aug 17 10:29:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Aug 2013 08:29:29 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376728169.75.0.347056637401.issue18712@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The difference doesn't look significant. In all cases the TypeError is raised.

But there was other differences between C and Python versions -- when __index__() returns non-integer. Updated patch fixes this.

----------
Added file: http://bugs.python.org/file31335/operator_index_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sat Aug 17 11:40:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Aug 2013 09:40:25 +0000
Subject: [issue18702] Report skipped tests as skipped
In-Reply-To: <1376132966.91.0.713996712724.issue18702@psf.upfronthosting.co.za>
Message-ID: <1376732425.55.0.119801155464.issue18702@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm not sure I understand you Rietveld comment right Terry.

We can get rid of _have_ssl (this is implementation detail and shouldn't be required) and just try import ssl.

try:
    import ssl
except ImportError:
    ssl = None

If ssl is not None but nntplib.NNTP_SSL doesn't exist the NetworkedNNTP_SSLTests tests will failed:

======================================================================
ERROR: setUpClass (test.test_nntplib.NetworkedNNTP_SSLTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_nntplib.py", line 298, in setUpClass
    cls.server = cls.NNTP_CLASS(cls.NNTP_HOST, timeout=TIMEOUT, usenetrc=False)
TypeError: 'NoneType' object is not callable

----------------------------------------------------------------------

This doesn't different from a case when some exception is raised in NNTP_SSL constructor.

We can add a separate test in MiscTests:

    @unittest.skipUnless(ssl, 'requires SSL support')
    def test_ssl_support(self):
        self.assertTrue(hasattr(nntplib, 'NNTP_SSL'))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18702>
_______________________________________

From report at bugs.python.org  Sat Aug 17 11:58:24 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Sat, 17 Aug 2013 09:58:24 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
 iterable)
In-Reply-To: <1376675096.92.0.0483806559999.issue18652@psf.upfronthosting.co.za>
Message-ID: <7010638E-1BD8-4DCA-BD6C-B6135709A9FB@ox.cx>


Hynek Schlawack added the comment:

Well that's the point: it's extremely handy but simple.  I wish Raymond would pronounce on this.  I can keep using the PyPI version for all I care, so I'm not going fight for it.  But with one exception there seems to be an agreement that it would be a very fine thing to have.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18652>
_______________________________________

From report at bugs.python.org  Sat Aug 17 12:23:06 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Aug 2013 10:23:06 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376734986.15.0.486296664524.issue18712@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Just mentioning it here again, but "type(a).__index__(a)" is still not perfectly correct.

Hmm.  "type(a).__dict__['__index__'](a)" ?  (With suitable error checks, as in Serhiy's patch.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sat Aug 17 12:33:54 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 17 Aug 2013 10:33:54 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376735634.96.0.670357226439.issue18712@psf.upfronthosting.co.za>


Armin Rigo added the comment:

> The difference doesn't look significant. In all cases the TypeError is raised.

Ok, so here is another case.  (I won't go to great lengths trying to convince you that there is a problem, because the discussion already occurred several times; google for example for "_PyType_Lookup pure Python")

----------
Added file: http://bugs.python.org/file31336/y.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sat Aug 17 14:27:06 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Aug 2013 12:27:06 +0000
Subject: [issue18702] Report skipped tests as skipped
In-Reply-To: <1376132966.91.0.713996712724.issue18702@psf.upfronthosting.co.za>
Message-ID: <1376742426.87.0.402561775862.issue18702@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

You changed "NNTP_CLASS = nntplib.NNTP_SSL", which could potentially fail, to "NNTP_CLASS = getattr(nntplib, 'NNTP_SSL', None)", which cannot fail.  Since that was the only thing that previously could fail, the change leaves nothing that can fail, so the test is not a test.

I suggested that you either not add the third param, a default, or that you remove the null test completely. If particular, if the only chunk of code in nntplib that is currently being tested is being executed by some other test, then do the latter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18702>
_______________________________________

From report at bugs.python.org  Sat Aug 17 14:54:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Aug 2013 12:54:29 +0000
Subject: [issue18705] Fix typos/spelling mistakes in Lib/*.py files
In-Reply-To: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>
Message-ID: <3cHLvS6pB7z7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset d234dd21374a by Ezio Melotti in branch '2.7':
#18705: fix a number of typos.  Patch by F?vry Thibault.
http://hg.python.org/cpython/rev/d234dd21374a

New changeset e07f104133d5 by Ezio Melotti in branch '3.3':
#18705: fix a number of typos.  Patch by F?vry Thibault.
http://hg.python.org/cpython/rev/e07f104133d5

New changeset a9ee869cae40 by Ezio Melotti in branch 'default':
#18705: merge with 3.3.
http://hg.python.org/cpython/rev/a9ee869cae40

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18705>
_______________________________________

From report at bugs.python.org  Sat Aug 17 14:56:22 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 12:56:22 +0000
Subject: [issue18705] Fix typos/spelling mistakes in Lib/*.py files
In-Reply-To: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>
Message-ID: <1376744182.3.0.358430856146.issue18705@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18705>
_______________________________________

From report at bugs.python.org  Sat Aug 17 15:03:10 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Aug 2013 13:03:10 +0000
Subject: [issue18178] Redefinition of malloc(3) family of functions at build
 time
In-Reply-To: <1370851878.25.0.593003779218.issue18178@psf.upfronthosting.co.za>
Message-ID: <3cHM5V24H9zR65@mail.python.org>


Roundup Robot added the comment:

New changeset f09ca52747a6 by Christian Heimes in branch '3.3':
Issue #18178: Fix ctypes on BSD. dlmalloc.c was compiled twice which broke malloc weak symbols.
http://hg.python.org/cpython/rev/f09ca52747a6

New changeset bea2f12e899e by Christian Heimes in branch 'default':
Issue #18178: Fix ctypes on BSD. dlmalloc.c was compiled twice which broke malloc weak symbols.
http://hg.python.org/cpython/rev/bea2f12e899e

New changeset d4ac6eee7061 by Christian Heimes in branch '2.7':
Issue #18178: Fix ctypes on BSD. dlmalloc.c was compiled twice which broke malloc weak symbols.
http://hg.python.org/cpython/rev/d4ac6eee7061

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18178>
_______________________________________

From report at bugs.python.org  Sat Aug 17 15:14:24 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Aug 2013 13:14:24 +0000
Subject: [issue18741] Fix typos/spelling mistakes in Lib/*/*/.py files
In-Reply-To: <1376515284.41.0.228001908428.issue18741@psf.upfronthosting.co.za>
Message-ID: <3cHMLS0MXkz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 5295ed192ffd by Ezio Melotti in branch '2.7':
#18741: fix more typos.  Patch by F?vry Thibault.
http://hg.python.org/cpython/rev/5295ed192ffd

New changeset 9e4685d703d4 by Ezio Melotti in branch '3.3':
#18741: fix more typos.  Patch by F?vry Thibault.
http://hg.python.org/cpython/rev/9e4685d703d4

New changeset b3236989f869 by Ezio Melotti in branch 'default':
#18741: merge with 3.3.
http://hg.python.org/cpython/rev/b3236989f869

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18741>
_______________________________________

From report at bugs.python.org  Sat Aug 17 15:15:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 13:15:15 +0000
Subject: [issue18741] Fix typos/spelling mistakes in Lib/*/*/.py files
In-Reply-To: <1376515284.41.0.228001908428.issue18741@psf.upfronthosting.co.za>
Message-ID: <1376745315.45.0.959097837756.issue18741@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18741>
_______________________________________

From report at bugs.python.org  Sat Aug 17 15:19:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 13:19:18 +0000
Subject: [issue18466] Spelling mistakes in various code comments.
In-Reply-To: <1373909571.44.0.949892598858.issue18466@psf.upfronthosting.co.za>
Message-ID: <1376745558.05.0.807898738551.issue18466@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

F?vry, do you want to make an updated patch that includes also "everytime" as suggested by Terry?
I think some of the typos of the current patch have also been fixed by the other patches you submitted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18466>
_______________________________________

From report at bugs.python.org  Sat Aug 17 15:21:58 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 13:21:58 +0000
Subject: [issue18764] The pdb print command prints repr instead of str in
 python3
In-Reply-To: <1376694990.04.0.946395407142.issue18764@psf.upfronthosting.co.za>
Message-ID: <1376745718.61.0.909491885202.issue18764@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, georg.brandl
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18764>
_______________________________________

From report at bugs.python.org  Sat Aug 17 15:24:47 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 13:24:47 +0000
Subject: [issue18759] Fix internal doc references for logging package
In-Reply-To: <1376680954.66.0.549191685954.issue18759@psf.upfronthosting.co.za>
Message-ID: <1376745887.77.0.107476473084.issue18759@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18759>
_______________________________________

From report at bugs.python.org  Sat Aug 17 15:38:16 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Sat, 17 Aug 2013 13:38:16 +0000
Subject: [issue18466] Spelling mistakes in various code comments.
In-Reply-To: <1373909571.44.0.949892598858.issue18466@psf.upfronthosting.co.za>
Message-ID: <1376746696.95.0.178242784532.issue18466@psf.upfronthosting.co.za>


F?vry Thibault added the comment:

Updated the patch.

----------
Added file: http://bugs.python.org/file31337/typos.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18466>
_______________________________________

From report at bugs.python.org  Sat Aug 17 15:58:54 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Aug 2013 13:58:54 +0000
Subject: [issue18466] Spelling mistakes in various code comments.
In-Reply-To: <1373909571.44.0.949892598858.issue18466@psf.upfronthosting.co.za>
Message-ID: <3cHNKL6p2zzS32@mail.python.org>


Roundup Robot added the comment:

New changeset c75b8d5fa016 by Ezio Melotti in branch '2.7':
#18466: fix more typos.  Patch by F?vry Thibault.
http://hg.python.org/cpython/rev/c75b8d5fa016

New changeset 61227b4c169f by Ezio Melotti in branch '3.3':
#18466: fix more typos.  Patch by F?vry Thibault.
http://hg.python.org/cpython/rev/61227b4c169f

New changeset 4cc308acd26d by Ezio Melotti in branch 'default':
#18466: merge with 3.3.
http://hg.python.org/cpython/rev/4cc308acd26d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18466>
_______________________________________

From report at bugs.python.org  Sat Aug 17 15:59:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 13:59:25 +0000
Subject: [issue18466] Spelling mistakes in various code comments.
In-Reply-To: <1373909571.44.0.949892598858.issue18466@psf.upfronthosting.co.za>
Message-ID: <1376747965.83.0.340643618885.issue18466@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18466>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:08:04 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:08:04 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
 when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1376748484.85.0.38109503097.issue18730@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> test needed
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18730>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:08:52 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:08:52 +0000
Subject: [issue13107] Text width in optparse.py can become negative
In-Reply-To: <1317812903.38.0.572106699519.issue13107@psf.upfronthosting.co.za>
Message-ID: <1376748532.07.0.798813526685.issue13107@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
stage: needs patch -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13107>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:10:23 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:10:23 +0000
Subject: [issue9882] abspath from directory
In-Reply-To: <1284682917.39.0.650396347526.issue9882@psf.upfronthosting.co.za>
Message-ID: <1376748623.12.0.328972955114.issue9882@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Was this brought up on python-ideas?  If so, what was the outcome?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9882>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:13:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:13:13 +0000
Subject: [issue15248] Better explain "TypeError: 'tuple' object is not
 callable"
In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>
Message-ID: <1376748792.99.0.437095633806.issue15248@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15248>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:14:23 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:14:23 +0000
Subject: [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1376748863.45.0.600388234822.issue6916@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

What's the status of this?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6916>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:15:21 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:15:21 +0000
Subject: [issue12866] Want to submit our Audioop.c patch for 24bit audio
In-Reply-To: <1314744712.67.0.770855933698.issue12866@psf.upfronthosting.co.za>
Message-ID: <1376748921.27.0.197366961527.issue12866@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

What's the status of this?

----------
nosy: +ezio.melotti
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12866>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:19:06 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:19:06 +0000
Subject: [issue9741] msgfmt.py generates invalid mo because msgfmt.make() does
 not clear dictionary
In-Reply-To: <1283437902.68.0.344684434437.issue9741@psf.upfronthosting.co.za>
Message-ID: <1376749146.64.0.153452093592.issue9741@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

FWIW now we have Lib/test/test_tools.py.

----------
nosy: +ezio.melotti
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9741>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:22:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:22:29 +0000
Subject: [issue10654] test_datetime sometimes fails on Python3.x windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1376749349.19.0.333403855707.issue10654@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Is this still an issue?

----------
nosy: +ezio.melotti
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:25:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Aug 2013 14:25:35 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376749535.75.0.0262570341731.issue18712@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Hmm.  "type(a).__dict__['__index__'](a)" ?

This variant fails on:

    class A(int):
        @staticmethod
        def __index__():
            return 42

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:26:40 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:26:40 +0000
Subject: [issue12913] Add a debugging howto
In-Reply-To: <1315323088.65.0.459623812563.issue12913@psf.upfronthosting.co.za>
Message-ID: <1376749600.8.0.0298262477943.issue12913@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
type:  -> enhancement
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12913>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:30:38 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:30:38 +0000
Subject: [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1376749838.49.0.473443027545.issue17232@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Terry, do you want to update your patch?

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17232>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:35:15 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 17 Aug 2013 14:35:15 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376750115.61.0.664986104491.issue18712@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Serhiy:  Yep, or even on bool.  Thanks.

Armin: I don't think either of us thinks there isn't a problem here. :-)
The Google search you suggested didn't turn up a whole lot of useful information for me.  Was there a discussion of this on python-dev at some point?  (And if not, should there be?)

For this *particular* issue, it seems we can't exactly reproduce.  type(a).__index__(a) seems like the best practical approximation to the true behaviour.  I'm guessing that it's fairly rare to have useful definitions of __index__ on a metaclass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:39:11 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:39:11 +0000
Subject: [issue5720] ctime: I don't think that word means what you think it
 means.
In-Reply-To: <1239141469.77.0.706973197517.issue5720@psf.upfronthosting.co.za>
Message-ID: <1376750351.87.0.0355659632412.issue5720@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

What was the outcome?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5720>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:52:08 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:52:08 +0000
Subject: [issue16699] Mountain Lion buildbot lacks disk space
In-Reply-To: <1355675210.52.0.0088069164146.issue16699@psf.upfronthosting.co.za>
Message-ID: <1376751128.47.0.874726123556.issue16699@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
type:  -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16699>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:53:04 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:53:04 +0000
Subject: [issue13924] Mercurial robots.txt should let robots crawl landing
 pages.
In-Reply-To: <1328135396.1.0.0965106732225.issue13924@psf.upfronthosting.co.za>
Message-ID: <1376751184.3.0.0506003279689.issue13924@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13924>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:53:53 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 17 Aug 2013 14:53:53 +0000
Subject: [issue18626] Make "python -m inspect <name>" meaningful
In-Reply-To: <1375413160.45.0.218073630788.issue18626@psf.upfronthosting.co.za>
Message-ID: <1376751233.97.0.624927544586.issue18626@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I realised that with the "module:qualname" syntax, it's straightforward to expand this beyond module introspection to arbitrary objects.

What I suggest we could output:

- a header with key module info (names taken from PEP 451):
    Origin
    Cached
    Submodule search path
    Loader (repr output)

- for non-module objects, also include the line within the file (if it can be determined)

- the output of getsource() if a "--source" option is given

----------
title: Make "python -m inspect <name>" dump the source of a module -> Make "python -m inspect <name>" meaningful

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18626>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:58:26 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:58:26 +0000
Subject: [issue13822] is(upper/lower/title) are not exactly correct
In-Reply-To: <1326946975.13.0.733756833132.issue13822@psf.upfronthosting.co.za>
Message-ID: <1376751506.01.0.759610096075.issue13822@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13822>
_______________________________________

From report at bugs.python.org  Sat Aug 17 16:59:48 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 14:59:48 +0000
Subject: [issue12985] Check signed arithmetic overflow in ./configure
In-Reply-To: <1316079277.71.0.960663177072.issue12985@psf.upfronthosting.co.za>
Message-ID: <1376751588.85.0.0635980957207.issue12985@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.4 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12985>
_______________________________________

From report at bugs.python.org  Sat Aug 17 17:02:20 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 15:02:20 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <1376751740.97.0.112719975125.issue18553@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Are there tests for this?

----------
components: +Tests
keywords: +easy
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18553>
_______________________________________

From report at bugs.python.org  Sat Aug 17 17:06:04 2013
From: report at bugs.python.org (James Sanders)
Date: Sat, 17 Aug 2013 15:06:04 +0000
Subject: [issue5527] multiprocessing won't work with Tkinter (under Linux)
In-Reply-To: <1237574081.02.0.0677822756927.issue5527@psf.upfronthosting.co.za>
Message-ID: <1376751964.04.0.0494701782456.issue5527@psf.upfronthosting.co.za>


James Sanders added the comment:

I did a bit more digging and I think I've worked out what is going on.  The particular bit of tcl initialization code that triggers the problem if it is run before the fork is Tcl_InitNotifier in tclUnixNotify.c.  It turns out there is a known problem with this bit of tcl not being process-safe if tcl was built with threading support (this is discussed at https://bugs.archlinux.org/task/16401, for example).

The bug doesn't show up in my 8.5 builds as threading support is off by default, though the debian/ubuntu packages apparently have it switched on.  Threading was turned on by default in 8.6, but a recent change to tclUnixNotify.c (discussed at https://issues.apache.org/bugzilla/show_bug.cgi?id=55153#c13 - it should be included in 8.6.1 and 8.5.15) appears to have fixed the whole problem anyway.

So hopefully the bug should disappear entirely in future releases of tcl, but for now you can work around it by building tcl without threads, calling exec in between the fork and any use of tkinter in the child process, or not importing tkinter until after the fork.  I don't know if there should be a note about this somewhere in the tkinter docs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5527>
_______________________________________

From report at bugs.python.org  Sat Aug 17 17:13:29 2013
From: report at bugs.python.org (koobs)
Date: Sat, 17 Aug 2013 15:13:29 +0000
Subject: [issue18762] error in test_multiprocessing_forkserver
In-Reply-To: <1376684380.66.0.0393627862698.issue18762@psf.upfronthosting.co.za>
Message-ID: <1376752409.83.0.101876276379.issue18762@psf.upfronthosting.co.za>


koobs added the comment:

2 more cases seen here:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/227/steps/test/logs/stdio

Note: cc on FreeBSD 10.0-CURRENT is clang

and here:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%2Bclang%203.x/builds/1825/steps/test/logs/stdio

----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18762>
_______________________________________

From report at bugs.python.org  Sat Aug 17 17:15:39 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 17 Aug 2013 15:15:39 +0000
Subject: [issue18768] Wrong documentation of RAND_egd function in ssl module
Message-ID: <1376752539.41.0.731008742763.issue18768@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

>>> import ssl
>>> ssl.RAND_egd.__doc__
"RAND_egd(path) -> bytes\n\nQueries the entropy gather daemon (EGD) on the socket named by 'path'.\nReturns number of bytes read.  Raises SSLError if connection to EGD\nfails or if it does provide enough data to seed PRNG."

Compare it to documentation about RAND_egd() function from openssl website (https://www.openssl.org/docs/crypto/RAND_egd.html):

RAND_egd() and RAND_egd_bytes() return the number of bytes read from the daemon on success, and -1 if the connection failed or the daemon did not return enough data to fully seed the PRNG. 

Attached the patch to fix the documentation. I am not sure whether we should put the word "fully" or not.

On the side note:
In line 813 in Modules/_ssl.c (the same file where my patch fixed the documentation about RAND_egd function):

gntype = name-> type;

The space between "->" and "type" irritates my eyes. Maybe we can fix this while we fix the documentation? Anyway, this is not really important. I just want to expose it to public and think this does not deserve a dedicated ticket.

----------
assignee: docs at python
components: Documentation
files: fix_documentation_on_rand_egd_function.patch
keywords: patch
messages: 195482
nosy: christian.heimes, docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Wrong documentation of RAND_egd function in ssl module
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31338/fix_documentation_on_rand_egd_function.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18768>
_______________________________________

From report at bugs.python.org  Sat Aug 17 17:15:58 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 15:15:58 +0000
Subject: [issue15939] make *.rst files in Doc/ parseable by doctest
In-Reply-To: <1347543698.43.0.179468389771.issue15939@psf.upfronthosting.co.za>
Message-ID: <1376752558.87.0.826149338106.issue15939@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
type:  -> enhancement
versions:  -Python 3.2
Added file: http://bugs.python.org/file31339/issue15939-ctypes-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15939>
_______________________________________

From report at bugs.python.org  Sat Aug 17 17:19:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Aug 2013 15:19:53 +0000
Subject: [issue18768] Wrong documentation of RAND_egd function in ssl module
In-Reply-To: <1376752539.41.0.731008742763.issue18768@psf.upfronthosting.co.za>
Message-ID: <3cHQ7F1tJdz7Lk7@mail.python.org>


Roundup Robot added the comment:

New changeset b352a5cb60b6 by Christian Heimes in branch '3.3':
Issue #18768: coding style nitpick. Thanks to Vajrasky Kok
http://hg.python.org/cpython/rev/b352a5cb60b6

New changeset fe444f324756 by Christian Heimes in branch 'default':
Issue #18768: coding style nitpick. Thanks to Vajrasky Kok
http://hg.python.org/cpython/rev/fe444f324756

New changeset a8787a6fa107 by Christian Heimes in branch '2.7':
Issue #18768: coding style nitpick. Thanks to Vajrasky Kok
http://hg.python.org/cpython/rev/a8787a6fa107

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18768>
_______________________________________

From report at bugs.python.org  Sat Aug 17 17:20:58 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 17 Aug 2013 15:20:58 +0000
Subject: [issue18768] Wrong documentation of RAND_egd function in ssl module
In-Reply-To: <1376752539.41.0.731008742763.issue18768@psf.upfronthosting.co.za>
Message-ID: <1376752858.88.0.282009683953.issue18768@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks, I have removed the extra space in gntype = name-> type;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18768>
_______________________________________

From report at bugs.python.org  Sat Aug 17 17:26:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Aug 2013 15:26:16 +0000
Subject: [issue18768] Wrong documentation of RAND_egd function in ssl module
In-Reply-To: <1376752539.41.0.731008742763.issue18768@psf.upfronthosting.co.za>
Message-ID: <3cHQGc1rR8zT2B@mail.python.org>


Roundup Robot added the comment:

New changeset ae91252943bf by Christian Heimes in branch '3.3':
Issue 18768: Correct doc string of RAND_edg(). Patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/ae91252943bf

New changeset 5c091acc799f by Christian Heimes in branch 'default':
Issue 18768: Correct doc string of RAND_edg(). Patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/5c091acc799f

New changeset 31389495cdbf by Christian Heimes in branch '2.7':
Issue 18768: Correct doc string of RAND_edg(). Patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/31389495cdbf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18768>
_______________________________________

From report at bugs.python.org  Sat Aug 17 17:27:17 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 17 Aug 2013 15:27:17 +0000
Subject: [issue18768] Wrong documentation of RAND_egd function in ssl module
In-Reply-To: <1376752539.41.0.731008742763.issue18768@psf.upfronthosting.co.za>
Message-ID: <1376753237.81.0.287540821809.issue18768@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks :)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18768>
_______________________________________

From report at bugs.python.org  Sat Aug 17 17:34:27 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 17 Aug 2013 15:34:27 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1376753667.06.0.348496037441.issue2516@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2516>
_______________________________________

From report at bugs.python.org  Sat Aug 17 17:39:18 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 17 Aug 2013 15:39:18 +0000
Subject: [issue2506] Add mechanism to disable optimizations
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1376753958.51.0.707222628681.issue2506@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2506>
_______________________________________

From report at bugs.python.org  Sat Aug 17 17:43:15 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 17 Aug 2013 15:43:15 +0000
Subject: [issue11671] Security hole in wsgiref.headers.Headers
In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za>
Message-ID: <1376754195.08.0.678140351916.issue11671@psf.upfronthosting.co.za>


Christian Heimes added the comment:

What do the RFCs for RFC-822 and HTTP 1.1 say about \r and \n in header names?

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11671>
_______________________________________

From report at bugs.python.org  Sat Aug 17 18:07:19 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 17 Aug 2013 16:07:19 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1376755639.21.0.821775534503.issue18747@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Here is a patch that is based on Apache's mod_ssl code. mod_ssl perturbs the PRNG state more often but I think that's overkill for Python.

The new patch only affects the PRNG state of the child process. In my opinion it is the better way to solve this issue. The RAND API does some internal locking. Bad things might happen if one thread of a process calls fork() while another is in the middle of a locked RAND operation.

----------
Added file: http://bugs.python.org/file31340/openssl_prng_atfork3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Sat Aug 17 18:08:21 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 17 Aug 2013 16:08:21 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376755701.77.0.859829649998.issue18712@psf.upfronthosting.co.za>


Armin Rigo added the comment:

This may have been the most recent discussion of this idea (as far as I can tell):
http://mail.python.org/pipermail//python-ideas/2012-August/016036.html

Basically, it seems to be still unresolved in the trunk Python; sorry, I thought by now it would have been resolved e.g. by the addition of a method on types or a function in the operator module.  In the absence of either, you need either to simulate its behavior by doing this:

    for t in type(a).__mro__:
        if '__index__' in t.__dict__:
            return t.__dict__['__index__'](a)

Or you can piggyback on an unrelated call that simply causes the C-level PyNumber_Index() to be called:

    return range(a).stop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sat Aug 17 18:12:23 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 17 Aug 2013 16:12:23 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376755943.08.0.713689462343.issue18712@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Sorry, realized that my pure Python algorithm isn't equivalent to _PyType_Lookup() --- it fails the staticmethod example of Serhiy.  A closer one would be:

    for t in type(a).__mro__:
        if '__index__' in t.__dict__:
            return t.__dict__['__index__'].__get__(a)()

But it's still not a perfect match.  I think right now the only "perfect" answer is given by workarounds like "range(a).stop"...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sat Aug 17 18:14:17 2013
From: report at bugs.python.org (Devin Cook)
Date: Sat, 17 Aug 2013 16:14:17 +0000
Subject: [issue11671] Security hole in wsgiref.headers.Headers
In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za>
Message-ID: <1376756057.0.0.860449383379.issue11671@psf.upfronthosting.co.za>


Devin Cook added the comment:

It looks like it's allowed for header line continuation.

http://www.ietf.org/rfc/rfc2616.txt

HTTP/1.1 header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear
white space, including folding, has the same semantics as SP. A
recipient MAY replace any linear white space with a single SP before
interpreting the field value or forwarding the message downstream.

...

A CRLF is allowed in the definition of TEXT only as part of a header
field continuation. It is expected that the folding LWS will be
replaced with a single SP before interpretation of the TEXT value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11671>
_______________________________________

From report at bugs.python.org  Sat Aug 17 18:25:02 2013
From: report at bugs.python.org (koobs)
Date: Sat, 17 Aug 2013 16:25:02 +0000
Subject: [issue18746] test_threading.test_finalize_with_trace() fails on
 FreeBSD buildbot
In-Reply-To: <1376561660.51.0.498019291184.issue18746@psf.upfronthosting.co.za>
Message-ID: <1376756702.58.0.478030911834.issue18746@psf.upfronthosting.co.za>


koobs added the comment:

I'm not sure if this issue is/was related, but it seems the commit addressing #18178 has taken care of the test_finalize_runnning_thread failure.

I note that your description specifies test_finalize_"with_trace", perhaps suggesting your reproduction case may be something slightly different?

FWIW, I don't think I've seen the 'with_trace' test fail on my buildbots (but correct me if I'm wrong)

After the commit mentioned above, the FreeBSD 10 buildbot is now green on all branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18746>
_______________________________________

From report at bugs.python.org  Sat Aug 17 18:29:23 2013
From: report at bugs.python.org (koobs)
Date: Sat, 17 Aug 2013 16:29:23 +0000
Subject: [issue18178] Redefinition of malloc(3) family of functions at build
 time
In-Reply-To: <1370851878.25.0.593003779218.issue18178@psf.upfronthosting.co.za>
Message-ID: <1376756963.35.0.276875842522.issue18178@psf.upfronthosting.co.za>


koobs added the comment:

Commit looks good, confirming test suite passing for 3.x, 3.3 and 2.7.on http://buildbot.python.org/all/buildslaves/koobs-freebsd10

Thank you for picking this up and finishing it off Christian.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18178>
_______________________________________

From report at bugs.python.org  Sat Aug 17 18:30:40 2013
From: report at bugs.python.org (Michael Bikovitsky)
Date: Sat, 17 Aug 2013 16:30:40 +0000
Subject: [issue18769] argparse remove subparser
Message-ID: <1376757040.66.0.700111900917.issue18769@psf.upfronthosting.co.za>


New submission from Michael Bikovitsky:

It might be useful in some circumstances to be able to remove a subparser, however the module does not provide such functionality.

The proposed method takes the same arguments as the add_parser method and removes the matching subparser from the map (including aliases).

----------
components: Library (Lib)
files: argparse_remove_parser.patch
keywords: patch
messages: 195494
nosy: Michael.Bikovitsky, bethard
priority: normal
severity: normal
status: open
title: argparse remove subparser
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31341/argparse_remove_parser.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18769>
_______________________________________

From report at bugs.python.org  Sat Aug 17 19:10:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Aug 2013 17:10:44 +0000
Subject: [issue12866] Want to submit our Audioop.c patch for 24bit audio
In-Reply-To: <1314744712.67.0.770855933698.issue12866@psf.upfronthosting.co.za>
Message-ID: <1376759444.69.0.655106063974.issue12866@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12866>
_______________________________________

From report at bugs.python.org  Sat Aug 17 19:21:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Aug 2013 17:21:45 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
 when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1376760105.98.0.86785742041.issue18730@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

>>> import tempfile
>>> f = tempfile.NamedTemporaryFile(suffix='$')
>>> f.name
'/tmp/tmpumyks8ju$'

I see an effect.

----------
nosy: +serhiy.storchaka
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18730>
_______________________________________

From report at bugs.python.org  Sat Aug 17 19:45:08 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 17:45:08 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
 when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1376761508.83.0.0868923024538.issue18730@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Works for me on Linux too (all branches, with different types of suffix).
Maybe it's a Windows issue?

----------
nosy: +terry.reedy
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18730>
_______________________________________

From report at bugs.python.org  Sat Aug 17 19:45:36 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 17:45:36 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
 when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1376761536.45.0.652829422631.issue18730@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18730>
_______________________________________

From report at bugs.python.org  Sat Aug 17 20:03:06 2013
From: report at bugs.python.org (Vivek Ratnaparkhi)
Date: Sat, 17 Aug 2013 18:03:06 +0000
Subject: [issue18770] Python insert operation on list
Message-ID: <1376762586.13.0.388208537821.issue18770@psf.upfronthosting.co.za>


New submission from Vivek Ratnaparkhi:

Example 1:

mylist = ['a','b','c','d','e']
mylist.insert(len(mylist),'f')
print(mylist)

Output: ['a', 'b', 'c', 'd', 'e', 'f']

Example 2:

mylist = ['a','b','c','d','e']
mylist.insert(10,'f')
print(mylist)

Output: ['a', 'b', 'c', 'd', 'e', 'f']

Why should mylist.insert(len(mylist), x) be equivalent to mylist.insert(len(mylist)+1000000000, x)

Excepted Output: Should give index error.

----------
messages: 195497
nosy: vivek.ratnaparkhi
priority: normal
severity: normal
status: open
title: Python insert operation on list
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18770>
_______________________________________

From report at bugs.python.org  Sat Aug 17 20:07:50 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 18:07:50 +0000
Subject: [issue18770] Python insert operation on list
In-Reply-To: <1376762586.13.0.388208537821.issue18770@psf.upfronthosting.co.za>
Message-ID: <1376762870.25.0.807988713643.issue18770@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The docs say that:
  l.insert(pos, val)
is equivalent to:
  l[pos:pos] = [val]
The docstring also says that the value is inserted before pos, so .insert is working as documented.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18770>
_______________________________________

From report at bugs.python.org  Sat Aug 17 20:20:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Aug 2013 18:20:43 +0000
Subject: [issue17810] Implement PEP 3154 (pickle protocol 4)
In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za>
Message-ID: <1376763643.97.0.51130184476.issue17810@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Alexandre, Stefan, is any of you working on this?
If not, could you please expose what the status of the patch is, whose work is the most advanced (Alexandre's or Stefan's) and what should be the plan to move this forward?

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17810>
_______________________________________

From report at bugs.python.org  Sat Aug 17 20:21:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Aug 2013 18:21:58 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1376763718.19.0.498294790613.issue18747@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The patch looks fine on the principle, but you should add a test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Sat Aug 17 20:30:20 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Aug 2013 18:30:20 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376755639.21.0.821775534503.issue18747@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2=_xoFQPE2SrVjYbM9AGki7aRSyA_yFsDkMtpBRb8xNg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

2013/8/17 Christian Heimes <report at bugs.python.org>:
> Here is a patch that is based on Apache's mod_ssl code. mod_ssl perturbs the PRNG state more often but I think that's overkill for Python.
>
> The new patch only affects the PRNG state of the child process. In my opinion it is the better way to solve this issue. The RAND API does some internal locking. Bad things might happen if one thread of a process calls fork() while another is in the middle of a locked RAND operation.

Ouch, this would mean making the interpreter prone to deadlock/crash
(since the atfork hook is not async-signal safe) :-\

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Sat Aug 17 20:33:11 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Aug 2013 18:33:11 +0000
Subject: [issue16105] Pass read only FD to signal.set_wakeup_fd
In-Reply-To: <1349125559.77.0.651840030069.issue16105@psf.upfronthosting.co.za>
Message-ID: <3cHVQG3xtWzQPM@mail.python.org>


Roundup Robot added the comment:

New changeset e2b234f5bf7d by Antoine Pitrou in branch 'default':
Issue #16105: When a signal handler fails to write to the file descriptor registered with ``signal.set_wakeup_fd()``, report an exception instead of ignoring the error.
http://hg.python.org/cpython/rev/e2b234f5bf7d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16105>
_______________________________________

From report at bugs.python.org  Sat Aug 17 20:54:06 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Aug 2013 18:54:06 +0000
Subject: [issue10654] test_datetime sometimes fails on Python3.x windows binary
In-Reply-To: <1291822652.75.0.279703972848.issue10654@psf.upfronthosting.co.za>
Message-ID: <1376765646.23.0.97438749364.issue10654@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

test_datetime passes on current 3.3 and 3.4.
datetimetest.py now gives the same answer for all 4 classes

unsupported operand type(s) for +: 'SubPy' and 'int'
unsupported operand type(s) for +: 'int' and 'SubPy'
NotImplemented NotImplemented NotImplemented NotImplemented

whereas the first line for the two subclasses was previously NotImplemented. I presume the above is the correct behavior, so closing.

----------
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10654>
_______________________________________

From report at bugs.python.org  Sat Aug 17 20:55:52 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Aug 2013 18:55:52 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1376696223.73.0.411079841076.issue18763@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0+3oMVRu_CQz_3Xk4Wg7eC=+80ok7g5zjgid+mdy2gUg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

With patch :)

----------
Added file: http://bugs.python.org/file31342/subprocess_close.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________
-------------- next part --------------
diff -r 5d4fe1da2c90 Lib/test/test_subprocess.py
--- a/Lib/test/test_subprocess.py	Fri Aug 16 23:19:56 2013 +0200
+++ b/Lib/test/test_subprocess.py	Sat Aug 17 20:53:01 2013 +0200
@@ -1972,6 +1972,19 @@
         self.assertRaises(OSError, os.waitpid, pid, 0)
         self.assertNotIn(ident, [id(o) for o in subprocess._active])
 
+    def test_close_fds_after_preexec(self):
+        fd_status = support.findfile("fd_status.py", subdir="subprocessdata")
+
+        # FDs created by preexec_fn should be closed in the child
+        p = subprocess.Popen([sys.executable, fd_status],
+                             stdout=subprocess.PIPE, close_fds=True,
+                             preexec_fn=os.pipe)
+        output, ignored = p.communicate()
+
+        remaining_fds = set(map(int, output.split(b',')))
+
+        self.assertTrue(remaining_fds <= set([0, 1, 2]))
+
 
 @unittest.skipUnless(mswindows, "Windows specific tests")
 class Win32ProcessTestCase(BaseTestCase):
diff -r 5d4fe1da2c90 Modules/_posixsubprocess.c
--- a/Modules/_posixsubprocess.c	Fri Aug 16 23:19:56 2013 +0200
+++ b/Modules/_posixsubprocess.c	Sat Aug 17 20:53:01 2013 +0200
@@ -412,17 +412,6 @@
         POSIX_CALL(close(errwrite));
     }
 
-    if (close_fds) {
-        int local_max_fd = max_fd;
-#if defined(__NetBSD__)
-        local_max_fd = fcntl(0, F_MAXFD);
-        if (local_max_fd < 0)
-            local_max_fd = max_fd;
-#endif
-        /* TODO HP-UX could use pstat_getproc() if anyone cares about it. */
-        _close_open_fd_range(3, local_max_fd, py_fds_to_keep);
-    }
-
     if (cwd)
         POSIX_CALL(chdir(cwd));
 
@@ -451,6 +440,18 @@
         /* Py_DECREF(result); - We're about to exec so why bother? */
     }
 
+    /* close FDs after executing preexec_fn, which might open FDs */
+    if (close_fds) {
+        int local_max_fd = max_fd;
+#if defined(__NetBSD__)
+        local_max_fd = fcntl(0, F_MAXFD);
+        if (local_max_fd < 0)
+            local_max_fd = max_fd;
+#endif
+        /* TODO HP-UX could use pstat_getproc() if anyone cares about it. */
+        _close_open_fd_range(3, local_max_fd, py_fds_to_keep);
+    }
+
     /* This loop matches the Lib/os.py _execvpe()'s PATH search when */
     /* given the executable_list generated by Lib/subprocess.py.     */
     saved_errno = 0;

From report at bugs.python.org  Sat Aug 17 20:57:52 2013
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Sat, 17 Aug 2013 18:57:52 +0000
Subject: [issue18748] libgcc_s.so.1 must be installed for pthread_cancel to
 work
In-Reply-To: <1376658678.46.0.641669212909.issue18748@psf.upfronthosting.co.za>
Message-ID: <CANkHFr_13ANzfAu2aNt1igH_Czx9nQO=L4g2UOvSv7psy4_rpg@mail.gmail.com>


Maries Ionel Cristian added the comment:

> What is the version of your libc library? Try something like "dpkg -l
> libc6".
>

 2.15-0ubuntu10.4

I don't think it's that obscure ... uwsgi has this issue
https://www.google.com/search?q=libgcc_s.so.1+must+be+installed+for+pthread_cancel+to+work+uwsgi+site:lists.unbit.it-
they cause it probably different but the point is that it's not
obscure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18748>
_______________________________________

From report at bugs.python.org  Sat Aug 17 20:57:58 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Aug 2013 18:57:58 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
Message-ID: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

I'm working on a patch for the lookkey() functions in Object/setobject.c.  The core idea is to follow the probe sequence as usual but to also check an adjacent entry for each probe (i.e. check &table[i & mask] as usual and then check &table[(i & mask) ^ 1] before going on the next probes which are scattered around memory).

On modern processors (anything in the last decade), this is likely to reduce the cost of hash collisions and reduce the number of cache lines fetched from memory.

+ Cache line benefit:  improves the odds that the adjacent probe will be on the same cache line, thereby reducing the total number of cache lines fetched.  This benefit will work for set insertions as well as set lookups (a partial write to a cache line requires that a full cache line be read prior to writing, so it is helpful if we've just examined another slot on the same cache line).

+ Parallel execution:  because the second lookup has no data dependency on the first lookup, some of its instructions can be executed in parallel by the out-of-order engine.

+ Reduced loop overhead:  the second lookup doesn't require a new computation of the index *i* (we just do a XOR 1), a new perturb shift, a new masking of *i*, or a jump to the top of the loop.  In other words, it has all the usual benefits of loop unrolling.

- On the downside, even this partial unrolling when increase the total code size which has the negative effect of blowing other code out of the I-cache (typically 32kb).

? I'm unsure whether the additional if-statements will have a net positive or net negative effect on branch prediction rates (positive because each branch can be tracked separately or negative because additional branches use up more space in the branch prediction tables).  Once the patch is ready, I'll run CacheGrind to get a better sense of what is happening.

----------
components: Interpreter Core
messages: 195506
nosy: haypo, rhettinger
priority: normal
severity: normal
status: open
title: Reduce the cost of hash collisions for set objects
type: performance
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sat Aug 17 20:59:05 2013
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Sat, 17 Aug 2013 18:59:05 +0000
Subject: [issue18748] libgcc_s.so.1 must be installed for pthread_cancel to
 work
In-Reply-To: <1376572242.37.0.931026549367.issue18748@psf.upfronthosting.co.za>
Message-ID: <1376765945.1.0.976448255456.issue18748@psf.upfronthosting.co.za>


Maries Ionel Cristian added the comment:

Correct link https://www.google.com/search?q=libgcc_s.so.1+must+be+installed+for+pthread_cancel+to+work+uwsgi+site:lists.unbit.it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18748>
_______________________________________

From report at bugs.python.org  Sat Aug 17 21:16:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Aug 2013 19:16:39 +0000
Subject: [issue16105] Pass read only FD to signal.set_wakeup_fd
In-Reply-To: <1349125559.77.0.651840030069.issue16105@psf.upfronthosting.co.za>
Message-ID: <1376766998.99.0.15817648254.issue16105@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, I pushed the patch to 3.4. Thanks for the report!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16105>
_______________________________________

From report at bugs.python.org  Sat Aug 17 21:17:23 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 17 Aug 2013 19:17:23 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376767043.77.0.170222952949.issue18771@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sat Aug 17 21:18:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Aug 2013 19:18:11 +0000
Subject: [issue18772] Fix test_gdb for new sets dummy object
Message-ID: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Changeset 2c9a2b588a89 broke the pretty-printing of sets by the gdb plugin.
Here is a temptative patch. It works, but I don't know enough to know whether that's the right coding style for a gdb plugin. Dave?

----------
components: Demos and Tools, Interpreter Core
files: gdb_sets_repr.patch
keywords: patch
messages: 195509
nosy: larry, pitrou
priority: release blocker
severity: normal
stage: patch review
status: open
title: Fix test_gdb for new sets dummy object
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31343/gdb_sets_repr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Sat Aug 17 21:18:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Aug 2013 19:18:25 +0000
Subject: [issue18772] Fix test_gdb for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1376767105.92.0.694838058162.issue18772@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +dmalcolm, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Sat Aug 17 21:22:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Aug 2013 19:22:04 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376767324.31.0.449910394716.issue18712@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is updated patch which uses Armin's algorithm for lookup special methods and adds special case for int subclasses in index().

I have no idea how the documentation should look.

----------
Added file: http://bugs.python.org/file31344/operator_index_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sat Aug 17 21:22:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Aug 2013 19:22:35 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1376767355.03.0.795669502196.issue18772@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
title: Fix test_gdb for new sets dummy object -> Fix gdb plugin for new sets dummy object

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Sat Aug 17 21:28:15 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 17 Aug 2013 19:28:15 +0000
Subject: [issue18770] Python insert operation on list
In-Reply-To: <1376762586.13.0.388208537821.issue18770@psf.upfronthosting.co.za>
Message-ID: <1376767695.32.0.290531865875.issue18770@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18770>
_______________________________________

From report at bugs.python.org  Sat Aug 17 21:33:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Aug 2013 19:33:34 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376768014.51.0.366842172739.issue18771@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

How it will affect a performance of set(range(n))?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sat Aug 17 21:35:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Aug 2013 19:35:55 +0000
Subject: [issue5527] multiprocessing won't work with Tkinter (under Linux)
In-Reply-To: <1237574081.02.0.0677822756927.issue5527@psf.upfronthosting.co.za>
Message-ID: <1376768155.15.0.251647378331.issue5527@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5527>
_______________________________________

From report at bugs.python.org  Sat Aug 17 21:44:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Aug 2013 19:44:37 +0000
Subject: [issue18702] Report skipped tests as skipped
In-Reply-To: <1376132966.91.0.713996712724.issue18702@psf.upfronthosting.co.za>
Message-ID: <1376768677.13.0.859042288961.issue18702@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> You changed "NNTP_CLASS = nntplib.NNTP_SSL", which could potentially fail, to "NNTP_CLASS = getattr(nntplib, 'NNTP_SSL', None)", which cannot fail.  Since that was the only thing that previously could fail, the change leaves nothing that can fail, so the test is not a test.

This statement is not a part of a test. It runs at module import time. As you said in msg194907 the failing here will prohibit the running of all tests (even not SSL related).

> I suggested that you either not add the third param, a default,

getattr(nntplib, 'NNTP_SSL') is same as nntplib.NNTP_SSL. And it will break all tests.

> or that you remove the null test completely.

The purpose of this issue is stopping silence skipping tests. If some tests skipped for some reasons it should be reported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18702>
_______________________________________

From report at bugs.python.org  Sat Aug 17 21:49:09 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 17 Aug 2013 19:49:09 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376768949.7.0.758056043899.issue18712@psf.upfronthosting.co.za>


Eric Snow added the comment:

Couldn't you make use of inspect.getattr_static()?

  getattr_static(obj.__class__, '__index__').__get__(obj)()

getattr_static() does some extra work to get do the right lookup.  I haven't verified that it matches _PyType_Lookup() exactly, but it should be pretty close at least.

Also, pickle (unfortunately) also does lookup on instances rather than classes for the special methods (issue #16251).

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sat Aug 17 21:58:42 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Aug 2013 19:58:42 +0000
Subject: [issue18770] Python insert operation on list
In-Reply-To: <1376762586.13.0.388208537821.issue18770@psf.upfronthosting.co.za>
Message-ID: <1376769522.17.0.248039943118.issue18770@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18770>
_______________________________________

From report at bugs.python.org  Sat Aug 17 21:59:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Aug 2013 19:59:20 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
 when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1376769560.06.0.268568233103.issue18730@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

'Filename extensions' are a proper subset of 'suffixes'.
https://en.wikipedia.org/wiki/Filename_extension
Dan 'solutions' indicates that he thinks that the two sets are or should be the same, which they are not. The only thing that is DOS/Windows specific is its more special treatment of '.'.  That said, I can see how a Windows user might be confused by the following awkward sentence.

    If 'suffix' is specified, the file name will end with that suffix,
    otherwise there will be no suffix.

as 'no suffix' is easily read as 'no extension. The manual, but not the docstring, addresses the possible confusion by adding

  mkstemp() does not put a dot between the file name and the suffix;
  if you need one, put it at the beginning of suffix.

I think the prefix sentence is also a bit awkward.

    If 'prefix' is specified, the file name will begin with that prefix,
    otherwise a default prefix is used.

I think both parameters should be explained in both docstring and doc with one shorter and clearer entry.

"The file name will begin with *prefix* (default 'tmp') and end with *suffix* (default ''). The is no automatic addition of a period ('.') before the suffix."

----------
stage: test needed -> needs patch
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18730>
_______________________________________

From report at bugs.python.org  Sat Aug 17 22:10:12 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Aug 2013 20:10:12 +0000
Subject: [issue18702] Report skipped tests as skipped
In-Reply-To: <1376132966.91.0.713996712724.issue18702@psf.upfronthosting.co.za>
Message-ID: <1376770212.78.0.00932090828722.issue18702@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

My original suggestion was to put the possibly failing assignment inside
  @classmethod
  def setUpClass:
    NNTP_CLASS = nntplib.NNTP_SSL
so that failure of the assignment would be be reported, but not affect import.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18702>
_______________________________________

From report at bugs.python.org  Sat Aug 17 22:25:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Aug 2013 20:25:41 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
 when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1376771141.66.0.975549576982.issue18730@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't think any explanation is needed. A docstring should be short, we can't duplicate a manual in it.

The mentioning suffix default is redundant because it already exposed in the function signature. The mentioning prefix default adds duplication. The purpose of introducing of the template attribute is get rid of such duplication.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18730>
_______________________________________

From report at bugs.python.org  Sat Aug 17 22:32:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Aug 2013 20:32:36 +0000
Subject: [issue18702] Report skipped tests as skipped
In-Reply-To: <1376132966.91.0.713996712724.issue18702@psf.upfronthosting.co.za>
Message-ID: <1376771556.38.0.190672012541.issue18702@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually you should call parent's setUpClass at the and of declared setUpClass. Therefore you need 4 nontrivial lines instead of 1. The test will fail in setUpClass() in any case because parent's setUpClass() uses NNTP_CLASS. There are no behavior difference between this variants, the variant with getattr just is shorter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18702>
_______________________________________

From report at bugs.python.org  Sat Aug 17 22:49:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Aug 2013 20:49:20 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
 when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1376772560.1.0.339419505387.issue18730@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

It would be fine with me to shorten the suggestion and not repeat the defaults. They are currently in both doc and docstring, but with *more* words than I used.

"The file name will begin with *prefix* and end with *suffix*. There is no automatic addition of a period ('.') before the suffix."

The explanation of . is already in the doc in a wordier form (too wordy in my view). The above is much shorter than what is currently in the docstring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18730>
_______________________________________

From report at bugs.python.org  Sat Aug 17 22:56:43 2013
From: report at bugs.python.org (Michael Foord)
Date: Sat, 17 Aug 2013 20:56:43 +0000
Subject: [issue18765] unittest needs a way to launch pdb.post_mortem or other
 debug hooks
In-Reply-To: <1376696752.64.0.473845221037.issue18765@psf.upfronthosting.co.za>
Message-ID: <1376773003.65.0.882782596062.issue18765@psf.upfronthosting.co.za>


Michael Foord added the comment:

This is done in outcome.testPartExecutor. If you add it in the except clause then it is *only* called on test failure or error. If we call it unconditionally with the result (maybe a sys.exc_info tuple?) then it could have extended use cases (perhaps custom reporting)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18765>
_______________________________________

From report at bugs.python.org  Sat Aug 17 22:57:49 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Aug 2013 20:57:49 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376773069.42.0.446816891349.issue18771@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31345/so.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sat Aug 17 23:11:13 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Aug 2013 21:11:13 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376773873.26.0.896329041842.issue18771@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Serhiy, I've posted a patch so you can examine the effects in detail.

For something like set(range(n)), I would expect no change because the dataset is collision free due to Tim's design where hash(someint)==someint.  That said, I'm trying to optimize the general case and don't really if rare cases are modestly slowed.

The new code only kicks in when there is a collision.  The logic for the initial probe is unchanged.   The idea is to pickup some of the cache locality benefits of collision resolution by separate chaining, but not incurring the 100% malloc typically associated with chaining.

When adjacent entries are in the same cache-line, the cost of the extra adjacent probe is much cheaper (nearly zero) than a probe somewhere else in memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sat Aug 17 23:54:28 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Aug 2013 21:54:28 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <CAH_1eM2=_xoFQPE2SrVjYbM9AGki7aRSyA_yFsDkMtpBRb8xNg@mail.gmail.com>
Message-ID: <CAMpsgwYCBf5G_QbYok90UMRgUMM8kZ0ti32XaRs-FWZ2SoPamQ@mail.gmail.com>


STINNER Victor added the comment:

openssl_prng_atfork3.patch: Why not using seconds (only micro or
nanoseconds) in the seed? Add a few more bits should not reduce the
entropy. OpenSSL does hash all these bytes anyway.

+#if 1
+    fprintf(stderr, "PySSL_RAND_atfork_child() seeds %i bytes in %i\n",
+            (int)sizeof(seed), seed.pid);
+#endif

This should be removed from the final patch ;-)

The patch is specific to pthread. Do we need something similar on
Windows. Windows has no fork, but I don't know if OpenSSL CPRNG state
can be inherited somehow? Does Python support other platforms (other
than pthread or Windows)?

Instead of using pthread_atfork(), we can add an hook in the Python
binding of OpenSSL checking the pid. I don't know which functions
should be modified. ssl.RAND_bytes() is probably not enough :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Sat Aug 17 23:58:59 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 17 Aug 2013 21:58:59 +0000
Subject: [issue17810] Implement PEP 3154 (pickle protocol 4)
In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za>
Message-ID: <1376776739.06.0.647100321402.issue17810@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Potentially relevant to this: we hope to have PEP 451 done for 3.4, which adds a __spec__ attribute to module objects, and will also tweak runpy to ensure -m registers __main__ under it's real name as well.

If pickle uses __spec__.name in preference to __name__ when __spec__ is defined, then objects defined in __main__ modules run via -m should start being pickled correctly.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17810>
_______________________________________

From report at bugs.python.org  Sat Aug 17 23:59:09 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Aug 2013 21:59:09 +0000
Subject: [issue18748] libgcc_s.so.1 must be installed for pthread_cancel to
 work
In-Reply-To: <CANkHFr_13ANzfAu2aNt1igH_Czx9nQO=L4g2UOvSv7psy4_rpg@mail.gmail.com>
Message-ID: <CAMpsgwaU+XzHqJinOOT8cbUQXeVZQr+r=RW+3PSUTXjZZW9+ZQ@mail.gmail.com>


STINNER Victor added the comment:

2013/8/17 Maries Ionel Cristian <report at bugs.python.org>:
> I don't think it's that obscure ... uwsgi has this issue
> https://www.google.com/search?q=libgcc_s.so.1+must+be+installed+for+pthread_cancel+to+work+uwsgi+site:lists.unbit.it-
> they cause it probably different but the point is that it's not
> obscure.

The error message is maybe the same, the reason is completly different:
http://lists.unbit.it/pipermail/uwsgi/2013-July/006213.html
"IT WAS A limit-as issue"

The root cause is an arbitrary limit on the size of the virtual memory.

Here the bug is that a thread B closes a file descriptor opened in a
thread B by the glibc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18748>
_______________________________________

From report at bugs.python.org  Sun Aug 18 00:04:29 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Aug 2013 22:04:29 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376773873.26.0.896329041842.issue18771@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbR_x7z2ipGRXThBRJOaMY2yHmaEJ5shhYyzCd8wu_K3w@mail.gmail.com>


STINNER Victor added the comment:

Do you expect visible difference on a microbenchmark? Do you have
benchmarks showing the speedup and showing that many collisions are no
too much slower?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 00:22:21 2013
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Sat, 17 Aug 2013 22:22:21 +0000
Subject: [issue18748] libgcc_s.so.1 must be installed for pthread_cancel to
 work
In-Reply-To: <1376572242.37.0.931026549367.issue18748@psf.upfronthosting.co.za>
Message-ID: <1376778141.25.0.344803209478.issue18748@psf.upfronthosting.co.za>


Maries Ionel Cristian added the comment:

Well anyway, is there any way to preload libgcc ? Because in python2.x it wasn't loaded at runtime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18748>
_______________________________________

From report at bugs.python.org  Sun Aug 18 00:41:01 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Aug 2013 22:41:01 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376779261.42.0.0504467004809.issue18771@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I just made the patch a few minutes ago.  Am just starting to work on benchmarks.  I posted here so that you guys could help find the strengths and weaknesses of the approach.  

The theory is sound, but it is going to take a good deal of effort to isolate the effects (either good or bad) in realistic benchmarks.  The short, tight loops in timeit tend to put everything in cache and hide the effects  of good memory access patterns.

If would love to have you all team up with me on this one.  I could use help on timings, examining disassembly, and runs with cache grind.

This is just in the experimental phase, so it is premature to be throwing up obstacles with "show me your data" or "what does it do in situatation x".  At this point, you all could help out by running some timings designed to isolate the effects on high collision data big enough to not fit in  L2 cache.  I hope you assist in evaluating the idea with an open mind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 00:44:04 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Aug 2013 22:44:04 +0000
Subject: [issue18748] libgcc_s.so.1 must be installed for pthread_cancel to
 work
In-Reply-To: <1376778141.25.0.344803209478.issue18748@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbwXq-MiMH06hgK3CycstMOcSNp+jLo0oaVbUgFwCkA3A@mail.gmail.com>


STINNER Victor added the comment:

2013/8/18 Maries Ionel Cristian <report at bugs.python.org>:
> Well anyway, is there any way to preload libgcc ? Because in python2.x it wasn't loaded at runtime.

On Linux, you can try to set the LD_PRELOAD environment variable as a
workaround.

LD_PRELOAD=libgcc_s.so.1 python bug.py

You may need to specify the full path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18748>
_______________________________________

From report at bugs.python.org  Sun Aug 18 00:44:09 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Aug 2013 22:44:09 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376779449.61.0.0158703404615.issue18771@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 00:49:35 2013
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Sat, 17 Aug 2013 22:49:35 +0000
Subject: [issue18748] libgcc_s.so.1 must be installed for pthread_cancel to
 work
In-Reply-To: <1376572242.37.0.931026549367.issue18748@psf.upfronthosting.co.za>
Message-ID: <1376779775.49.0.359014157207.issue18748@psf.upfronthosting.co.za>


Maries Ionel Cristian added the comment:

Alright ... would it be a very big hack to preload libgcc in the thread module (at import time) ? There is platform specific code there anyway, it wouldn't be such a big deal would it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18748>
_______________________________________

From report at bugs.python.org  Sun Aug 18 00:52:25 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Aug 2013 22:52:25 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376779449.65.0.748437048917.issue18771@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaBtv9oDqxvUfzvyxcw040DNhovU8NvebM3wZAxUP+T2w@mail.gmail.com>


STINNER Victor added the comment:

> The theory is sound, but it is going to take a good deal of effort to isolate the effects (either good or bad) in realistic benchmarks.

Oh, it was just asking for a microbenchmark on set(). I don't care of
a "real" benchmark (realistic use case) for such issue :-)

I asked because I don't understand all these complex things of the CPU
(cache size, data dependency, prefetch, ...), whereas I can compare
number of a microbenchmark :-) And I can try to reproduce it on a
different CPU and a different dataset. Because I don't understand
low-level CPU things, I always fear that a patch works well on a
specific CPU whereas it would behave badly on a completly different
CPU architecture (ex: RISC vs CISC).

All your arguments sound good and I'm always happy to see people
involved to optimize Python!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 01:07:08 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Aug 2013 23:07:08 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376780828.1.0.317249472154.issue18771@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Here's an excerpt of the patch that gives a pretty good idea of that is being changed (there are essentially three lines of new logic):

static void
set_insert_clean(PySetObject *so, PyObject *key, Py_hash_t hash)
{
    setentry *table = so->table;
    setentry *entry;
    size_t perturb = hash;
    size_t mask = (size_t)so->mask;
    size_t i, j;                        // the j variable is new
    i = j = (size_t)hash & mask;
    while(1) {
        entry = &table[j];
        if (entry->key == NULL)
            break;
        entry = &table[j ^ 1];          // this line is new
        if (entry->key == NULL)         // this line is new
            break;                      // this line new
        i = i * 5 + perturb + 1;
        j = i & mask;
        perturb >>= PERTURB_SHIFT;
    }
    so->fill++;
    entry->key = key;
    entry->hash = hash;
    so->used++;
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 01:07:44 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Aug 2013 23:07:44 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376780864.01.0.865662479653.issue18771@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: http://bugs.python.org/msg195530

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 01:08:40 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Aug 2013 23:08:40 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376780920.98.0.616505973936.issue18771@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Here's an excerpt from the patch that gives a pretty good idea of what is being changed (the three lines of new logic are marked):

static void
set_insert_clean(PySetObject *so, PyObject *key, Py_hash_t hash)
{
    setentry *table = so->table;
    setentry *entry;
    size_t perturb = hash;
    size_t mask = (size_t)so->mask;
    size_t i, j;                        // the j variable is new
    i = j = (size_t)hash & mask;
    while(1) {
        entry = &table[j];
        if (entry->key == NULL)
            break;
        entry = &table[j ^ 1];          // this line is new
        if (entry->key == NULL)         // this line is new
            break;                      // this line new
        i = i * 5 + perturb + 1;
        j = i & mask;
        perturb >>= PERTURB_SHIFT;
    }
    so->fill++;
    entry->key = key;
    entry->hash = hash;
    so->used++;
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 01:28:55 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Aug 2013 23:28:55 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376780920.98.0.616505973936.issue18771@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbn=8pssCPMNRFdKY3gadWrhUUG4Y6CirW5cN3h2WJwzQ@mail.gmail.com>


STINNER Victor added the comment:

"+ Cache line benefit:  improves the odds that the adjacent probe will
be on the same cache line (...)
+ Reduced loop overhead:  the second lookup doesn't require a new
computation of the index *i* (we just do a XOR 1) (...)"

With j=11, is the lookup at index 10 in the same cache line? Does a
cache line start at the address of the first lookup, or is it
"rounded" to the size of a cache line?

I read that CPU likes to prefetch data forward, but I didn't know that
they like prefetching backward.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 02:04:58 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Aug 2013 00:04:58 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376784298.98.0.878896620348.issue18771@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> With j=11, is the lookup at index 10 in the same cache line?

It might or it might not.  The cache lines are typically 64 bytes which holds 4 key/hash pairs.  So, the odds are 75% in favor of an adjacent entry being in the same cache line.

If malloc where guaranteed to return 64-byte aligned memory blocks, the odds would be 100%, but my understanding is that 16-byte alignment is the norm.

> I read that CPU likes to prefetch data forward, 
> but I didn't know that they like prefetching backward.

The integrated memory controller can also prefetch backwards, but that won't help us.  The prefetching doesn't start until you've done a series of monotonically increasing or decreasing accesses.  There is no prefetch on the first probe regardless of whether you're going up or down.

The whole problem with large sets is that the data is scattered all over memory and is unlikely to be in cache or to benefit from prefetching in the same way that lists and deques do (their memory access patterns are consecutive).   

The core concept for the patch is that a cache line fetch may be expensive so you might as well check more than one slot once a line is fetched.  Working against us is that we don't have control over where malloc starts a memory block (possibly starting in the middle of a cache line).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 02:14:01 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 18 Aug 2013 00:14:01 +0000
Subject: [issue18773] When a signal handler fails to write to the file
 descriptor registered with ``signal.set_wakeup_fd()``,
 an exception does not report the file descriptor
Message-ID: <1376784841.45.0.79172750551.issue18773@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

When a signal handler fails to write to the file descriptor registered with ``signal.set_wakeup_fd()``, an exception does not report which the file descriptor is the problematic one.

Attached the patch to put the file descriptor in the aforementioned exception and modify the unit test accordingly.

----------
components: Extension Modules
files: add_file_descriptor_to_exception_signal_set_wakeup_fd.patch
keywords: patch
messages: 195534
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: When a signal handler fails to write to the file descriptor registered with ``signal.set_wakeup_fd()``, an exception does not report the file descriptor
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31346/add_file_descriptor_to_exception_signal_set_wakeup_fd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18773>
_______________________________________

From report at bugs.python.org  Sun Aug 18 02:16:37 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 18 Aug 2013 00:16:37 +0000
Subject: [issue18773] When a signal handler fails to write to the file
 descriptor registered with ``signal.set_wakeup_fd()``,
 an exception does not report the file descriptor
In-Reply-To: <1376784841.45.0.79172750551.issue18773@psf.upfronthosting.co.za>
Message-ID: <1376784997.81.0.453234778184.issue18773@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Same patch, but more pep8 compliant.

----------
Added file: http://bugs.python.org/file31347/add_file_descriptor_to_exception_signal_set_wakeup_fd_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18773>
_______________________________________

From report at bugs.python.org  Sun Aug 18 02:17:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Aug 2013 00:17:33 +0000
Subject: [issue18773] When a signal handler fails to write to the file
 descriptor registered with ``signal.set_wakeup_fd()``,
 an exception does not report the file descriptor
In-Reply-To: <1376784841.45.0.79172750551.issue18773@psf.upfronthosting.co.za>
Message-ID: <1376785053.31.0.0969024944135.issue18773@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The errno is in the following line (the "[OSError]" one).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18773>
_______________________________________

From report at bugs.python.org  Sun Aug 18 02:34:19 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 18 Aug 2013 00:34:19 +0000
Subject: [issue18562] Regex howto: revision pass
In-Reply-To: <1374854855.56.0.787824851556.issue18562@psf.upfronthosting.co.za>
Message-ID: <1376786059.51.0.537951236723.issue18562@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Slightly revised version that modifies the discussion of when to pre-compile a regex and when to not bother.  I don't think this is a very important issue, so I don't think it needs a long discussion.

----------
Added file: http://bugs.python.org/file31348/regex.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18562>
_______________________________________

From report at bugs.python.org  Sun Aug 18 02:44:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Aug 2013 00:44:15 +0000
Subject: [issue18562] Regex howto: revision pass
In-Reply-To: <1374854855.56.0.787824851556.issue18562@psf.upfronthosting.co.za>
Message-ID: <1376786655.29.0.853291513116.issue18562@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Well, this is already too long IMO. Two sentences should suffice. If you are calling a regex very often in a loop, then it makes sense to compile it. Otherwise, don't bother.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18562>
_______________________________________

From report at bugs.python.org  Sun Aug 18 03:49:58 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Aug 2013 01:49:58 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376790598.58.0.760924111518.issue18771@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Here's a simple benchmark to start with.

On my machine (2.4Ghz Core2 Duo with 2MB L3 cache) and compiled with GCC-4.8, the benchmark shows a 6% speedup for sets that spill over L2 cache and 11% for sets that spill over the L3 cache.

The theoretically expected result is 9.75%:

   26% collision rate (for tables that are 64% full)
 x 75% chance of adjacent entry in same cache line
 x 50% savings (two lookups for the price of one)
 -----
 9.75%
 =====

Most programs will have less benefit (they may smaller tables that fit in L1 cache or have tables that are less densely filled resulting in fewer collisions).  My quick timings show either no change or inconsequential improvement in the performance of those programs.

----------
Added file: http://bugs.python.org/file31349/set_bench.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 04:46:35 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Aug 2013 02:46:35 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376793995.04.0.145107608122.issue18771@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file31350/insert_clean.s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 05:12:21 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 18 Aug 2013 03:12:21 +0000
Subject: [issue18773] When a signal handler fails to write to the file
 descriptor registered with ``signal.set_wakeup_fd()``,
 an exception does not report the file descriptor
In-Reply-To: <1376784841.45.0.79172750551.issue18773@psf.upfronthosting.co.za>
Message-ID: <1376795541.0.0.944189192501.issue18773@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Sorry,

When I read "... wakeup fd:\n" my subconsciousness mind automatically translated it to "... wakeup fd: %d\n". Then you made me realized there is another error message below it.

I closed this ticket as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18773>
_______________________________________

From report at bugs.python.org  Sun Aug 18 06:38:23 2013
From: report at bugs.python.org (John Pye)
Date: Sun, 18 Aug 2013 04:38:23 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1376800703.6.0.596174674359.issue4709@psf.upfronthosting.co.za>


John Pye added the comment:

This bug is still present in Python 2.7.5 on Windows 64-bit . I am currently providing the following instructions for MinGW-w64 users wanting to link to Python27.dll:

http://ascend4.org/Setting_up_a_MinGW-w64_build_environment#Setup_Python_for_compilation_of_extensions

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Sun Aug 18 06:58:01 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 18 Aug 2013 04:58:01 +0000
Subject: [issue18774] There is still last bit of GNU Pth code in signalmodule.c
Message-ID: <1376801880.96.0.197365143686.issue18774@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

I read this commit:
http://hg.python.org/cpython/rev/1d5f644b9241

But I noticed there is still GNU Pth code lingering around in Modules/signalmodule.c.

Beside of that the WITH_PTH code (in the same file) is expired already. If you configure python with this option (--with-pth), the configure process will complain that it does not recognize the option.

Attached the patch to clean up this last bit of GNU Pth code.

----------
components: Extension Modules
files: remove_gnu_pth.patch
keywords: patch
messages: 195542
nosy: christian.heimes, vajrasky
priority: normal
severity: normal
status: open
title: There is still last bit of GNU Pth code in signalmodule.c
versions: Python 3.4
Added file: http://bugs.python.org/file31351/remove_gnu_pth.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18774>
_______________________________________

From report at bugs.python.org  Sun Aug 18 07:47:34 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Aug 2013 05:47:34 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376804854.28.0.115603751027.issue18771@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Attaching the detailed results of a CacheGrind analysis.  Here are the high-points (all of which were expected):

* The last level data cache miss-rate improved 12% (from 4.9% to 4.3%).
* The first level data cache miss-rate improved 14% (from 5.5% to 4.7%).
* The additional code caused the instruction cache miss-rate to get slightly worse (from .32% to .40%).

The last level cache misses are the most important.  Per the cachegrind docs, "an L1 miss will typically cost around 10 cycles, [and] an LL miss can cost as much as 200 cycles."

----------
Added file: http://bugs.python.org/file31352/grind.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 08:27:40 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Aug 2013 06:27:40 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376807260.44.0.861289436542.issue18771@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Also, cachegrind shows a 3% improvement in the branch misprediction rate (from 9.9% to 9.6%).

==82814== Mispred rate:             9.9% (          9.4%     +          15.5%
==82812== Mispred rate:             9.6% (          9.1%     +          14.1%   )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 08:49:07 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 18 Aug 2013 06:49:07 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376808547.5.0.881586458783.issue18712@psf.upfronthosting.co.za>


Armin Rigo added the comment:

For completeness, can you post one line saying why the much simpler solution "range(a).stop" is not accepted?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sun Aug 18 09:31:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Aug 2013 07:31:25 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376811085.51.0.0511265794782.issue18712@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a variant with getattr_static().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sun Aug 18 09:31:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Aug 2013 07:31:58 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376811118.41.0.471214294834.issue18712@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file31353/operator_index_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sun Aug 18 09:38:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Aug 2013 07:38:45 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376811525.07.0.106497210872.issue18712@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> For completeness, can you post one line saying why the much simpler solution "range(a).stop" is not accepted?

Because it is implementation detail. The range() function if it will be implemented in Python needs operator.index().

The main purpose of adding Python implementation of the operator module was to provide an implementation which can be used in alternative Python implementations (e.g. PyPy). The CPython itself doesn't use it. And now I doubt that such complicated implementation will be helpful.

Perhaps we need a builtin which exposes _PyType_Lookup() at Python level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sun Aug 18 09:48:01 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 18 Aug 2013 07:48:01 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376812081.57.0.535887451425.issue18712@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Ah.  If that's the only reason, then that seems a bit like misguided effort...  For alternative implementations like PyPy and Jython, the "_operator" module is definitely one of the simplest ones to reimplement in RPython or Java.  Every function is straightforwardly translated to just one call to an internal function -- that we need to have already for the rest of the language.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sun Aug 18 09:56:42 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 18 Aug 2013 07:56:42 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376812602.56.0.159196539389.issue18712@psf.upfronthosting.co.za>


Armin Rigo added the comment:

...but yes, it's very obvious that exposing _PyType_Lookup() to pure Python is the right thing to do here.  This is a central part of the way Python works internally, after all.

Moreover, sorry about my previous note: if we started today to write PyPy, then it would be enough to have the pure Python version of operator.index(), based on the newly exposed _PyType_Lookup().  With PyPy's JIT, there is no real performance loss.  Some of my confusion came from the fact that there *would* be serious performance loss if we had to work with the pure Python looping-over-__mro__-and-fishing-in-__dict__ version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Sun Aug 18 10:25:52 2013
From: report at bugs.python.org (Freek Dijkstra)
Date: Sun, 18 Aug 2013 08:25:52 +0000
Subject: [issue17400] ipaddress.is_private needs to take into account of
 rfc6598
In-Reply-To: <1363052217.02.0.113831391012.issue17400@psf.upfronthosting.co.za>
Message-ID: <1376814352.54.0.625159275447.issue17400@psf.upfronthosting.co.za>


Freek Dijkstra added the comment:

I was about to make the same suggestion as the OP.

Most users think of "private IP" addresses as NATed IP addresses. I think the technical term is "forwardable, but not globally unique". Thus, the method of least surprise would be that indeed the is_private() method returns True for 100.64.0.0/10.

As for the RFC, these addresses are indeed the same, that they are both NATted. They are different that for RFC 1918 addresses, it is the end-site (home network, or office network) that does the NATing, while for RFC 6598, it is the ISP that does the NATing.

I think the confusing comes from the term is_private(). Formally, this only applies to RFC 1918 addresses, but it seems that this library does not take a formal but pragmatic approach. Otherwise, they would have added the methods is_forwardable(), is_global() and is_reserved() in line with what is the official specification at http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml. I prefer a pragmatic approach, and the term is_natted() or is_private() because that is what most programmers are interested in. Those few programmers that truly understand the difference between all these IP ranges (e.g. those who write bogon filter software), will simply avoid these methods and just use the rest of the library.

So +1 for this request.

----------
nosy: +macfreek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17400>
_______________________________________

From report at bugs.python.org  Sun Aug 18 12:23:17 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Aug 2013 10:23:17 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376807260.44.0.861289436542.issue18771@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb4yRCCWs-6hZiN-TRdkqTmjrK0nHDkia4wBNxN-a6D+w@mail.gmail.com>


STINNER Victor added the comment:

Instead of only a second lookup, could you try for example 4 lookup and
align j to fit in a cache line? Or do you expect more collisions with 4
contiguious lookup?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 12:43:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Aug 2013 10:43:32 +0000
Subject: [issue18774] There is still last bit of GNU Pth code in signalmodule.c
In-Reply-To: <1376801880.96.0.197365143686.issue18774@psf.upfronthosting.co.za>
Message-ID: <3cHvxv5yx1z7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 646c2388d8f5 by Christian Heimes in branch 'default':
Issue #18774: Remove last bits of GNU PTH thread code, patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/646c2388d8f5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18774>
_______________________________________

From report at bugs.python.org  Sun Aug 18 12:44:34 2013
From: report at bugs.python.org (Robin Schreiber)
Date: Sun, 18 Aug 2013 10:44:34 +0000
Subject: [issue15849] PEP 3121, 384 Refactoring applied to xx module
In-Reply-To: <1346596353.57.0.974507844943.issue15849@psf.upfronthosting.co.za>
Message-ID: <1376822674.67.0.687020104494.issue15849@psf.upfronthosting.co.za>


Robin Schreiber added the comment:

Antoine, regarding that the last pending problem with the patch is related to the NULL checking of FindModule, I would be inclined to include your proposed helper API. I see that issue18710 has not been included into the trunk yet, but I think this is mostly due to the additional _csv patch and not because of the proposed API itself.
So I will upload a corrected version of the patch soon, but it will rely on issue18710 to be accepted beforehand...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15849>
_______________________________________

From report at bugs.python.org  Sun Aug 18 14:02:06 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 18 Aug 2013 12:02:06 +0000
Subject: [issue18774] There is still last bit of GNU Pth code in signalmodule.c
In-Reply-To: <1376801880.96.0.197365143686.issue18774@psf.upfronthosting.co.za>
Message-ID: <1376827326.74.0.0555706834949.issue18774@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks! Three comments still refer to GNU pth:

configure.ac:    # (e.g. gnu pth with pthread emulation)
Python/condvar.h:   library (e.g. gnu pth in pthread emulation) */
Python/thread.c:   library (e.g. gnu pth in pthread emulation) */

thread.c and condvar.h implement a fallback for libraries that don't provide _POSIX_THREADS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18774>
_______________________________________

From report at bugs.python.org  Sun Aug 18 14:19:27 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 18 Aug 2013 12:19:27 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376828367.1.0.000396676154108.issue18606@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Since I can't respond to the reviews, here's a revised patch. Summary of major changes:

- median.* functions are now median_*
- mode now only returns a single value
- better integrate tests with Python regression suite
- cleanup tests as per Ezio's suggestions
- remove unnecessary metadata and change licence

----------
Added file: http://bugs.python.org/file31354/statistics.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Sun Aug 18 14:27:49 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 18 Aug 2013 12:27:49 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376828869.27.0.706031333422.issue18606@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

On 15/08/13 22:58, ezio.melotti at gmail.com wrote:
> http://bugs.python.org/review/18606/diff/8927/Lib/statistics.py#newcode277
> Lib/statistics.py:277: assert isinstance(x, float) and
> isinstance(partials, list)
> Is this a good idea?

I think so add_partials is internal/private, and so I don't have to worry about the caller providing wrong arguments, say a non-float. But I want some testing to detect coding errors. Using assert for this sort of internal pre-condition is exactly what assert is designed for.


> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics.py#newcode144
> Lib/test/test_statistics.py:144: assert data != sorted(data)
> Why not assertNotEqual?

I use bare asserts for testing code logic, even if the code is test code. So if I use self.assertSpam(...) then I'm performing a unit test of the module being tested. If I use a bare assert, I'm asserting something about the test logic itself.


> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py
> File Lib/test/test_statistics_approx.py (right):
>
> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py#newcode1
> Lib/test/test_statistics_approx.py:1: """Numeric approximated equal
> comparisons and unit testing.
> Do I understand correctly that this is just an helper module used in
> test_statistics and that it doesn't actually test anything from the
> statistics module?

Correct.


> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py#newcode137
> Lib/test/test_statistics_approx.py:137: # and avoid using
> TestCase.almost_equal, because it sucks
> Could you elaborate on this?

Ah, I misspelled "TestCase.AlmostEqual".

- Using round() to test for equal-to-some-tolerance is IMO quite an idiosyncratic way of doing approx-equality tests. I've never seen anyone do it that way before. It surprises me.

- It's easy to think that ``places`` means significant figures, not decimal places.

- There's now a delta argument that is the same as my absolute error tolerance ``tol``, but no relative error argument.

- You can't set a  per-instance error tolerance.


> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py#newcode241
> Lib/test/test_statistics_approx.py:241: assert len(args1) == len(args2)
> Why not assertEqual?

As above, I use bare asserts to test the test logic, and assertSpam methods to perform the test. In this case, I'm confirming that I haven't created dodgy test data.


> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py#newcode255
> Lib/test/test_statistics_approx.py:255: self.assertTrue(approx_equal(b,
> a, tol=0, rel=rel))
> Why not assertApproxEqual?

Because I'm testing the approx_equal function. I can't use assertApproxEqual to test its own internals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Sun Aug 18 15:14:26 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 18 Aug 2013 13:14:26 +0000
Subject: [issue18178] Redefinition of malloc(3) family of functions at build
 time
In-Reply-To: <1370851878.25.0.593003779218.issue18178@psf.upfronthosting.co.za>
Message-ID: <1376831666.25.0.672121413919.issue18178@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thx for the fix!

----------
nosy: +christian.heimes
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18178>
_______________________________________

From report at bugs.python.org  Sun Aug 18 15:17:42 2013
From: report at bugs.python.org (Robin Schreiber)
Date: Sun, 18 Aug 2013 13:17:42 +0000
Subject: [issue15849] PEP 3121, 384 Refactoring applied to xx module
In-Reply-To: <1346596353.57.0.974507844943.issue15849@psf.upfronthosting.co.za>
Message-ID: <1376831862.39.0.472116849634.issue15849@psf.upfronthosting.co.za>


Robin Schreiber added the comment:

Updated patch accordingly. 
Regarding the problem in http://mail.python.org/pipermail/python-dev/2013-August/127862.html , it can indeed be solved by returning the already existing module object, if PyInit is called multiple times. I followed the discussion and can not make out a definite decision on how to handle this.
My understanding is, that up to now extension modules are only supposed to be initialized once per interpreter, so the check I have included in, for example issue15651, makes sense from this perspective. There have been reasonable desires (from Eli) to make the module state separate from each imported module within the interpreter, but this would involve more drastic changes and will be rather part of future Python releases.
Should we therefore (for now) make this a mandatory PEP3121 convention and include it into the xxmodule.c refactoring?

----------
Added file: http://bugs.python.org/file31355/xxmodule_pep3121-384_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15849>
_______________________________________

From report at bugs.python.org  Sun Aug 18 15:19:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Aug 2013 13:19:40 +0000
Subject: [issue15849] PEP 3121, 384 Refactoring applied to xx module
In-Reply-To: <1376831862.39.0.472116849634.issue15849@psf.upfronthosting.co.za>
Message-ID: <1376831970.2520.0.camel@fsol>


Antoine Pitrou added the comment:

> Updated patch accordingly. 

I don't understand why your patch still has a module state while all
objects can be looked up in the module dict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15849>
_______________________________________

From report at bugs.python.org  Sun Aug 18 15:22:02 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 18 Aug 2013 13:22:02 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1376832122.61.0.259675418608.issue18747@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The lastest patch mixes seconds into the time field of seed.

Python 3.3+ support only NT and POSIX threads. 2.7 and 3.2 have GNU pth and other threading API but I neither have a system to test other threading libs nor the motivation to port my patch to an ancient threading library.

It's not just RAND_bytes(). OpenSSL's PRNG is also used by OpenSSL internally, e.g. as entropy source for SSL/TLS handshakes. How many function do you want to patch?

----------
Added file: http://bugs.python.org/file31356/openssl_prng_atfork4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Sun Aug 18 15:29:16 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 18 Aug 2013 13:29:16 +0000
Subject: [issue18742] Abstract base class for hashlib
In-Reply-To: <1376519472.63.0.753349393836.issue18742@psf.upfronthosting.co.za>
Message-ID: <1376832556.53.0.90130150517.issue18742@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks Gregory!

Have you had a chance to read http://www.python.org/dev/peps/pep-0452/ , too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18742>
_______________________________________

From report at bugs.python.org  Sun Aug 18 15:34:56 2013
From: report at bugs.python.org (Robin Schreiber)
Date: Sun, 18 Aug 2013 13:34:56 +0000
Subject: [issue15849] PEP 3121, 384 Refactoring applied to xx module
In-Reply-To: <1346596353.57.0.974507844943.issue15849@psf.upfronthosting.co.za>
Message-ID: <1376832896.65.0.863006111897.issue15849@psf.upfronthosting.co.za>


Robin Schreiber added the comment:

Everything except for the Xxo_Type. But you are right. Then again, why are these global static variables from the start? Isn't this because xxmodule is some kind of "dummy" module that is supposed to demonstrate some coding conventions on how to build extension modules? 
Another possibility could be the faster lookup of the variables, which is now of course invalidated if we store it within the module state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15849>
_______________________________________

From report at bugs.python.org  Sun Aug 18 15:45:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Aug 2013 13:45:19 +0000
Subject: [issue15849] PEP 3121, 384 Refactoring applied to xx module
In-Reply-To: <1376832896.65.0.863006111897.issue15849@psf.upfronthosting.co.za>
Message-ID: <1376833511.2520.1.camel@fsol>


Antoine Pitrou added the comment:

> Everything except for the Xxo_Type. But you are right. Then again, why
> are these global static variables from the start? Isn't this because
> xxmodule is some kind of "dummy" module that is supposed to
> demonstrate some coding conventions on how to build extension
> modules? 

I don't really know what the purpose of xxmodule is. But I don't think
redundant storage is a good idea, especially with different
lifetimes :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15849>
_______________________________________

From report at bugs.python.org  Sun Aug 18 15:47:19 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 18 Aug 2013 13:47:19 +0000
Subject: [issue18603] PyOS_mystricmp unused and no longer available
In-Reply-To: <1375228725.23.0.641374823001.issue18603@psf.upfronthosting.co.za>
Message-ID: <1376833639.49.0.900745505469.issue18603@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Here is a simple patch based on the approach in Objects/object.c

----------
components: +Interpreter Core
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file31357/18603.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18603>
_______________________________________

From report at bugs.python.org  Sun Aug 18 17:00:26 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Aug 2013 15:00:26 +0000
Subject: [issue18748] libgcc_s.so.1 must be installed for pthread_cancel to
 work
In-Reply-To: <CAMpsgwbwXq-MiMH06hgK3CycstMOcSNp+jLo0oaVbUgFwCkA3A@mail.gmail.com>
Message-ID: <CAH_1eM2+VKK+pHMd8waMiBcgdY9ZxYkq=X8dZPMyZEmNDfjn1w@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> On Linux, you can try to set the LD_PRELOAD environment variable as a
> workaround.
>
> LD_PRELOAD=libgcc_s.so.1 python bug.py
>
> You may need to specify the full path.

I don't think that'll work.
Despite its name, using LD_PRELOAD won't "preload" the library. It
will only be loaded upon dlopen(). It just makes sure that symbols
will be looked for in this library first, even before the libc.

> Because in python2.x it wasn't loaded at runtime.

Yes it was. As explained above, you can get the very same crash upon
pthread_exit().

> Alright ... would it be a very big hack to preload libgcc in the thread module (at import
> time) ?

IMO yes, but if someone writes a patch, I won't oppose to it :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18748>
_______________________________________

From report at bugs.python.org  Sun Aug 18 17:04:48 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 18 Aug 2013 15:04:48 +0000
Subject: [issue18678] Wrong struct members name for spwd module
In-Reply-To: <1375887000.77.0.620898445025.issue18678@psf.upfronthosting.co.za>
Message-ID: <1376838288.72.0.127543910866.issue18678@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Attached the patch to accommodate R. David Murray's request. Accessing invalid attributes such as sp_nam and sp_pwd from spwd tuple will generate deprecation warning message.

Also, I added test function so we can run spwd module directly. This is useful because I don't think we can unit test spwd module. (This module can be used only if you are root.)

The Modules/spwdmodule.c file is supposed to be Modules/_spwdmodule.c following tradition but that will make the review process harder. If this patch is good to go, I'll rename the module file later.

----------
Added file: http://bugs.python.org/file31358/spwd_struct_members_name_fix_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18678>
_______________________________________

From report at bugs.python.org  Sun Aug 18 17:12:04 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Aug 2013 15:12:04 +0000
Subject: [issue18418] Thread.isAlive() sometimes True after fork
In-Reply-To: <1373408030.66.0.77258289483.issue18418@psf.upfronthosting.co.za>
Message-ID: <1376838724.8.0.510094402885.issue18418@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18418>
_______________________________________

From report at bugs.python.org  Sun Aug 18 17:27:32 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 18 Aug 2013 15:27:32 +0000
Subject: [issue18562] Regex howto: revision pass
In-Reply-To: <1374854855.56.0.787824851556.issue18562@psf.upfronthosting.co.za>
Message-ID: <1376839652.86.0.192392030366.issue18562@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

#17441 also has a discussion about regex caching that might be relevant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18562>
_______________________________________

From report at bugs.python.org  Sun Aug 18 17:31:37 2013
From: report at bugs.python.org (pmoody)
Date: Sun, 18 Aug 2013 15:31:37 +0000
Subject: [issue17400] ipaddress.is_private needs to take into account of
 rfc6598
In-Reply-To: <1363052217.02.0.113831391012.issue17400@psf.upfronthosting.co.za>
Message-ID: <1376839897.73.0.854433532618.issue17400@psf.upfronthosting.co.za>


pmoody added the comment:

I'm still not convinced. The rfc still says in essence "It's not private like rfc1918 space, but sometimes certain people can treat it similarly." and I think it would be pretty surprising for ipaddress to return True if it's not a network operator running the query. Since we have no way of knowing that, I'm extremely disinclined to make this change. A more formal solution would be all of the possible "is_RFCXXXX" methods, but that doesn't seem to be worth the effort.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17400>
_______________________________________

From report at bugs.python.org  Sun Aug 18 17:36:04 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 18 Aug 2013 15:36:04 +0000
Subject: [issue17276] HMAC: deprecate default hash
In-Reply-To: <1361535402.96.0.618065106631.issue17276@psf.upfronthosting.co.za>
Message-ID: <1376840164.94.0.754390859962.issue17276@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Here is a patch that deprecates MD5 has implicit default hashing algorithm. It also implements digestmod string support.

PEP 247 doesn't define the digestmod argument of keyed hashing algorithms. I'm going to define it in PEP 452.

----------
keywords: +patch
nosy: +akuchling, gregory.p.smith
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31359/17276.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17276>
_______________________________________

From report at bugs.python.org  Sun Aug 18 18:35:57 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 18 Aug 2013 16:35:57 +0000
Subject: [issue18775] name attribute for HMAC
Message-ID: <1376843757.16.0.673413061043.issue18775@psf.upfronthosting.co.za>


New submission from Christian Heimes:

In issue #18532 name attribute was officially documented and tested for hashing objects. PEP 247 considers HMAC as keyed hashing algorithm. Therefore I suggest that HMAC object should provide the same interface.

It's a bit unfortunate that HMAC has a blocksize attribute for the default blocksize but the API defines a block_size attribute.

----------
components: Library (Lib)
files: hmac_name.patch
keywords: patch
messages: 195570
nosy: christian.heimes, gregory.p.smith, jason.coombs
priority: normal
severity: normal
stage: patch review
status: open
title: name attribute for HMAC
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31360/hmac_name.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18775>
_______________________________________

From report at bugs.python.org  Sun Aug 18 18:54:55 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Aug 2013 16:54:55 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376844895.13.0.85981629311.issue18771@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Instead of only a second lookup, could you try for example 4 lookup
> and align j to fit in a cache line? 

Accessing 4 entries per probe is a tempting line of development, but will be subject to diminishing returns (second and third collisions aren't frequent).

I like the idea of aligning j to fit in a cache line, but the computation would need to be cheap and portable (standard C with no pointer tricks that rely on non-guaranteed behavior).

Have you had a chance to run the benchmarks on your machine?  I'm curious how this works out on other processors and with other compilers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 19:12:12 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 18 Aug 2013 17:12:12 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376845932.26.0.230143156087.issue18771@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 19:24:30 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 18 Aug 2013 17:24:30 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376846670.05.0.754742588856.issue18771@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Attaching an updated patch (same algorithm but with a little more factoring to make the patch smaller).

----------
Added file: http://bugs.python.org/file31361/so2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Sun Aug 18 19:52:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Aug 2013 17:52:00 +0000
Subject: [issue18743] References to non-existant "StringIO" module
In-Reply-To: <1376542911.78.0.658455842148.issue18743@psf.upfronthosting.co.za>
Message-ID: <1376848320.57.0.572399781902.issue18743@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which fixes references to StringIO in docstrings and comments and removes redundant code.

----------
Added file: http://bugs.python.org/file31362/src_StringIO_refs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18743>
_______________________________________

From report at bugs.python.org  Sun Aug 18 20:31:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Aug 2013 18:31:08 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1376850668.68.0.157982725052.issue18772@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

See also the python-dev thread about other drawbacks of the new dummy approach: http://mail.python.org/pipermail/python-dev/2013-August/128025.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Sun Aug 18 20:38:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Aug 2013 18:38:59 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376851139.65.0.862762398269.issue18606@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

A couple of comments about the test suite:
- I would like to see PEP8 test names, i.e. test_foo_and_bar rather than testFooAndBar
- I don't think we need two separate test modules, it makes things more confusing

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Sun Aug 18 21:28:49 2013
From: report at bugs.python.org (Geert Jansen)
Date: Sun, 18 Aug 2013 19:28:49 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1376854129.33.0.153973389259.issue12641@psf.upfronthosting.co.za>


Geert Jansen added the comment:

*bump*.

This is a critical bugfix that prevents I bet 90%+ of Python users on Windows compiling C extensions. It has been open for 2 years and it's a great disservice to people having to compile stuff on Windows.

Oscar has been doing a terrific job of providing man patches. May I ask that a core dev finally takes some responsibility here, signs of on the patch, and get it applied?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Sun Aug 18 21:46:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Aug 2013 19:46:08 +0000
Subject: [issue18761] Fix internal doc references for the email package
In-Reply-To: <1376682451.08.0.523486132403.issue18761@psf.upfronthosting.co.za>
Message-ID: <1376855168.6.0.472121952916.issue18761@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is updated patch which addresses comments from David. Long lines are wrapped now.

----------
Added file: http://bugs.python.org/file31363/refs.email_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18761>
_______________________________________

From report at bugs.python.org  Sun Aug 18 23:20:37 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Aug 2013 21:20:37 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376832122.61.0.259675418608.issue18747@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ7jBHH=f_R+sPsrmgb-4t3txCZSzrqddN-iwLgE+=G0A@mail.gmail.com>


STINNER Victor added the comment:

PySSL_RAND_atfork_child(void) can be simplified by calling
_PyTime_gettimeofday(). This function uses the most(*) accurate
function and already implements fallbacks on error.

(*) _PyTime_gettimeofday() does not use clock_gettime() because of a
linker issue: Python is not linked to librt, which is required to get
clock_gettime() on Linux with glibc < 2.17. So you get a few less bits
of entropy, but does it really matter? If it matters, you have
probably to use a better random of entropy than the system time...

Anyway, it would be easier to move the _PyTime_timeval and similar
structures into the seed structure instead of shifting bits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Mon Aug 19 00:08:42 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Aug 2013 22:08:42 +0000
Subject: [issue18761] Fix internal doc references for the email package
In-Reply-To: <1376682451.08.0.523486132403.issue18761@psf.upfronthosting.co.za>
Message-ID: <1376863722.08.0.567539217713.issue18761@psf.upfronthosting.co.za>


R. David Murray added the comment:

Based on your response to the review (I haven't looked at the new patch) I say go ahead and apply it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18761>
_______________________________________

From report at bugs.python.org  Mon Aug 19 00:09:10 2013
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Sun, 18 Aug 2013 22:09:10 +0000
Subject: [issue18418] Thread.isAlive() sometimes True after fork
In-Reply-To: <1373408030.66.0.77258289483.issue18418@psf.upfronthosting.co.za>
Message-ID: <1376863750.12.0.658123802278.issue18418@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

FYI I'm going on vacation again 8/20 through 8/25. I'll check in again as soon as I return to see if there's anything else I should do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18418>
_______________________________________

From report at bugs.python.org  Mon Aug 19 00:29:22 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Aug 2013 22:29:22 +0000
Subject: [issue18592] IDLE: Unit test for SearchDialogBase.py
In-Reply-To: <1375146770.41.0.774627283078.issue18592@psf.upfronthosting.co.za>
Message-ID: <3cJCcL0K1Rz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 0d2b87ec9f2b by Terry Jan Reedy in branch '2.7':
Issue #18592: Add docstrings to file being tested (idlelib.SearchDialogBase.py).
http://hg.python.org/cpython/rev/0d2b87ec9f2b

New changeset e09dfdbeb9a2 by Terry Jan Reedy in branch '3.3':
Issue #18592: Add docstrings to file being tested (idlelib.SearchDialogBase.py).
http://hg.python.org/cpython/rev/e09dfdbeb9a2

New changeset 358a2b2fbad4 by Terry Jan Reedy in branch '3.3':
Issue #18592: whitespace
http://hg.python.org/cpython/rev/358a2b2fbad4

New changeset 1f2b78941c4a by Terry Jan Reedy in branch '2.7':
Issue #18592: whitespace
http://hg.python.org/cpython/rev/1f2b78941c4a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18592>
_______________________________________

From report at bugs.python.org  Mon Aug 19 00:30:21 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 18 Aug 2013 22:30:21 +0000
Subject: [issue18592] IDLE: Unit test for SearchDialogBase.py
In-Reply-To: <1375146770.41.0.774627283078.issue18592@psf.upfronthosting.co.za>
Message-ID: <1376865021.46.0.246364160316.issue18592@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I added the docstrings that I wish had already been present.
The only 2.7-3.3 difference in SearchDialogBase is Tkinter/tkinter.

----------
assignee:  -> terry.reedy
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18592>
_______________________________________

From report at bugs.python.org  Mon Aug 19 00:37:47 2013
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 18 Aug 2013 22:37:47 +0000
Subject: [issue1257] atexit errors should result in nonzero exit code
In-Reply-To: <1192046186.55.0.804669715206.issue1257@psf.upfronthosting.co.za>
Message-ID: <1376865467.04.0.147224029493.issue1257@psf.upfronthosting.co.za>


Changes by Doug Hellmann <doug.hellmann at gmail.com>:


----------
nosy: +doughellmann

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1257>
_______________________________________

From report at bugs.python.org  Mon Aug 19 00:49:33 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 18 Aug 2013 22:49:33 +0000
Subject: [issue17810] Implement PEP 3154 (pickle protocol 4)
In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za>
Message-ID: <1376866173.24.0.248146119282.issue17810@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

I am still working on it. I am implemented support for nested globals last week (http://hg.python.org/features/pep-3154-alexandre/rev/c8991b32a47e). At this point, the only big piece remaining is the support for method descriptors. There are other minor things left but we can worry about those later.

Nick, thanks for the pointer! I didn't know about PEP 451. I will look how we can use it in pickle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17810>
_______________________________________

From report at bugs.python.org  Mon Aug 19 00:57:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Aug 2013 22:57:33 +0000
Subject: [issue18562] Regex howto: revision pass
In-Reply-To: <1374854855.56.0.787824851556.issue18562@psf.upfronthosting.co.za>
Message-ID: <3cJDDr3Mqxz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 366ca21600c9 by Andrew Kuchling in branch '3.3':
#18562: various revisions to the regex howto for 3.x
http://hg.python.org/cpython/rev/366ca21600c9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18562>
_______________________________________

From report at bugs.python.org  Mon Aug 19 00:58:15 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 18 Aug 2013 22:58:15 +0000
Subject: [issue11671] Security hole in wsgiref.headers.Headers
In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za>
Message-ID: <1376866695.41.0.945727881449.issue11671@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11671>
_______________________________________

From report at bugs.python.org  Mon Aug 19 01:01:22 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 18 Aug 2013 23:01:22 +0000
Subject: [issue18562] Regex howto: revision pass
In-Reply-To: <1374854855.56.0.787824851556.issue18562@psf.upfronthosting.co.za>
Message-ID: <1376866882.76.0.512108677683.issue18562@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18562>
_______________________________________

From report at bugs.python.org  Mon Aug 19 01:01:32 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 18 Aug 2013 23:01:32 +0000
Subject: [issue18562] Regex howto: revision pass
In-Reply-To: <1374854855.56.0.787824851556.issue18562@psf.upfronthosting.co.za>
Message-ID: <1376866892.35.0.863262657788.issue18562@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18562>
_______________________________________

From report at bugs.python.org  Mon Aug 19 01:06:09 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Aug 2013 23:06:09 +0000
Subject: [issue1680961] remove sys.exitfunc, rewrite atexit in C
Message-ID: <1376867169.8.0.154511764028.issue1680961@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Sorry to ping you on an old issue, but can any of you explain why it was necessary to rewrite atexit in C?

----------
nosy: +pitrou
resolution: accepted -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1680961>
_______________________________________

From report at bugs.python.org  Mon Aug 19 01:07:59 2013
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 18 Aug 2013 23:07:59 +0000
Subject: [issue18776] atexit error display behavior changed in python 3
Message-ID: <1376867279.76.0.423082412526.issue18776@psf.upfronthosting.co.za>


New submission from Doug Hellmann:

Under python 2 when an atexit callback raised an exception the full traceback was displayed. Under python 3, only the summary of the exception is shown.

Input file:

import atexit


def exit_with_exception(message):
    raise RuntimeError(message)

atexit.register(exit_with_exception, 'Registered first')
atexit.register(exit_with_exception, 'Registered second')


Python 2:

$ python2.7 source/atexit/atexit_exception.py
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "source/atexit/atexit_exception.py", line 36, in exit_with_exception
    raise RuntimeError(message)
RuntimeError: Registered second
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "source/atexit/atexit_exception.py", line 36, in exit_with_exception
    raise RuntimeError(message)
RuntimeError: Registered first
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "source/atexit/atexit_exception.py", line 36, in exit_with_exception
    raise RuntimeError(message)
RuntimeError: Registered first

Python 3:

$ python3.3 source/atexit/atexit_exception.py
Error in atexit._run_exitfuncs:
RuntimeError: Registered second
Error in atexit._run_exitfuncs:
RuntimeError: Registered first

----------
messages: 195586
nosy: doughellmann
priority: normal
severity: normal
status: open
title: atexit error display behavior changed in python 3
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18776>
_______________________________________

From report at bugs.python.org  Mon Aug 19 01:08:49 2013
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 18 Aug 2013 23:08:49 +0000
Subject: [issue1680961] remove sys.exitfunc, rewrite atexit in C
Message-ID: <1376867329.24.0.683784836175.issue1680961@psf.upfronthosting.co.za>


Changes by Doug Hellmann <doug.hellmann at gmail.com>:


----------
nosy: +doughellmann

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1680961>
_______________________________________

From report at bugs.python.org  Mon Aug 19 01:11:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Aug 2013 23:11:23 +0000
Subject: [issue18776] atexit error display behavior changed in python 3
In-Reply-To: <1376867279.76.0.423082412526.issue18776@psf.upfronthosting.co.za>
Message-ID: <1376867483.01.0.173590598498.issue18776@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib)
keywords: +easy
stage:  -> patch review
type:  -> enhancement
versions:  -Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18776>
_______________________________________

From report at bugs.python.org  Mon Aug 19 01:16:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Aug 2013 23:16:48 +0000
Subject: [issue1257] atexit errors should result in nonzero exit code
In-Reply-To: <1192046186.55.0.804669715206.issue1257@psf.upfronthosting.co.za>
Message-ID: <1376867808.19.0.115066838091.issue1257@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I would disagree with this report. There are many errors which are effectively silenced by Python, except for being printed on stderr: for example, errors which occur in a __del__ method or a weakref callback (both of which semantically similar to an atexit handler); but also exceptions which terminate a non-main thread.

Python's error code is derived from the return status of the main thread of execution, not counting any kinds of asynchronous exceptions, which are simply displayed and then ignored.

If you want to write a test for errors at program exit, you should check for stderr's contents (by capturing it).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1257>
_______________________________________

From report at bugs.python.org  Mon Aug 19 01:56:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Aug 2013 23:56:16 +0000
Subject: [issue18445] Tools/Script/Readme is outdated
In-Reply-To: <1373782620.19.0.347266346086.issue18445@psf.upfronthosting.co.za>
Message-ID: <3cJFXb1RQ4z7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 9d5468a7a381 by Andrew Kuchling in branch 'default':
#18445: change permissions on some scripts to executable
http://hg.python.org/cpython/rev/9d5468a7a381

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18445>
_______________________________________

From report at bugs.python.org  Mon Aug 19 02:07:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Aug 2013 00:07:19 +0000
Subject: [issue18445] Tools/Script/Readme is outdated
In-Reply-To: <1373782620.19.0.347266346086.issue18445@psf.upfronthosting.co.za>
Message-ID: <3cJFnL3Lqqz7LjZ@mail.python.org>


Roundup Robot added the comment:

New changeset 16fad6c48016 by Andrew Kuchling in branch 'default':
#18445: update Tools/scripts/README.
http://hg.python.org/cpython/rev/16fad6c48016

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18445>
_______________________________________

From report at bugs.python.org  Mon Aug 19 02:08:13 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 19 Aug 2013 00:08:13 +0000
Subject: [issue18445] Tools/Script/Readme is outdated
In-Reply-To: <1373782620.19.0.347266346086.issue18445@psf.upfronthosting.co.za>
Message-ID: <1376870893.51.0.868455185049.issue18445@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Seydou: thanks for the patch!  I've applied it to 3.4.

----------
nosy: +akuchling
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18445>
_______________________________________

From report at bugs.python.org  Mon Aug 19 03:17:49 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 19 Aug 2013 01:17:49 +0000
Subject: [issue18592] IDLE: Unit test for SearchDialogBase.py
In-Reply-To: <1375146770.41.0.774627283078.issue18592@psf.upfronthosting.co.za>
Message-ID: <1376875069.47.0.809001280605.issue18592@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

A subtle point about coverage. The target module must be imported.
from idlelib import SearchDialogBase as sdb  # works.
import idlelib.SearchDialogBase as sdb  # does not
at least not as I invoke coveragepy in my batch file.

With this change, the four uncovered lines were "btn.select()" after 
  if self.engine.is/re/case/word/back/():
in create_option_buttons and create_other_buttons. I added a parameter to checkboxtests and a new method test_create_option_buttons_flipped. That leaves the line after isback() and I think the radiobutton test probably covers that anyway.

The attached file has a few other cosmetic changes, like 'self.searchengine' to 'self.engine'.

I would like to remove the duplicate testing in test_create_widgets. All we care for that test is that create_widgets calls the other four create methods. This could be done either by mocking the other methods (unittest.mock or custom replacement) or by looking to see that there is one entry, option button, other button, and command button.

Were you planning to do the check-label todos?

----------
Added file: http://bugs.python.org/file31364/18592_test_searchdialog.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18592>
_______________________________________

From report at bugs.python.org  Mon Aug 19 03:26:27 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Mon, 19 Aug 2013 01:26:27 +0000
Subject: [issue18727] test for writing dictionary rows to CSV
In-Reply-To: <1376409675.57.0.271656920796.issue18727@psf.upfronthosting.co.za>
Message-ID: <1376875587.35.0.767310423939.issue18727@psf.upfronthosting.co.za>


Muhammad Jehanzeb added the comment:

Sure. Thanks for the comment. I was just trying to be consistent with other tests. However, I updated the patch based on your recommendation. Please have a look at the latest one.

----------
Added file: http://bugs.python.org/file31365/issue18727_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18727>
_______________________________________

From report at bugs.python.org  Mon Aug 19 03:54:34 2013
From: report at bugs.python.org (=?utf-8?q?Juan_Luis_Boya_Garc=C3=ADa?=)
Date: Mon, 19 Aug 2013 01:54:34 +0000
Subject: [issue18512] sys.stdout.write does not allow bytes in Python 3.x
In-Reply-To: <1374287481.36.0.643885131326.issue18512@psf.upfronthosting.co.za>
Message-ID: <1376877274.74.0.259887377232.issue18512@psf.upfronthosting.co.za>


Juan Luis Boya Garc?a added the comment:

Sorry for the late response, GMail's SPAM filter ate the replies.

The main issue is sys.stdout being opened as text instead of binary. This fact is stated in the docs. http://docs.python.org/3/library/sys.html#sys.stdout

In any case, there are some caveats worth noting:

> You can do
>    sys.stdout.buffer.write(b"hello")
This is problematic if both buffer and IOTextWrapper are used. For example:

  print("Hello", end=""); sys.stdout.buffer.write(b"World")

That line may write `WorldHello` instead of `HelloWorld` (and it does indeed, at least in Linux implementation).

Yes, an application should not do this in Python3, but using print() and writing to stdout were OK in Python2, which makes porting programs harder.

A workaround is to perform sys.stdout.flush() before sys.stdout.buffer.write().

> (from the docs)
> Using io.TextIOBase.detach(), streams can be made binary by default.
> sys.stdout = sys.stdout.detach()

This should help in cases where most output is binary, but it's worth noting that interactive shells (such as the builtin python or IPython) and debuggers (both pdb and ipdb) stop working when this is used. Also, it will probably break every function there that relies on sys.stdout being Unicode or binary depending on only the Python version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18512>
_______________________________________

From report at bugs.python.org  Mon Aug 19 04:17:03 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 19 Aug 2013 02:17:03 +0000
Subject: [issue18425] IDLE Unit test for IdleHistory.py
In-Reply-To: <1373493838.59.0.876568806243.issue18425@psf.upfronthosting.co.za>
Message-ID: <1376878623.33.0.37450475624.issue18425@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Ezio: grepping test/*.py for (name)'= self.assertEqual' gets 182 hits in 15 different files. If you are generically opposed to name localization, please take your case to pydev. I also found 'unless = self.assertTrue' and am sure I have seen others in the stdlib and test files.

For (name), there is 1 use of 'e' and 'asseq', 5 of 'equal', and 175 of 'eq'. (In one place, 'eq' was only used once after being defined. I would not bother.) If you have a strong preference for 'eq', I will consider it, though it almost seems too light.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18425>
_______________________________________

From report at bugs.python.org  Mon Aug 19 04:19:21 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Aug 2013 02:19:21 +0000
Subject: [issue18425] IDLE Unit test for IdleHistory.py
In-Reply-To: <1373493838.59.0.876568806243.issue18425@psf.upfronthosting.co.za>
Message-ID: <1376878761.75.0.936322671524.issue18425@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> If you are generically opposed to name localization, please take your
> case to pydev.

I'm not strongly opposed to it, I probably even use it sometimes.  In that case I wouldn't have bothered, but YMMV.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18425>
_______________________________________

From report at bugs.python.org  Mon Aug 19 05:26:52 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Aug 2013 03:26:52 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
 iterable)
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1376882812.49.0.813789757115.issue18652@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18652>
_______________________________________

From report at bugs.python.org  Mon Aug 19 05:40:39 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Aug 2013 03:40:39 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
 iterable)
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1376883639.69.0.0651820914766.issue18652@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Hynek, thanks for your suggestion.  I would like to mull it over for a while before chiming in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18652>
_______________________________________

From report at bugs.python.org  Mon Aug 19 05:55:21 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 19 Aug 2013 03:55:21 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376884521.9.0.681958863846.issue18606@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Merged two test suites into one, and PEP-ified the test names testSpam -> test_spam.

----------
Added file: http://bugs.python.org/file31366/test_statistics.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Aug 19 05:59:06 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 19 Aug 2013 03:59:06 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1376884746.55.0.0278802992198.issue18606@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Patch file for the stats module alone, without the tests.

----------
Added file: http://bugs.python.org/file31367/statistics.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Aug 19 06:33:08 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 19 Aug 2013 04:33:08 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
 arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1376886788.07.0.0167617132308.issue16248@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

3.2 is owned by Georg.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Mon Aug 19 06:34:17 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 19 Aug 2013 04:34:17 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
 arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1376886857.13.0.968841101337.issue16248@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

As for 3.1, feel free to apply. There will likely be a source release of it at some point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Mon Aug 19 07:06:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Aug 2013 05:06:00 +0000
Subject: [issue18489] IDLE Unit test for SearchEngine.py
In-Reply-To: <1374118219.91.0.797974191988.issue18489@psf.upfronthosting.co.za>
Message-ID: <3cJNQ00hsnz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 310d187020e3 by Terry Jan Reedy in branch '2.7':
Issue #18489: idlelib.SearchEngine - add docstrings
http://hg.python.org/cpython/rev/310d187020e3

New changeset cfb510884a13 by Terry Jan Reedy in branch '3.3':
Issue #18489: idlelib.SearchEngine - add docstrings
http://hg.python.org/cpython/rev/cfb510884a13

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18489>
_______________________________________

From report at bugs.python.org  Mon Aug 19 07:31:27 2013
From: report at bugs.python.org (Vitaly Murashev)
Date: Mon, 19 Aug 2013 05:31:27 +0000
Subject: [issue18777] Cannot compile _ssl.c using openssl > 1.0
Message-ID: <1376890287.78.0.562230025847.issue18777@psf.upfronthosting.co.za>


New submission from Vitaly Murashev:

Cannot compile _ssl module when openssl version > 1.0 and it is configured with turned on macro OPENSSL_NO_DEPRECATED

Everything looks like in recent versions of openssl routine 'CRYPTO_set_id_callback' has gone away.

Patch suggested.

----------
components: Build
files: ssl.patch
keywords: patch
messages: 195602
nosy: vmurashev
priority: normal
severity: normal
status: open
title: Cannot compile _ssl.c using openssl > 1.0
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file31368/ssl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18777>
_______________________________________

From report at bugs.python.org  Mon Aug 19 07:47:47 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 19 Aug 2013 05:47:47 +0000
Subject: [issue18774] There is still last bit of GNU Pth code in signalmodule.c
In-Reply-To: <1376801880.96.0.197365143686.issue18774@psf.upfronthosting.co.za>
Message-ID: <1376891267.64.0.801440324733.issue18774@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18774>
_______________________________________

From report at bugs.python.org  Mon Aug 19 08:19:27 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 19 Aug 2013 06:19:27 +0000
Subject: [issue18489] IDLE Unit test for SearchEngine.py
In-Reply-To: <1374118219.91.0.797974191988.issue18489@psf.upfronthosting.co.za>
Message-ID: <1376893167.08.0.806709710766.issue18489@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

As with searchdialogbase tests, I get the following in the console every time I run the test file within idle.
'''
can't invoke "event" command:  application has been destroyed
    while executing
"event generate $w <<ThemeChanged>>"
    (procedure "ttk::ThemeChanged" line 6)
    invoked from within
"ttk::ThemeChanged"
'''
This seems like a bug somewhere, but where? Why is ttk involved?

When I applied the patch, the tests ran, but left two tk windows. I added the missing root.destroy() calls. I plan to separate the class methods that search a text widget into a separate test case (or more).

10 lines are not yet covered. 6 should be easy.

----------
assignee:  -> terry.reedy
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18489>
_______________________________________

From report at bugs.python.org  Mon Aug 19 08:19:42 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 19 Aug 2013 06:19:42 +0000
Subject: [issue18489] IDLE Unit test for SearchEngine.py
In-Reply-To: <1374118219.91.0.797974191988.issue18489@psf.upfronthosting.co.za>
Message-ID: <1376893182.28.0.123532069263.issue18489@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


Added file: http://bugs.python.org/file31369/18489-test_searchengine4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18489>
_______________________________________

From report at bugs.python.org  Mon Aug 19 09:05:08 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Aug 2013 07:05:08 +0000
Subject: [issue18761] Fix internal doc references for the email package
In-Reply-To: <1376682451.08.0.523486132403.issue18761@psf.upfronthosting.co.za>
Message-ID: <3cJR3S12WFz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 7a1534dba050 by Serhiy Storchaka in branch '3.3':
Issue #18761: Improved cross-references in email documentation.
http://hg.python.org/cpython/rev/7a1534dba050

New changeset 464eed5ddb2e by Serhiy Storchaka in branch 'default':
Issue #18761: Improved cross-references in email documentation.
http://hg.python.org/cpython/rev/464eed5ddb2e

New changeset 062533327ad2 by Serhiy Storchaka in branch '2.7':
Issue #18761: Improved cross-references in email documentation.
http://hg.python.org/cpython/rev/062533327ad2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18761>
_______________________________________

From report at bugs.python.org  Mon Aug 19 09:20:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 07:20:20 +0000
Subject: [issue18778] email docstrings and comments say about Unicode strings
Message-ID: <1376896820.36.0.260467198244.issue18778@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

email docstrings and comments uses the "Unicode string" term and refer to the unicode() built-in. In 3.x this should be corrected to "string" and "str()". Perhaps some code (for example coercing a charset name to Unicode) is not needed more.

----------
components: email
messages: 195605
nosy: barry, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: email docstrings and comments say about Unicode strings
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18778>
_______________________________________

From report at bugs.python.org  Mon Aug 19 09:22:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 07:22:21 +0000
Subject: [issue18761] Fix internal doc references for the email package
In-Reply-To: <1376682451.08.0.523486132403.issue18761@psf.upfronthosting.co.za>
Message-ID: <1376896941.43.0.892296872792.issue18761@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for the review.

----------
assignee: docs at python -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18761>
_______________________________________

From report at bugs.python.org  Mon Aug 19 09:33:02 2013
From: report at bugs.python.org (Freek Dijkstra)
Date: Mon, 19 Aug 2013 07:33:02 +0000
Subject: [issue17400] ipaddress.is_private needs to take into account of
 rfc6598
In-Reply-To: <1363052217.02.0.113831391012.issue17400@psf.upfronthosting.co.za>
Message-ID: <1376897582.01.0.726376526579.issue17400@psf.upfronthosting.co.za>


Freek Dijkstra added the comment:

I don't understand your remark "I think it would be pretty surprising for ipaddress to return True if it's not a network operator running the query."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17400>
_______________________________________

From report at bugs.python.org  Mon Aug 19 09:33:31 2013
From: report at bugs.python.org (Freek Dijkstra)
Date: Mon, 19 Aug 2013 07:33:31 +0000
Subject: [issue17400] ipaddress.is_private needs to take into account of
 rfc6598
In-Reply-To: <1363052217.02.0.113831391012.issue17400@psf.upfronthosting.co.za>
Message-ID: <1376897611.46.0.591012838888.issue17400@psf.upfronthosting.co.za>


Freek Dijkstra added the comment:

Edit: could you rephrase?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17400>
_______________________________________

From report at bugs.python.org  Mon Aug 19 09:40:00 2013
From: report at bugs.python.org (Alex Quinn)
Date: Mon, 19 Aug 2013 07:40:00 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
 2038 or greater on 32-bit platforms
In-Reply-To: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>
Message-ID: <1376898000.28.0.624733068148.issue5537@psf.upfronthosting.co.za>


Alex Quinn added the comment:

This bug still exists in Python 2.7.3 32-bit on Linux.

I wonder if this might be because the patch (posted 2011-02-18) used utcfromtimestamp().  datetime.datetime.utcfromtimestamp(2**32) will fail on 32-bit systems.

The bug does NOT exist in Python 2.7.3 32-bit on Windows (64-bit OS).

==========================================
32-BIT PYTHON ON 32-BIT LINUX
------------------------------------------
$ python -c "import sys, cookielib; print sys.version; print cookielib.time2isoz(2322923767)"
2.7.3 (default, Apr 10 2013, 05:46:21) 
[GCC 4.6.3]
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/cookielib.py", line 99, in time2isoz
    year, mon, mday, hour, min, sec = time.gmtime(t)[:6]
ValueError: timestamp out of range for platform time_t
==========================================


==========================================
64-BIT PYTHON ON 64-BIT LINUX
------------------------------------------
$ python -c "import sys, cookielib; print sys.version; print cookielib.time2isoz(2322923767)"
2.7.3 (default, Aug  3 2012, 17:21:07)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)]
2043-08-11 16:36:07Z
==========================================


==========================================
32-BIT PYTHON ON 64-BIT WINDOWS
------------------------------------------
C:\>python -c "import sys, cookielib; print sys.version; print cookielib.time2isoz(2322923767)"
2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)]
2043-08-11 16:36:07Z
==========================================

----------
nosy: +Alex Quinn
Added file: http://bugs.python.org/file31370/monkey_patch_cookielib_time2isoz.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Mon Aug 19 09:44:41 2013
From: report at bugs.python.org (Alex Quinn)
Date: Mon, 19 Aug 2013 07:44:41 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
 2038 or greater on 32-bit platforms
In-Reply-To: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>
Message-ID: <1376898281.55.0.543423670833.issue5537@psf.upfronthosting.co.za>


Alex Quinn added the comment:

For those who are affected by this bug, here's a snippet to monkey-patch cookielib on any Python 2.4 to 2.7.

A more complete version of this was attached to my message a moment ago.

==========================================
import cookielib
try:
    cookielib.time2isoz(2**32)
except ValueError:
    from datetime import datetime, timedelta
    def time2isoz(t=None):
        if t is None:
            dt = datetime.now()
        else:
            dt = datetime.utcfromtimestamp(0) + timedelta(seconds=int(t))
        return "%04d-%02d-%02d %02d:%02d:%02dZ"%\
                (dt.year, dt.month, dt.day, dt.hour, dt.minute, dt.second)
    cookielib.time2isoz = time2isoz
==========================================

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Mon Aug 19 09:45:16 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 19 Aug 2013 07:45:16 +0000
Subject: [issue18779] Misleading documentations and comments in regular
 expression about alphanumerics and underscore
Message-ID: <1376898316.85.0.0813282739116.issue18779@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

According to:

http://oald8.oxfordlearnersdictionaries.com/dictionary/alphanumeric
http://en.wikipedia.org/wiki/Alphanumeric

Alphanumeric is defined as [A-Za-z0-9]. Underscore (_) is not one of them. One of the documentation in Python (Doc/tutorial/stdlib2.rst) differentiates them very clearly:

"The format uses placeholder names formed by ``$`` with valid Python identifiers
(alphanumeric characters and underscores).  Surrounding the placeholder with
braces allows it to be followed by more alphanumeric letters with no intervening
spaces.  Writing ``$$`` creates a single escaped ``$``::"

Yet, in documentations as well as comments in regex, we implicitely assumes underscore belongs to alphanumeric.

Explicit is better than implicit!

Attached the patch to differentiate alphanumeric and underscore in documentations and comments in regex.

This is important in case someone is confused with this code:
>>> import re
>>> re.split('\W', 'haha$hihi*huhu_hehe hoho')
['haha', 'hihi', 'huhu_hehe', 'hoho']

On the side note:
In Python code base, sometimes we write "alphanumerics" and "underscores", yet sometimes we write "alphanumeric characters" and "underscore characters". Which one again is the true way?

----------
assignee: docs at python
components: Documentation
files: fix_alphanumeric_and_underscore_doc_in_regex.patch
keywords: patch
messages: 195611
nosy: akuchling, docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Misleading documentations and comments in regular expression about alphanumerics and underscore
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31371/fix_alphanumeric_and_underscore_doc_in_regex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18779>
_______________________________________

From report at bugs.python.org  Mon Aug 19 10:04:35 2013
From: report at bugs.python.org (Freek Dijkstra)
Date: Mon, 19 Aug 2013 08:04:35 +0000
Subject: [issue17400] ipaddress.is_private needs to take into account of
 rfc6598
In-Reply-To: <1363052217.02.0.113831391012.issue17400@psf.upfronthosting.co.za>
Message-ID: <1376899475.23.0.552905503884.issue17400@psf.upfronthosting.co.za>


Freek Dijkstra added the comment:

A bit odd questions: What is the is_private() function intended to accomplish?

I have been wondering what is_private() means, and how users of the library are going to use this function. I've actually failed to come up with any sensible use-case with the current implementation. So in the current state, without the modifications, my vote would be to remove the method, as it is more likely to add confusion than the be of a particular use.

The most useful method (which I originally thought it was meant to do) is a function that indicates if a certain IP range is NATted (only an indication, since it requires a network to reliable test). However, that's not what the current function entails: it misses the 100.64.0.0/10 range, which is NATted, but includes the fc00::/7 unique local block, which is not NATted.

I would be all in favour of such a is_natted() function, but that's not what this is.

The is_private() function also does not simply list "private" IP addresses, when looking at the formal IETF definitions, since it includes fc00::/7, which are unique local addresses, which in practice used in a rather different way: IPv4 private IP addresses are often NATted (and routed after translation), while IPv6 unique local addresses are typically used for local non-routed networks.

Also, the is_private() function does not list all non-globally assigned addresses. That should includes a lot more ranges, as listed on http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml and http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml.

So far, the is_private() function seems to return True for addresses which are:
* non-globally assigned (as opposed to regular unicast and multicast addresses)
* available for manual assignment (as opposed to link-local addresses)
* may be assigned by end-sites, but not by ISPs (as opposed to shared IP addresses and the small DS-Lite block)
* is not intended for benchmarking purposes (as opposed to benchmarking IP addresses)

Frankly, I wonder if this very particular information of enough interest to warrant a function on its own.

In that case, I much rather see more generic (and hopefully more useful) functions such as is_natted() and for is_global(), is_forwardable() and is_reserved(), as defined by IANA.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17400>
_______________________________________

From report at bugs.python.org  Mon Aug 19 11:15:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 09:15:36 +0000
Subject: [issue18438] Obsolete url in comment inside decimal module
In-Reply-To: <1373686911.48.0.750703855786.issue18438@psf.upfronthosting.co.za>
Message-ID: <1376903736.22.0.908045090843.issue18438@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +facundobatista, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18438>
_______________________________________

From report at bugs.python.org  Mon Aug 19 11:25:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Aug 2013 09:25:40 +0000
Subject: [issue18777] Cannot compile _ssl.c using openssl > 1.0
In-Reply-To: <1376890287.78.0.562230025847.issue18777@psf.upfronthosting.co.za>
Message-ID: <1376904340.22.0.00364324259373.issue18777@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Rather than removing the call to CRYPTO_set_id_callback, it seems we should replace it with CRYPTO_THREADID_set_callback:

? CRYPTO_THREADID and associated functions were introduced in OpenSSL 1.0.0 to replace (actually, deprecate) the previous CRYPTO_set_id_callback(), CRYPTO_get_id_callback(), and CRYPTO_thread_id() functions which assumed thread IDs to always be represented by 'unsigned long'. ?

http://www.openssl.org/docs/crypto/threads.html

----------
components: +Extension Modules
nosy: +christian.heimes, giampaolo.rodola, janssen, pitrou
priority: normal -> critical
stage:  -> needs patch
versions: +Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18777>
_______________________________________

From report at bugs.python.org  Mon Aug 19 11:27:12 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 19 Aug 2013 09:27:12 +0000
Subject: [issue18777] Cannot compile _ssl.c using openssl > 1.0
In-Reply-To: <1376890287.78.0.562230025847.issue18777@psf.upfronthosting.co.za>
Message-ID: <1376904432.95.0.916444661703.issue18777@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Something like that:

static void
_ssl_threadid_callback(CRYPTO_THREADID *id)
{
    CRYPTO_THREADID_set_numeric(id, PyThread_get_thread_ident());
}

CRYPTO_THREADID_set_callback(_ssl_threadid_callback);

----------
components:  -Extension Modules
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18777>
_______________________________________

From report at bugs.python.org  Mon Aug 19 11:28:53 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 19 Aug 2013 09:28:53 +0000
Subject: [issue18777] Cannot compile _ssl.c using openssl > 1.0
In-Reply-To: <1376890287.78.0.562230025847.issue18777@psf.upfronthosting.co.za>
Message-ID: <1376904533.11.0.175964224585.issue18777@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I'm going to work on a modified patch.

----------
assignee:  -> christian.heimes
components: +Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18777>
_______________________________________

From report at bugs.python.org  Mon Aug 19 11:30:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Aug 2013 09:30:21 +0000
Subject: [issue18777] Cannot compile _ssl.c using openssl > 1.0
In-Reply-To: <1376890287.78.0.562230025847.issue18777@psf.upfronthosting.co.za>
Message-ID: <1376904621.2.0.0704847802388.issue18777@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Indeed, only with the proper #ifdef's :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18777>
_______________________________________

From report at bugs.python.org  Mon Aug 19 11:31:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 09:31:47 +0000
Subject: [issue18779] Misleading documentations and comments in regular
 expression about alphanumerics and underscore
In-Reply-To: <1376898316.85.0.0813282739116.issue18779@psf.upfronthosting.co.za>
Message-ID: <1376904707.31.0.623004304179.issue18779@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Regular Expressions
nosy: +ezio.melotti, mrabarnett, pitrou
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18779>
_______________________________________

From report at bugs.python.org  Mon Aug 19 11:37:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Aug 2013 09:37:36 +0000
Subject: [issue18779] Misleading documentations and comments in regular
 expression HOWTO
In-Reply-To: <1376898316.85.0.0813282739116.issue18779@psf.upfronthosting.co.za>
Message-ID: <1376905056.34.0.97935452053.issue18779@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I was wondering which doc you were alluding it, before I noticed your patch is against the regex HOWTO.
The HOWTO seems quite outdated wrt. Python 3. For example "\w" is not equivalent to "[a-zA-Z0-9_]", anymore, except with the ASCII flag.

----------
title: Misleading documentations and comments in regular expression about alphanumerics and underscore -> Misleading documentations and comments in regular expression HOWTO

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18779>
_______________________________________

From report at bugs.python.org  Mon Aug 19 12:19:36 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 19 Aug 2013 10:19:36 +0000
Subject: [issue18779] Misleading documentations and comments in regular
 expression HOWTO
In-Reply-To: <1376898316.85.0.0813282739116.issue18779@psf.upfronthosting.co.za>
Message-ID: <1376907576.3.0.437350024386.issue18779@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

In Lib/re.py, starting from line 77 (Python 3.4):

    \w       Matches any alphanumeric character; equivalent to [a-zA-Z0-9_]
             in bytes patterns or string patterns with the ASCII flag.
             In string patterns without the ASCII flag, it will match the
             range of Unicode alphanumeric characters (letters plus digits
             plus underscore).
             With LOCALE, it will match the set [0-9_] plus characters defined
             as letters for the current locale.

The prelude is "Matches any alphanumeric character;".

Yet, in any case (bytes, string patterns with ascii flag, string patterns without the ascii flag, strings with locale), the underscore is always included.

Then why don't we change the prelude to "Matches any alphanumeric character and underscore character;"? In the description we explain the alphanumeric depending on it's unicode or not can be [A-Za-z0-9] or wider than that.

The description is already okay but the prelude is misleading readers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18779>
_______________________________________

From report at bugs.python.org  Mon Aug 19 12:42:56 2013
From: report at bugs.python.org (Tal Einat)
Date: Mon, 19 Aug 2013 10:42:56 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376908976.23.0.512082694839.issue18771@psf.upfronthosting.co.za>


Tal Einat added the comment:

The following benchmarks were run with the second version of the patch (so2.diff), once before and once after.

OSX 10.8 on a Macbook Pro, 2.5 GHz Core i5, two cores each with 256kb L2 cache, 3MB L3 cache:

1.32% less time for first benchmark (7.07 before, 6.98 after)
1.31% less time for second benchmark (9.81 before, 9.68 after)

Ubuntu 12.10 64-bit, AMD Athlon II X2 250 Processor (3.0 GHz, 2MB L2 cache, 256KB total L1 per processor):

5% less time for first benchmark (13.6 before, 12.9 after)
11% less time for second benchmark (18.3 before, 16.3 after)

Win7 64-bit, Intel Xeon E3-1230 V2 (quad-core, 3.30GHz, 256kb L2 cache per core, 8MB L3 cache):

1.8% less time for first benchmark (3.90 before, 3.83 after)
3.5% less time for second benchmark (7.27 before, 7.02 after)

However, this processor has "Intel SmartCache", which as far as I can tell means one processor can use other processors' caches if they are inactive. So I ran the benchmarks again with 4x larger data sets (revised benchmark script attached):

3.8% less time for first benchmark (19.3 before, 18.6 after)
7.5% less time for second benchmark (33.1 before, 30.6 after)

----------
nosy: +taleinat
Added file: http://bugs.python.org/file31372/set_bench_smartcache.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Mon Aug 19 12:56:56 2013
From: report at bugs.python.org (Tal Einat)
Date: Mon, 19 Aug 2013 10:56:56 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376909816.16.0.495700658988.issue18771@psf.upfronthosting.co.za>


Tal Einat added the comment:

Because of the unusually low differences, I tried running the benchmarks again on the MacBook (OSX 10.8). The first time was actually with so.diff, this time was with so2.diff.

0.69% less time for first benchmark (7.30 before, 7.25 after)
8.08% less time for second benchmark (10.85 before, 9.97 after)

Strange...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Mon Aug 19 13:49:34 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 19 Aug 2013 11:49:34 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376912974.09.0.484217609975.issue18771@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz on Ubuntu 13.04 X86_64 with GCC 4.7.3

1MB L2 cache test: 11.33sec / 10.83sec (4.4% faster)
8Mb L3 cache test: 22.16sec / 19.67sec (11% faster)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Mon Aug 19 14:01:22 2013
From: report at bugs.python.org (Tal Einat)
Date: Mon, 19 Aug 2013 12:01:22 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376913682.74.0.9111108446.issue18771@psf.upfronthosting.co.za>


Tal Einat added the comment:

Sorry to be pedantic, but while 19.67sec is about 11.2% less than 22.16sec, it is actually about 12.6% faster (22.16/19.67 - 1).

Regardless, that's a good result! And I'm happy that the modified benchmark is useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Mon Aug 19 14:10:51 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 19 Aug 2013 12:10:51 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376914251.45.0.718832198517.issue18771@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Oh *curse*, you are right. Why do I always confuse the order? :|

It looks like the performance boost increases with CPU cache size as well as the CPU's generation. The i7-4770K box at work is less than a week old. The CPU is currently the fast desktop CPU from Intel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Mon Aug 19 14:28:00 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Aug 2013 12:28:00 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
 iterable)
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1376915280.15.0.93554117547.issue18652@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, now I have a place in the non-test email code where using this would lead to easier-to-read code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18652>
_______________________________________

From report at bugs.python.org  Mon Aug 19 14:34:06 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Aug 2013 12:34:06 +0000
Subject: [issue18778] email docstrings and comments say about Unicode strings
In-Reply-To: <1376896820.36.0.260467198244.issue18778@psf.upfronthosting.co.za>
Message-ID: <1376915646.98.0.327124755519.issue18778@psf.upfronthosting.co.za>


R. David Murray added the comment:

If you mean the code in Charset's __init__, if you change that you'll have backward compatibility issues.  As the code currently stands it is legal to pass in a charset name that is bytes.  And the string path of that if checks that it contains only ASCII characters, a check that is also still required.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18778>
_______________________________________

From report at bugs.python.org  Mon Aug 19 14:34:36 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Aug 2013 12:34:36 +0000
Subject: [issue18778] email docstrings and comments say about Unicode strings
In-Reply-To: <1376896820.36.0.260467198244.issue18778@psf.upfronthosting.co.za>
Message-ID: <1376915676.75.0.234561856876.issue18778@psf.upfronthosting.co.za>


R. David Murray added the comment:

The comment, however, is clearly no longer appropriate :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18778>
_______________________________________

From report at bugs.python.org  Mon Aug 19 14:39:58 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Aug 2013 12:39:58 +0000
Subject: [issue18779] Misleading documentations and comments in regular
 expression HOWTO
In-Reply-To: <1376898316.85.0.0813282739116.issue18779@psf.upfronthosting.co.za>
Message-ID: <1376915998.68.0.437880445223.issue18779@psf.upfronthosting.co.za>


R. David Murray added the comment:

The answer to the question about "alphanumerics" versus "alphanumeric characters" is that is is mostly likely context-dependent, so I'd have to see particular examples to say which I though read better.  So, there is no One True Answer for this question, I think.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18779>
_______________________________________

From report at bugs.python.org  Mon Aug 19 14:45:38 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 19 Aug 2013 12:45:38 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376916338.02.0.276331604909.issue18738@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Oh, I don't feel my time has been wasted. Where else can I have a discussion of __format__?

With this patch, given this:

class UpperString(str):
  def __format__(self, fmt):
    return str.__format__(self, fmt).upper()

class UpperEnum(UpperString, Enum):
  pass

class S(UpperEnum):
  a = 'a'
  b = 'b'

this gives the (to me) surprising results of:

>>> format(S.a)
'S.a'
>>> format(S.a, '10')
'S.a       '
>>> format(S.a, '10s')
'A         '

I'd expect this to always use UpperString.__format__, since it understands all str format specs.

And before you say UpperString is contrived, I've used classes like it in the past: they're just like a string, but the __format__ method does something special after calling through to str.__format__. 

Which is why I think __format__ has to go in the derived type (IntEnum, in the originally reported case): only it can decide whether to call str.__format__ or the mix-in class's __format__.

Now, whether or not Enum needs to support such classes with specialized __format___, I can't say. I suppose it's not super-important. But it will be difficult to explain all of this.

Also, the patch give this:

>>> class E(IntEnum):
...   one = 1
...   two = 2
... 
>>> format(E.one)
'E.one'
>>> format(E.one, 's')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/eric/local/python/cpython/Lib/enum.py", line 463, in __format__
    return obj.__format__(val, format_spec)
ValueError: Unknown format code 's' for object of type 'int'

I can't format it using the 's' presentation type, despite the fact it looks like a string. I think you need to add 's' to your _remove_plain_format_chars.

And consider this valid (but arguably pathological) code:

>>> format(datetime.datetime.now(), '10')
'10'

Despite this being a valid datetime format spec, your code would consider it a str spec.

tl;dr: I think __format__ belongs in the class that understands how the subclass handles format specs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Mon Aug 19 15:04:45 2013
From: report at bugs.python.org (Giacomo Alzetta)
Date: Mon, 19 Aug 2013 13:04:45 +0000
Subject: [issue18750] '' % [1] doesn't fail
In-Reply-To: <1376586656.31.0.488715338617.issue18750@psf.upfronthosting.co.za>
Message-ID: <1376917485.3.0.967725176304.issue18750@psf.upfronthosting.co.za>


Giacomo Alzetta added the comment:

Note that the documentation for formatting with %, found here: http://docs.python.org/2/library/stdtypes.html#string-formatting-operations,  states:

"""
If format requires a single argument, values may be a single non-tuple object. [5] Otherwise, values must be a tuple with exactly the number of items specified by the format string, or a single mapping object (for example, a dictionary)."""

Note how it explicitly states that in an expression: format % value there are two different cases:

 - If format contains *exactly one* format specifier, then value can be any non-tuple item and it will be formatted as is. Otherwise, value MUST be either tuple or a mapping.

In your example '' contains 0 format specifiers, hence you MUST use either a tuple or a dict. Any other object triggers "undefined behaviour"(in particular depending on whether the object define __geitem__ or not the formatting might or might not raise an exception etc.)

AFAIK only few people know this, hence changing the code could potentially break a lot of code for apparently no reason.
Since people should start to move to str.format instead of % this wart may not be worth fixing.

----------
nosy: +bakuriu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18750>
_______________________________________

From report at bugs.python.org  Mon Aug 19 15:15:55 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Mon, 19 Aug 2013 13:15:55 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1376884746.55.0.0278802992198.issue18606@psf.upfronthosting.co.za>
Message-ID: <CAHVvXxSoDxb2MWeQfzRdBhFHGj-f3CAfPs0BHdGSVLwbrsZH9A@mail.gmail.com>


Oscar Benjamin added the comment:

I've just checked over the new patch and it all looks good to me apart
from one quibble.

It is documented that statistics.sum() will respect rounding errors
due to decimal context (returning the same result that sum() would). I
would prefer it if statistics.sum would use compensated summation with
Decimals since in my view they are a floating point number
representation and are subject to arithmetic rounding error in the
same way as floats. I expect that the implementation of sum() will
change but it would be good to at least avoid documenting this IMO
undesirable behaviour.

So with the current implementation I can do:

>>> from decimal import Decimal as D, localcontext, Context, ROUND_DOWN
>>> data = [D("0.1375"), D("0.2108"), D("0.3061"), D("0.0419")]
>>> print(statistics.variance(data))
0.01252909583333333333333333333
>>> with localcontext() as ctx:
...     ctx.prec = 2
...     ctx.rounding = ROUND_DOWN
...     print(statistics.variance(data))
...
0.010

The final result is not accurate to 2 d.p. rounded down. This is
because the decimal context has affected all intermediate computations
not just the final result. Why would anyone prefer this behaviour over
an implementation that could compensate for rounding errors and return
a more accurate result?

If statistics.sum and statistics.add_partial are modified in such a
way that they use the same compensated algorithm for Decimals as they
would for floats then you can have the following:

>>> statistics.sum([D('-1e50'), D('1'), D('1e50')])
Decimal('1')

whereas it currently does:

>>> statistics.sum([D('-1e50'), D('1'), D('1e50')])
Decimal('0E+23')
>>> statistics.sum([D('-1e50'), D('1'), D('1e50')]) == 0
True

It still doesn't fix the variance calculation but I'm not sure exactly
how to do better than the current implementation for that. Either way
though I don't think the current behaviour should be a documented
guarantee. The meaning of "honouring the context" implies using a
specific sum algorithm, since an alternative algorithm would give a
different result and I don't think you should constrain yourself in
that way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Aug 19 16:10:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 14:10:34 +0000
Subject: [issue18780] SystemError when formatting int subclass
Message-ID: <1376921434.69.0.557024484243.issue18780@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> class I(int):
...     def __str__(self):
...         return 'spam'
... 
>>> '%i' % (I(42),)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/unicodeobject.c:13595: bad argument to internal function

This issue is related to issue18738 and will be fixed when use PyNumber_ToBase() for any int subclass (not only for bool).

----------
messages: 195631
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: SystemError when formatting int subclass
type: crash
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18780>
_______________________________________

From report at bugs.python.org  Mon Aug 19 16:13:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 14:13:28 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1376921608.43.0.594820718492.issue18738@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For C-style formatting see also issue18780.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Mon Aug 19 16:17:49 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Aug 2013 14:17:49 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376921869.86.0.122472208778.issue18771@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Wow, thanks for running these tests and posting the results :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Mon Aug 19 16:36:16 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Aug 2013 14:36:16 +0000
Subject: [issue18780] SystemError when formatting int subclass
In-Reply-To: <1376921434.69.0.557024484243.issue18780@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYMhygfJSsXPdCd8spwvNPHyOTv4Tgutxq0=vCYCbVtGw@mail.gmail.com>


STINNER Victor added the comment:

formatlong() should copy the string if Py_REFCNT(str) != 1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18780>
_______________________________________

From report at bugs.python.org  Mon Aug 19 16:39:09 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Aug 2013 14:39:09 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <3cJd7J11R9z7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset a887596b841f by Raymond Hettinger in branch 'default':
Issue18771:  Reduce the cost of hash collisions for set objects.
http://hg.python.org/cpython/rev/a887596b841f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Mon Aug 19 16:41:13 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Aug 2013 14:41:13 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376923273.52.0.787694970802.issue18771@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Mon Aug 19 16:51:58 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 19 Aug 2013 14:51:58 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376923918.6.0.323660413842.issue18771@psf.upfronthosting.co.za>


Christian Heimes added the comment:

How about a Misc/NEWS and a Doc/whatsnew/3.4 entry, too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Mon Aug 19 16:53:08 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Aug 2013 14:53:08 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376923918.6.0.323660413842.issue18771@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb16E=RPKmDABftn14N1MQAJ8M6Eok4SM1TPkhMAdTwKA@mail.gmail.com>


STINNER Victor added the comment:

This optimization cannot be applied to the dict type?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Mon Aug 19 17:05:40 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 19 Aug 2013 15:05:40 +0000
Subject: [issue18781] re.escape escapes underscore (Python 2.7)
Message-ID: <1376924740.46.0.92680141708.issue18781@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

$ ./python --version
Python 2.7.5+
$ ./python
Python 2.7.5+ (2.7:062533327ad2, Aug 19 2013, 22:44:52) 
[GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.escape('_')
'\\_'

Python 3.3 and 3.4 got it right and don't escape the underscore.

Because many people are still doing their livelihoods with Python 2.7 and I am a compassionate person, here is the patch to fix the bug in Python 2.7.

----------
components: Regular Expressions
files: dont_escape_underscore_in_regex_27.patch
keywords: patch
messages: 195638
nosy: ezio.melotti, mrabarnett, vajrasky
priority: normal
severity: normal
status: open
title: re.escape escapes underscore (Python 2.7)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31373/dont_escape_underscore_in_regex_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18781>
_______________________________________

From report at bugs.python.org  Mon Aug 19 17:17:54 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 19 Aug 2013 15:17:54 +0000
Subject: [issue18777] Cannot compile _ssl.c using openssl > 1.0
In-Reply-To: <1376890287.78.0.562230025847.issue18777@psf.upfronthosting.co.za>
Message-ID: <1376925474.81.0.662496542898.issue18777@psf.upfronthosting.co.za>


Christian Heimes added the comment:

patch

----------
Added file: http://bugs.python.org/file31374/18777.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18777>
_______________________________________

From report at bugs.python.org  Mon Aug 19 17:18:33 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Aug 2013 15:18:33 +0000
Subject: [issue18781] re.escape escapes underscore (Python 2.7)
In-Reply-To: <1376924740.46.0.92680141708.issue18781@psf.upfronthosting.co.za>
Message-ID: <1376925513.96.0.685009861172.issue18781@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This was considered a new feature when it was added in 3.2 (see #2650), so it was not backported to 2.7 because -- even if it was a minor change -- it was not 100% backward compatible.

----------
assignee:  -> ezio.melotti
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18781>
_______________________________________

From report at bugs.python.org  Mon Aug 19 17:33:25 2013
From: report at bugs.python.org (Timothy O'Keefe)
Date: Mon, 19 Aug 2013 15:33:25 +0000
Subject: [issue18782] sqlite3 row factory and multiprocessing map
Message-ID: <1376926405.17.0.0447575429203.issue18782@psf.upfronthosting.co.za>


New submission from Timothy O'Keefe:

If you run this code, you will get a segfault. If you a) remove the row factory from the following code or b) use the standard library map() instead of multiprocessing.Pool.map, then the code does not crash.

#!/usr/bin/env python

import sqlite3
import multiprocessing as mp

def main():
    ## --- create a database
    conn = sqlite3.connect(':memory:')
    conn.row_factory = sqlite3.Row
    c = conn.cursor()

    ## --- create example table similar to python docs
    c.execute('''CREATE TABLE stocks (date text, trans text, symbol text, qty real, price real)''')
    c.execute("INSERT INTO stocks VALUES ('2006-01-05','BUY','GOOG',100,869.29)")
    c.execute("INSERT INTO stocks VALUES ('1992-01-06','SELL','AAPL',20,512.99)")
    c.execute("SELECT * FROM stocks")

    ## --- map fun over cursor iterable (fun does nothing)
    pool = mp.Pool(processes=mp.cpu_count())
    features = pool.map(fun, c)

def fun(row):
    return row

if __name__ == "__main__":
    main()

----------
messages: 195641
nosy: tokeefe
priority: normal
severity: normal
status: open
title: sqlite3 row factory and multiprocessing map
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18782>
_______________________________________

From report at bugs.python.org  Mon Aug 19 17:37:17 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Aug 2013 15:37:17 +0000
Subject: [issue18777] Cannot compile _ssl.c using openssl > 1.0
In-Reply-To: <1376890287.78.0.562230025847.issue18777@psf.upfronthosting.co.za>
Message-ID: <3cJfQP0vgxz7LjX@mail.python.org>


Roundup Robot added the comment:

New changeset f967ded6f9dd by Christian Heimes in branch '3.3':
Issue #18777: The ssl module now uses the new CRYPTO_THREADID API of
http://hg.python.org/cpython/rev/f967ded6f9dd

New changeset 28e68f4807a2 by Christian Heimes in branch 'default':
Issue #18777: The ssl module now uses the new CRYPTO_THREADID API of
http://hg.python.org/cpython/rev/28e68f4807a2

New changeset 5d691723bfbd by Christian Heimes in branch '2.7':
Issue #18777: The ssl module now uses the new CRYPTO_THREADID API of
http://hg.python.org/cpython/rev/5d691723bfbd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18777>
_______________________________________

From report at bugs.python.org  Mon Aug 19 17:39:54 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 19 Aug 2013 15:39:54 +0000
Subject: [issue18777] Cannot compile _ssl.c using openssl > 1.0
In-Reply-To: <1376890287.78.0.562230025847.issue18777@psf.upfronthosting.co.za>
Message-ID: <1376926794.45.0.365987428283.issue18777@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18777>
_______________________________________

From report at bugs.python.org  Mon Aug 19 18:12:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Aug 2013 16:12:28 +0000
Subject: [issue18774] There is still last bit of GNU Pth code in signalmodule.c
In-Reply-To: <1376801880.96.0.197365143686.issue18774@psf.upfronthosting.co.za>
Message-ID: <3cJgBz4sFPz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset a02339bda413 by Raymond Hettinger in branch 'default':
Issue 18774:  Update news and whatsnew for the set optimizations
http://hg.python.org/cpython/rev/a02339bda413

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18774>
_______________________________________

From report at bugs.python.org  Mon Aug 19 18:17:29 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Aug 2013 16:17:29 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <1376929049.57.0.911985941608.issue18771@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Victor, this should also work for dictionaries as well.   Fundamentally, the concepts of loop-unrolling and exploiting cache locality should apply to any hash table implementation.

That said, the dicts are more complex than sets due to 1) storing the hash/key/value 2) key-sharing, and 3) different access patterns.  So, it will require more effort than just porting over the patch.  Feel free to open a new tracker item for that one.  It will take more work but will potentially have a much greater pay-off.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Mon Aug 19 18:24:01 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 19 Aug 2013 16:24:01 +0000
Subject: [issue17276] HMAC: deprecate default hash
In-Reply-To: <1361535402.96.0.618065106631.issue17276@psf.upfronthosting.co.za>
Message-ID: <1376929441.87.0.483716271905.issue17276@psf.upfronthosting.co.za>


Christian Heimes added the comment:

assertWarns() is much easier than the block I have copied and pasted. Thanks. :)

----------
Added file: http://bugs.python.org/file31375/17276-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17276>
_______________________________________

From report at bugs.python.org  Mon Aug 19 18:35:54 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 19 Aug 2013 16:35:54 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <CAHVvXxSoDxb2MWeQfzRdBhFHGj-f3CAfPs0BHdGSVLwbrsZH9A@mail.gmail.com>
Message-ID: <52124961.20503@pearwood.info>


Steven D'Aprano added the comment:

On 19/08/13 23:15, Oscar Benjamin wrote:

> So with the current implementation I can do:
>
>>>> from decimal import Decimal as D, localcontext, Context, ROUND_DOWN
>>>> data = [D("0.1375"), D("0.2108"), D("0.3061"), D("0.0419")]
>>>> print(statistics.variance(data))
> 0.01252909583333333333333333333
>>>> with localcontext() as ctx:
> ...     ctx.prec = 2
> ...     ctx.rounding = ROUND_DOWN
> ...     print(statistics.variance(data))
> ...
> 0.010
>
> The final result is not accurate to 2 d.p. rounded down. This is
> because the decimal context has affected all intermediate computations
> not just the final result.

Yes. But that's the whole point of setting the context to always round down. If summation didn't always round down, it would be a bug.

If you set the precision to a higher value, you can avoid the need for compensated summation. I'm not prepared to pick and choose which contexts I'll honour. If I honour those with a high precision, I'll honour those with a low precision too. I'm not going to check the context, and if it is "too low" (according to whom?) set it higher.

>Why would anyone prefer this behaviour over
> an implementation that could compensate for rounding errors and return
> a more accurate result?

Because that's what the Decimal standard requires (as I understand it), and besides you might be trying to match calculations on some machine with a lower precision, or different rounding modes. Say, a pocket calculator, or a Cray, or something. Or demonstrating why rounding matters.

Perhaps it will cause less confusion if I add an example to show a use for higher precision as well.

> If statistics.sum and statistics.add_partial are modified in such a
> way that they use the same compensated algorithm for Decimals as they
> would for floats then you can have the following:
>
>>>> statistics.sum([D('-1e50'), D('1'), D('1e50')])
> Decimal('1')

statistics.sum can already do that:

py> with localcontext() as ctx:
...     ctx.prec = 50
...     x = statistics.sum([D('-1e50'), D('1'), D('1e50')])
...
py> x
Decimal('1')

I think the current behaviour is the right thing to do, but I appreciate the points you raise. I'd love to hear from someone who understands the Decimal module better than I do and can confirm that the current behaviour is in the spirit of the Decimal module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Aug 19 18:52:03 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 19 Aug 2013 16:52:03 +0000
Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has
 /system/bin/sh
In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za>
Message-ID: <1376931123.14.0.081004635972.issue16255@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
dependencies: +add function to os module for getting path to default shell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16255>
_______________________________________

From report at bugs.python.org  Mon Aug 19 18:52:27 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 19 Aug 2013 16:52:27 +0000
Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has
 /system/bin/sh
In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za>
Message-ID: <1376931147.11.0.700731302557.issue16255@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
versions:  -Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16255>
_______________________________________

From report at bugs.python.org  Mon Aug 19 19:12:34 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Mon, 19 Aug 2013 17:12:34 +0000
Subject: [issue17560] problem using multiprocessing with really big objects?
In-Reply-To: <1364399521.2.0.696890688109.issue17560@psf.upfronthosting.co.za>
Message-ID: <1376932354.42.0.166286509501.issue17560@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

I have implemented a custom subclass of the multiprocessing Pool to be able plug custom pickling strategy for this specific use case in joblib:

https://github.com/joblib/joblib/blob/master/joblib/pool.py#L327

In particular it can:

- detect mmap-backed numpy
- transform large memory backed numpy arrays into numpy.memmap instances prior to pickling using the /dev/shm partition when available or TMPDIR otherwise.

Here is some doc: https://github.com/joblib/joblib/blob/master/doc/parallel_numpy.rst

I could submit the part that makes it possible to customize the picklers of multiprocessing.pool.Pool instance to the standard library if people are interested.

The numpy specific stuff would stay in third party projects such as joblib but at least that would make it easier for people to plug their own optimizations without having to override half of the multiprocessing class hierarchy.

----------
nosy: +Olivier.Grisel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17560>
_______________________________________

From report at bugs.python.org  Mon Aug 19 19:14:53 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Mon, 19 Aug 2013 17:14:53 +0000
Subject: [issue17560] problem using multiprocessing with really big objects?
In-Reply-To: <1364399521.2.0.696890688109.issue17560@psf.upfronthosting.co.za>
Message-ID: <1376932493.51.0.622732358644.issue17560@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

I forgot to end a sentence in my last comment:

- detect mmap-backed numpy

should read:

- detect mmap-backed numpy arrays and pickle only the filename and other buffer metadata to reconstruct a mmap-backed array in the worker processes instead of copying the data around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17560>
_______________________________________

From report at bugs.python.org  Mon Aug 19 19:26:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Aug 2013 17:26:12 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1376933172.26.0.676126245957.issue18772@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Raymond, if you don't have time for this issue, I'd prefer your patch to be reverted. It hasn't been proven to accelerate any benchmark, and the problems it triggered need solving.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Mon Aug 19 19:35:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 17:35:24 +0000
Subject: [issue18783] No more refer to Python "long"
Message-ID: <1376933723.97.0.818285065385.issue18783@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which removes (almost all) mentions of Python long type from docstrings, exception messages and comments.

----------
files: no_long.patch
keywords: patch
messages: 195650
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: No more refer to Python "long"
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31376/no_long.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18783>
_______________________________________

From report at bugs.python.org  Mon Aug 19 19:40:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 17:40:39 +0000
Subject: [issue18778] email docstrings and comments say about Unicode strings
In-Reply-To: <1376896820.36.0.260467198244.issue18778@psf.upfronthosting.co.za>
Message-ID: <1376934039.74.0.400321205713.issue18778@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It is just unusual to accept a bytes object as a charset name. Of course if it is needed for Charset's __init__ the code should not be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18778>
_______________________________________

From report at bugs.python.org  Mon Aug 19 19:48:54 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 19 Aug 2013 17:48:54 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a traceback
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1376934534.86.0.525419590076.issue16396@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

I think it's the opposite: when Unix support was added to ctypes, 'import ctypes.wintypes' was not considered. By that logic, the patch is a new feature.
IMO "historical" arguments are moot :-)

I agree with the conclusion tough: the patch will not break code that carefully catches ValueError, and so it suitable for 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Mon Aug 19 19:49:28 2013
From: report at bugs.python.org (Evgeny Sologubov)
Date: Mon, 19 Aug 2013 17:49:28 +0000
Subject: [issue18784] minor uuid.py loading optimization
Message-ID: <1376934568.82.0.658591354908.issue18784@psf.upfronthosting.co.za>


New submission from Evgeny Sologubov:

Please see the patch attached.
It quite is primitive and self-explanatory: the code wouldn't attempt to load *libc* via ctypes.CDLL, if all necessary functions are already found in *libuuid*.

This patch also can serve as a work-around solution to issue #17213 
(which I encountered on cygwin+python27)

----------
components: Library (Lib), Windows, ctypes
files: uuid.patch
keywords: patch
messages: 195653
nosy: eugals
priority: normal
severity: normal
status: open
title: minor uuid.py loading optimization
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file31377/uuid.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18784>
_______________________________________

From report at bugs.python.org  Mon Aug 19 19:53:26 2013
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 19 Aug 2013 17:53:26 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1376934806.74.0.495274687757.issue18772@psf.upfronthosting.co.za>


Dave Malcolm added the comment:

Antoine's patch looks reasonable to me, FWIW.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Mon Aug 19 20:03:04 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Aug 2013 18:03:04 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1376935384.53.0.814304672868.issue18772@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Mon Aug 19 20:09:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Aug 2013 18:09:48 +0000
Subject: [issue18784] minor uuid.py loading optimization
In-Reply-To: <1376934568.82.0.658591354908.issue18784@psf.upfronthosting.co.za>
Message-ID: <1376935788.81.0.593698756799.issue18784@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18784>
_______________________________________

From report at bugs.python.org  Mon Aug 19 20:45:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 18:45:44 +0000
Subject: [issue17998] internal error in regular expression engine
In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za>
Message-ID: <1376937944.73.0.72183836064.issue17998@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For other related issues see issue18672 and issue18684.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17998>
_______________________________________

From report at bugs.python.org  Mon Aug 19 20:52:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 18:52:27 +0000
Subject: [issue18750] '' % [1] doesn't fail
In-Reply-To: <1376586656.31.0.488715338617.issue18750@psf.upfronthosting.co.za>
Message-ID: <1376938347.99.0.0122728002906.issue18750@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Since people should start to move to str.format instead of % this wart may not be worth fixing.

>>> ''.format_map([1])
''

However I agree that this is not worth fixing.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18750>
_______________________________________

From report at bugs.python.org  Mon Aug 19 20:53:43 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 19 Aug 2013 18:53:43 +0000
Subject: [issue17560] problem using multiprocessing with really big objects?
In-Reply-To: <1364399521.2.0.696890688109.issue17560@psf.upfronthosting.co.za>
Message-ID: <1376938423.42.0.935004786492.issue17560@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> I could submit the part that makes it possible to customize the picklers 
> of multiprocessing.pool.Pool instance to the standard library if people 
> are interested.

2.7 and 3.3 are in bugfix mode now, so they will not change.

In 3.3 you can do

    from multiprocessing.forking import ForkingPickler
    ForkingPickler.register(MyType, reduce_MyType)

Is this sufficient for you needs?  This is private (and its definition has moved in 3.4) but it could be made public.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17560>
_______________________________________

From report at bugs.python.org  Mon Aug 19 21:16:53 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Aug 2013 19:16:53 +0000
Subject: [issue18778] email docstrings and comments say about Unicode strings
In-Reply-To: <1376896820.36.0.260467198244.issue18778@psf.upfronthosting.co.za>
Message-ID: <1376939813.34.0.208223371832.issue18778@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yeah, if I could have a do-over of the 3.0 port, I'd probably drop the acceptance of byte strings.  Maybe we can deprecate it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18778>
_______________________________________

From report at bugs.python.org  Mon Aug 19 21:53:22 2013
From: report at bugs.python.org (ali)
Date: Mon, 19 Aug 2013 19:53:22 +0000
Subject: [issue15809] IDLE console uses incorrect encoding.
In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za>
Message-ID: <1376942002.31.0.993783013204.issue15809@psf.upfronthosting.co.za>


Changes by ali <mr.dalba at gmail.com>:


----------
nosy: +irdb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15809>
_______________________________________

From report at bugs.python.org  Mon Aug 19 21:57:44 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Aug 2013 19:57:44 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1376942264.41.0.0961806580571.issue18772@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This is a bummer.  The internal comments made the claim that any python object would suffice.   The use of a unicode object was unfortunate because it isn't guaranteed to be unique (i.e. a user can legitimately store "<dummy>" as a valid member of a set).  As a consequence, the tight loops for the hash table lookups had to add special case checks for the dummy variables.  Eliminating those checks made the generated code shorter and faster.  It also paved the way for a future optimization for non-debug builds to eliminate all non-essential increfs and decrefs to the dummy object.

In other words, we're paying a price for the dummy object being printable as a string.

Antoine, thanks to the link to the python-dev discussion.  I hope we can come with a solution that doesn't involve going back to unicode objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Mon Aug 19 22:24:32 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Aug 2013 20:24:32 +0000
Subject: [issue18782] sqlite3 row factory and multiprocessing map
In-Reply-To: <1376926405.17.0.0447575429203.issue18782@psf.upfronthosting.co.za>
Message-ID: <1376943872.0.0.277430300537.issue18782@psf.upfronthosting.co.za>


Ned Deily added the comment:

What platform are you running on? Please run the following script in the same environment as you get the segfault and report the results.

#!/usr/bin/env python

import multiprocessing
import platform
import sqlite3
import sys

print(sys.version)
print(sqlite3.version)
print(sqlite3.sqlite_version)
print(multiprocessing.__version__)
print(multiprocessing.cpu_count())
print(platform.platform())

For what it's worth, I was not able to reproduce this behavior using several different environments.  Also, what happens if you add

    pool.close()
    pool.join()

following the pool.map call?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18782>
_______________________________________

From report at bugs.python.org  Mon Aug 19 22:30:24 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Aug 2013 20:30:24 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <3cJmwb24PwzRhf@mail.python.org>


Roundup Robot added the comment:

New changeset de049e9abdf7 by Serhiy Storchaka in branch '3.3':
Issue #18647: Correctly bound calculated min/max width of a subexpression.
http://hg.python.org/cpython/rev/de049e9abdf7

New changeset e47f2dc564bc by Serhiy Storchaka in branch 'default':
Issue #18647: Correctly bound calculated min/max width of a subexpression.
http://hg.python.org/cpython/rev/e47f2dc564bc

New changeset d10c287c200c by Serhiy Storchaka in branch '2.7':
Issue #18647: Correctly bound calculated min/max width of a subexpression.
http://hg.python.org/cpython/rev/d10c287c200c

New changeset 19ed2fbb8e6b by Serhiy Storchaka in branch '3.3':
Issue #18647: A regular expression in the doctest module rewritten so that
http://hg.python.org/cpython/rev/19ed2fbb8e6b

New changeset 8b24818c7327 by Serhiy Storchaka in branch 'default':
Issue #18647: A regular expression in the doctest module rewritten so that
http://hg.python.org/cpython/rev/8b24818c7327

New changeset c2dc99ec46bc by Serhiy Storchaka in branch '2.7':
Issue #18647: A regular expression in the doctest module rewritten so that
http://hg.python.org/cpython/rev/c2dc99ec46bc

New changeset 7ab07f15d78c by Serhiy Storchaka in branch '3.3':
Issue #2537: Remove breaked check which prevented valid regular expressions.
http://hg.python.org/cpython/rev/7ab07f15d78c

New changeset f4271cc2dfb5 by Serhiy Storchaka in branch 'default':
Issue #2537: Remove breaked check which prevented valid regular expressions.
http://hg.python.org/cpython/rev/f4271cc2dfb5

New changeset 7b867a46a8b4 by Serhiy Storchaka in branch '2.7':
Issue #2537: Remove breaked check which prevented valid regular expressions.
http://hg.python.org/cpython/rev/7b867a46a8b4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18647>
_______________________________________

From report at bugs.python.org  Mon Aug 19 22:30:24 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Aug 2013 20:30:24 +0000
Subject: [issue2537] re.compile(r'((x|y+)*)*') should fail
In-Reply-To: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>
Message-ID: <3cJmwc0K1GzRhf@mail.python.org>


Roundup Robot added the comment:

New changeset 7ab07f15d78c by Serhiy Storchaka in branch '3.3':
Issue #2537: Remove breaked check which prevented valid regular expressions.
http://hg.python.org/cpython/rev/7ab07f15d78c

New changeset f4271cc2dfb5 by Serhiy Storchaka in branch 'default':
Issue #2537: Remove breaked check which prevented valid regular expressions.
http://hg.python.org/cpython/rev/f4271cc2dfb5

New changeset 7b867a46a8b4 by Serhiy Storchaka in branch '2.7':
Issue #2537: Remove breaked check which prevented valid regular expressions.
http://hg.python.org/cpython/rev/7b867a46a8b4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2537>
_______________________________________

From report at bugs.python.org  Mon Aug 19 22:33:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 20:33:07 +0000
Subject: [issue1633953] re.compile("(.*$){1,4}", re.MULTILINE) fails
Message-ID: <1376944387.12.0.253504067105.issue1633953@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed in issue2537. See also issue18647.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> re.compile(r'((x|y+)*)*') should fail

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633953>
_______________________________________

From report at bugs.python.org  Mon Aug 19 22:43:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 20:43:29 +0000
Subject: [issue2537] re.compile(r'((x|y+)*)*') should not fail
In-Reply-To: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>
Message-ID: <1376945009.78.0.394688443179.issue2537@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This issue is a duplicate of issue1633953. See also issue18647. After some fixes in other parts of the re module this check has become even more invalid.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
title: re.compile(r'((x|y+)*)*') should fail -> re.compile(r'((x|y+)*)*') should not fail
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2537>
_______________________________________

From report at bugs.python.org  Mon Aug 19 22:43:39 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 19 Aug 2013 20:43:39 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1376945019.56.0.78825280255.issue18712@psf.upfronthosting.co.za>


Zachary Ware added the comment:

A lot of this discussion has flown a rather unfortunate distance over my head, especially since I've barely had time to follow it.  But it looks to me like--given the number of other places that do the same thing as operator.index currently does--there needs to be a simple way to do the right thing somewhere accessible, which probably means a builtin.

On the other hand, it seems to me like 'a.__index__()' *should* be "the right thing" to do, but I get the feeling that making that so would be an astronomically huge change without much real benefit and lots of opportunities to break everything.  I suspect I'm also missing something fundamental in why it's not the right thing to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Mon Aug 19 22:44:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 20:44:29 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1376945069.38.0.356965387024.issue18647@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18647>
_______________________________________

From report at bugs.python.org  Mon Aug 19 22:46:08 2013
From: report at bugs.python.org (Timothy O'Keefe)
Date: Mon, 19 Aug 2013 20:46:08 +0000
Subject: [issue18782] sqlite3 row factory and multiprocessing map
In-Reply-To: <1376926405.17.0.0447575429203.issue18782@psf.upfronthosting.co.za>
Message-ID: <1376945168.73.0.0223366994795.issue18782@psf.upfronthosting.co.za>


Timothy O'Keefe added the comment:

Could you change the dummy function to do something other than simply return the row? For example:

#!/usr/bin/env python

import sqlite3
import multiprocessing as mp

def main():
    ## --- create a database
    conn = sqlite3.connect(':memory:')
    conn.row_factory = sqlite3.Row
    c = conn.cursor()

    ## --- create example table similar to python docs
    c.execute('''CREATE TABLE stocks (date text, trans text, symbol text, qty real, price real)''')
    c.execute("INSERT INTO stocks VALUES ('2006-01-05','BUY','GOOG',100,869.29)")
    c.execute("INSERT INTO stocks VALUES ('1992-01-06','SELL','AAPL',20,512.99)")
    c.execute("SELECT * FROM stocks")

    ## --- map fun over cursor (fun does little to nothing)
    pool = mp.Pool(processes=mp.cpu_count())
    rows = pool.map(fun, c)

def fun(row):
    _ = len(row)
    return row

if __name__ == "__main__":
    main()

In this example the code simply hangs. For whatever reason, I can no longer provoke the segfault.

Regardless, there is something going on. Here are the results from the print statements you asked for:

2.7.2 (default, Oct 11 2012, 20:14:37) 
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)]
2.6.0
3.7.12
0.70a1
4
Darwin-12.4.0-x86_64-i386-64bit

I have also tried this on Ubuntu 12.04:

2.7.3 (default, Apr 10 2013, 06:20:15) 
[GCC 4.6.3]
2.6.0
3.7.9
0.70a1
4
Linux-3.2.0-24-generic-x86_64-with-Ubuntu-12.04-precise

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18782>
_______________________________________

From report at bugs.python.org  Mon Aug 19 22:53:26 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 19 Aug 2013 20:53:26 +0000
Subject: [issue18782] sqlite3 row factory and multiprocessing map
In-Reply-To: <1376926405.17.0.0447575429203.issue18782@psf.upfronthosting.co.za>
Message-ID: <1376945606.13.0.937882646018.issue18782@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

Adding the line

    features[0][0]

to the end of main() produces a segfault for me on Linux.

The FAQ for sqlite3 says that

    Under Unix, you should not carry an open SQLite database across a 
    fork() system call into the child process. Problems will result if 
    you do.

-- see http://www.sqlite.org/faq.html.  So assuming you are using Unix, this is probably not a Python bug.

(And anyway, I would not expect the pickling of row objects to work correctly.)

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18782>
_______________________________________

From report at bugs.python.org  Mon Aug 19 23:10:03 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Aug 2013 21:10:03 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1376946603.52.0.377257894827.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file31378/00df7fc6d2ef.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Mon Aug 19 23:14:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 21:14:46 +0000
Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010
In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za>
Message-ID: <1376946886.31.0.438324657015.issue13461@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13461>
_______________________________________

From report at bugs.python.org  Mon Aug 19 23:24:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Aug 2013 21:24:24 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
 directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1376947464.4.0.453228498276.issue7732@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The bug still fails on a regular basis on the Windows buildbots:

======================================================================
FAIL: test_bug7732 (test.test_imp.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\test_imp.py", line 285, in test_bug7732
    imp.find_module, support.TESTFN, ["."])
AssertionError: ImportError not raised by find_module

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Mon Aug 19 23:24:43 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Aug 2013 21:24:43 +0000
Subject: [issue18785] Add get_body and iter_attachments to provisional email
 API
Message-ID: <1376947482.78.0.757583569107.issue18785@psf.upfronthosting.co.za>


New submission from R. David Murray:

I'm working on completing the API changes for the email package for 3.4.  This means I'm adding some more stuff to the current provisional API, which I will then aim to make non-provisional in 3.5.

I've made a complete proposal to the email-sig, and have gotten some positive feedback but no detailed reviews yet.

One part of the new API proposal is independent of the rest, and I've documented that part and implemented it.  I'm posting the patch for that part.  The patch includes some of the documentation for the rest, though not all of it...you can ignore all the doc changes in the new doc page except for the docs for the three new methods implemented by the patch for the purposes of reviewing this patch, though of course feedback on the (incomplete) rest is welcome.

I'm posting this now because this part of the enhancement can be reviewed independently of the other changes.

Note: I'm aware that MIMEMessage duplicates the name of a class in the mime subpackage.  By the time I'm done that class will be deprecated (in 3.5).  I haven't got that approved by the SIG yet, though, so it may change :)

----------
components: email
files: get_body_iter_attachments.patch
keywords: patch
messages: 195669
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Add get_body and iter_attachments to provisional email API
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31379/get_body_iter_attachments.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18785>
_______________________________________

From report at bugs.python.org  Mon Aug 19 23:25:37 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Mon, 19 Aug 2013 21:25:37 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <52124961.20503@pearwood.info>
Message-ID: <CAHVvXxQtvOC_v1PPtYYjB0KcJfvQ_o=ToVek=VH=uLWmH5gGLA@mail.gmail.com>


Oscar Benjamin added the comment:

On 19 August 2013 17:35, Steven D'Aprano <report at bugs.python.org> wrote:
>
> Steven D'Aprano added the comment:
>
> On 19/08/13 23:15, Oscar Benjamin wrote:
>>
>> The final result is not accurate to 2 d.p. rounded down. This is
>> because the decimal context has affected all intermediate computations
>> not just the final result.
>
> Yes. But that's the whole point of setting the context to always round down. If summation didn't always round down, it would be a bug.

If individual binary summation (d1 + d2) didn't round down then that
would be a bug.

> If you set the precision to a higher value, you can avoid the need for compensated summation. I'm not prepared to pick and choose which contexts I'll honour. If I honour those with a high precision, I'll honour those with a low precision too. I'm not going to check the context, and if it is "too low" (according to whom?) set it higher.

I often write functions like this:

def compute_stuff(x):
    with localcontext() as ctx:
         ctx.prec +=2
         y = ... # Compute in higher precision
    return +y  # __pos__ reverts to the default precision

The final result is rounded according to the default context but the
intermediate computation is performed in such a way that the final
result is (hopefully) correct within its context. I'm not proposing
that you do that, just that you don't commit to respecting inaccurate
results.

>>Why would anyone prefer this behaviour over
>> an implementation that could compensate for rounding errors and return
>> a more accurate result?
>
> Because that's what the Decimal standard requires (as I understand it), and besides you might be trying to match calculations on some machine with a lower precision, or different rounding modes. Say, a pocket calculator, or a Cray, or something. Or demonstrating why rounding matters.

No that's not what the Decimal standard requires. Okay I haven't fully
read it but I am familiar with these standards and I've read a good
bit of IEEE-754. The standard places constrainst on low-level
arithmetic operations that you as an implementer of high-level
algorithms can use to ensure that your code is accurate.

Following your reasoning above I should say that math.fsum and your
statistics.sum are both in violation of IEEE-754 since
    fsum([a, b, c, d, e])
is not equivalent to
    ((((a+b)+c)+d)+e)
under the current rounding scheme. They are not in violation of the
standard: both functions use the guarantees of the standard to
guarantee their own accuracy. Both go to some lengths to avoid
producing output with the rounding errors that sum() would produce.

> I think the current behaviour is the right thing to do, but I appreciate the points you raise. I'd love to hear from someone who understands the Decimal module better than I do and can confirm that the current behaviour is in the spirit of the Decimal module.

I use the Decimal module for multi-precision real arithmetic. That may
not be the typical use-case but to me Decimal is a floating point type
just like float. Precisely the same reasoning that leads to fsum
applies to Decimal just as it does to float

(BTW I've posted on Rayomnd Hettinger's recipe a modification that
might make it work for Decimal but no reply yet.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Aug 19 23:26:49 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Mon, 19 Aug 2013 21:26:49 +0000
Subject: [issue17560] problem using multiprocessing with really big objects?
In-Reply-To: <1376938423.42.0.935004786492.issue17560@psf.upfronthosting.co.za>
Message-ID: <CAFvE7K53mkpji8ZMAjhbuA=BCCtu+DzQq0WjMRf9rtjCMQRAMQ@mail.gmail.com>


Olivier Grisel added the comment:

> In 3.3 you can do
>
>     from multiprocessing.forking import ForkingPickler
>     ForkingPickler.register(MyType, reduce_MyType)
>
> Is this sufficient for you needs?  This is private (and its definition has moved in 3.4) but it could be made public.

Indeed I forgot that the multiprocessing pickler was made already made
pluggable in Python 3.3. I needed backward compat for python 2.6 in
joblib hence I had to rewrite a bunch of the class hierarchy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17560>
_______________________________________

From report at bugs.python.org  Mon Aug 19 23:31:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Aug 2013 21:31:30 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
 directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <3cJpH55WJpzRrM@mail.python.org>


Roundup Robot added the comment:

New changeset 4f7845be9e23 by Antoine Pitrou in branch 'default':
Issue #7732: try to fix test_bug7732's flakiness on Windows by executing it in a fresh temporary directory.
http://hg.python.org/cpython/rev/4f7845be9e23

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Mon Aug 19 23:33:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Aug 2013 21:33:37 +0000
Subject: [issue18786] test_multiprocessing_spawn crashes under PowerLinux
Message-ID: <1376948017.66.0.62278437821.issue18786@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.x

[319/379] test_multiprocessing_spawn
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/semaphore_tracker.py:121: UserWarning: semaphore_tracker: There appear to be 2 leaked semaphores to clean up at shutdown
  len(cache))
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/semaphore_tracker.py:133: UserWarning: semaphore_tracker: '/mp-t89tlie_': [Errno 2] No such file or directory
  warnings.warn('semaphore_tracker: %r: %s' % (name, e))
make: *** [buildbottest] User defined signal 1
Process PoolWorker-777:
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/pool.py", line 123, in worker
    put((job, i, result))
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/queues.py", line 368, in put
    self._writer.send_bytes(obj)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py", line 202, in send_bytes
    self._send_bytes(m[offset:offset + size])
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py", line 401, in _send_bytes
    self._send(struct.pack("!i", n))
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py", line 371, in _send
    n = write(self._handle, buf)
BrokenPipeError: [Errno 32] Broken pipe

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/process.py", line 255, in _bootstrap
    self.run()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/process.py", line 92, in run
    self._target(*self._args, **self._kwargs)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/pool.py", line 128, in worker
    put((job, i, (False, wrapped)))
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/queues.py", line 368, in put
    self._writer.send_bytes(obj)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py", line 202, in send_bytes
    self._send_bytes(m[offset:offset + size])
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py", line 401, in _send_bytes
    self._send(struct.pack("!i", n))
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py", line 371, in _send
    n = write(self._handle, buf)
BrokenPipeError: [Errno 32] Broken pipe
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/semaphore_tracker.py:121: UserWarning: semaphore_tracker: There appear to be 4 leaked semaphores to clean up at shutdown
  len(cache))
program finished with exit code 2
elapsedTime=4624.019498

----------
assignee: sbt
components: Library (Lib), Tests
messages: 195673
nosy: David.Edelsohn, pitrou, sbt
priority: critical
severity: normal
status: open
title: test_multiprocessing_spawn crashes under PowerLinux
type: crash
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18786>
_______________________________________

From report at bugs.python.org  Mon Aug 19 23:41:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Aug 2013 21:41:20 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1376948480.52.0.983402832632.issue18571@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> make_inheritable() should ignore errpipe_write, instead of changing twice the inheritable flag of errpipe_write.

Done in the last patch (00df7fc6d2ef.diff).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Tue Aug 20 03:42:30 2013
From: report at bugs.python.org (Meador Inge)
Date: Tue, 20 Aug 2013 01:42:30 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a traceback
In-Reply-To: <1376309480.35.0.803170349404.issue16396@psf.upfronthosting.co.za>
Message-ID: <CAK1QoopOr=DLZNEg0g33yy1-B_CSxx58=LdMUJ_K8LCTiuv0Cg@mail.gmail.com>


Meador Inge added the comment:

On Mon, Aug 12, 2013 at 7:11 AM, Ezio Melotti <report at bugs.python.org>wrote:

> Even if the patch is applied only on 3.4, I would still like to see the
> ValueError turned into ImportError for 2.7/3.3.
>

Why not raise an ImportError for all versions?  I don't see how
'ctypes.wintypes' is ever actually useful on anything but Windows.
 Allowing it to successfully import on non-Windows systems seems misleading.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Tue Aug 20 04:22:06 2013
From: report at bugs.python.org (Todd Rovito)
Date: Tue, 20 Aug 2013 02:22:06 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1376965326.9.0.324500835394.issue18704@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Ezio,
   I think modern editors are expected to have this sort of functionality built into them [1].  XCode is simply amazing where it will pop up errors and quote the C99 standard [2].  We don't expect IDLE to have all that functionality but it seemed to us like it would be great to add pep8 or PyFlakes to IDLE.  It is possible we could create an extension but that would void Python's motto "batteries included".  In addition tools like pep8 and PyFlakes could be useful for other purposes as well.  JayKrish is checking with the authors of pep8 about license issues.  As always we will defer to the judgement of Core Developers and could pursue either option.  


[1] Wikipeida Microsoft Visual Studio, http://en.wikipedia.org/wiki/Microsoft_Visual_Studio#Code_editor
[2] XCode, http://en.wikipedia.org/wiki/XCode

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Tue Aug 20 04:30:51 2013
From: report at bugs.python.org (Todd Rovito)
Date: Tue, 20 Aug 2013 02:30:51 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1376965851.61.0.853461567654.issue18704@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Raymond,
   Would you prefer PyFlakes instead?  Try to consider IDLE being for beginners so they need all the help they can get.  Advanced users can always turn the extension off.  Thanks for your input.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Tue Aug 20 04:49:04 2013
From: report at bugs.python.org (Todd Rovito)
Date: Tue, 20 Aug 2013 02:49:04 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1376966944.77.0.172767396804.issue18704@psf.upfronthosting.co.za>


Changes by Todd Rovito <rovitotv at gmail.com>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Tue Aug 20 06:13:02 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 20 Aug 2013 04:13:02 +0000
Subject: [issue18787] Misleading error from getspnam function of spwd module
Message-ID: <1376971981.98.0.467831293927.issue18787@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

As root:

$ sudo python3
[sudo] password for ethan: 
Python 3.2.3 (default, Apr 10 2013, 05:07:54) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import spwd
>>> spwd.getspnam("I_don't_exist")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'getspnam(): name not found'
>>> spwd.getspnam("bin")
spwd.struct_spwd(sp_nam='bin', sp_pwd='*', sp_lstchg=15259, sp_min=0, sp_max=99999, sp_warn=7, sp_inact=-1, sp_expire=-1, sp_flag=-1)

As normal user:

$ python3
Python 3.2.3 (default, Apr 10 2013, 05:07:54) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import spwd
>>> spwd.getspnam("I_don't_exist")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'getspnam(): name not found'
>>> spwd.getspnam("bin")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'getspnam(): name not found'

People can be confused. How could the name not found if the name actually exists?

Attached the patch to differentiate the error whether the error is really 'name not found' or 'permission denied'.

I use the error message from the getspnam manual:
http://man7.org/linux/man-pages/man3/getspnam.3.html

There is another error message from getspnam beside EACCES (permission denied), which is ERANGE, but I don't think we need to handle this.

----------
components: Extension Modules
files: fix_error_message_getspnam.patch
keywords: patch
messages: 195678
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Misleading error from getspnam function of spwd module
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31380/fix_error_message_getspnam.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18787>
_______________________________________

From report at bugs.python.org  Tue Aug 20 06:59:09 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Aug 2013 04:59:09 +0000
Subject: [issue18788] Proof of concept: implicit call syntax
Message-ID: <1376974748.83.0.329764233469.issue18788@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

After watching one of the presenters at PyTexas struggle painfully with the fact "print value" doesn't work in Python 3, I decided I had to at least *try* to see if a general "implicit call" syntax was feasible within the constraints of the CPython parser.

The attached patch shows that it is, indeed, possible to implement such a syntax by modifying the definition of expr_stmt to allow for an implicit trailing argument list (using the normal argument syntax).

The key benefit of such a feature is that the following would once again be legal Python syntax:

    print "Hello world!"

Ambiguous cases (such as "expr * expr" and "expr ** expr") obey the rule that implicit calls are very *low* precedence, so you have to use parens to force the call interpretation. Similarly, a bare expression is not call - you must still append () to force a call without arguments.

In addition to being a pain at the interactive prompt, the change of print from a statement to a function has also been noted as one of the biggest problems with compatibility of third party user scripts for Linux distros changing the default system Python to Python 3. This change would mean most Python 2 print statements either do nothing (no arguments), produce an unexpected trailing newline (trailing comma) or work exactly as they do in Python 2. Only those that use the Python 2 redirection syntax continue to trigger a syntax error in Python 3.

While the *code* changes to achieve this behaviour turned out to be relatively small (most of the diff is in the autogenerated parser code), the documentation and general pedagogical impact could be substantially larger.

If there's even an outside chance this could be accepted, I'm happy to work up a full PEP for it.

----------
files: implicit_call_statements.diff
keywords: patch
messages: 195679
nosy: gvanrossum, ncoghlan
priority: normal
severity: normal
status: open
title: Proof of concept: implicit call syntax
Added file: http://bugs.python.org/file31381/implicit_call_statements.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18788>
_______________________________________

From report at bugs.python.org  Tue Aug 20 07:42:53 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 20 Aug 2013 05:42:53 +0000
Subject: [issue18672] Fix format specifiers for debug output in _sre.c
In-Reply-To: <1375805518.91.0.887667887132.issue18672@psf.upfronthosting.co.za>
Message-ID: <1376977373.3.0.02931743061.issue18672@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18672>
_______________________________________

From report at bugs.python.org  Tue Aug 20 07:42:56 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 20 Aug 2013 05:42:56 +0000
Subject: [issue18684] Pointers point out of array bound in _sre.c
In-Reply-To: <1375962984.07.0.918202360038.issue18684@psf.upfronthosting.co.za>
Message-ID: <1376977376.77.0.763871521743.issue18684@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18684>
_______________________________________

From report at bugs.python.org  Tue Aug 20 08:56:03 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 20 Aug 2013 06:56:03 +0000
Subject: [issue18788] Proof of concept: implicit call syntax
In-Reply-To: <1376974748.83.0.329764233469.issue18788@psf.upfronthosting.co.za>
Message-ID: <1376981763.64.0.506265360995.issue18788@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18788>
_______________________________________

From report at bugs.python.org  Tue Aug 20 10:19:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Aug 2013 08:19:59 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376942264.41.0.0961806580571.issue18772@psf.upfronthosting.co.za>
Message-ID: <1814281845.72522399.1376986793557.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> In other words, we're paying a price for the dummy object being
> printable as a string.

Which is pointless, I agree.

> Antoine, thanks to the link to the python-dev discussion.  I hope we
> can come with a solution that doesn't involve going back to unicode
> objects.

Re-using PyDict's dummy object would be a solution, AFAICT?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Tue Aug 20 10:25:44 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Aug 2013 08:25:44 +0000
Subject: [issue18788] Proof of concept: implicit call syntax
In-Reply-To: <1376974748.83.0.329764233469.issue18788@psf.upfronthosting.co.za>
Message-ID: <1376987144.29.0.942358449918.issue18788@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> In addition to being a pain at the interactive prompt

Just type "pr<TAB>" and the "print(" call will be auto-completed.
(with TAB-completion being enabled by default in 3.4 ;-))

> the change of print from a statement to a function has also been noted 
> as one of the biggest problems with compatibility of third party user
> scripts for Linux distros changing the default system Python to Python 3

Well, I know 2to3 has had some bad press recently, but it should still make it a piece of cake to convert such small scripts.
(since you don't need to keep 2.x compatibility for them)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18788>
_______________________________________

From report at bugs.python.org  Tue Aug 20 11:27:03 2013
From: report at bugs.python.org (Peter Otten)
Date: Tue, 20 Aug 2013 09:27:03 +0000
Subject: [issue18788] Proof of concept: implicit call syntax
In-Reply-To: <1376974748.83.0.329764233469.issue18788@psf.upfronthosting.co.za>
Message-ID: <1376990823.84.0.7102649026.issue18788@psf.upfronthosting.co.za>


Peter Otten added the comment:

> a bare expression is not call

Wouldn't that silently swallow a lot of bare

print

statements?

----------
nosy: +peter.otten

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18788>
_______________________________________

From report at bugs.python.org  Tue Aug 20 11:32:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Aug 2013 09:32:45 +0000
Subject: [issue18787] Misleading error from getspnam function of spwd module
In-Reply-To: <1376971981.98.0.467831293927.issue18787@psf.upfronthosting.co.za>
Message-ID: <1376991165.34.0.998422150792.issue18787@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

PyErr_SetFromErrno(PyExc_OSError) looks more appropriate for permission denied error. However this change is backward incompatible so perhaps we have to left a KeyError.

----------
nosy: +loewis, serhiy.storchaka
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18787>
_______________________________________

From report at bugs.python.org  Tue Aug 20 11:41:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Aug 2013 09:41:13 +0000
Subject: [issue18788] Proof of concept: implicit call syntax
In-Reply-To: <1376974748.83.0.329764233469.issue18788@psf.upfronthosting.co.za>
Message-ID: <1376991673.56.0.216121394997.issue18788@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Ambiguous cases (such as "expr * expr" and "expr ** expr") obey the rule that implicit calls are very *low* precedence, so you have to use parens to force the call interpretation.

Does "a + b c" mean "(a + b)(c)"? Does "a + b (c)" mean "(a + b)((c))"?

What does "a (b, c)" mean? "a.__call__(b, c)" or "a.__call__((b, c))"?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18788>
_______________________________________

From report at bugs.python.org  Tue Aug 20 12:10:14 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Aug 2013 10:10:14 +0000
Subject: [issue18783] No more refer to Python "long"
In-Reply-To: <1376933723.97.0.818285065385.issue18783@psf.upfronthosting.co.za>
Message-ID: <1376993414.4.0.946729838979.issue18783@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18783>
_______________________________________

From report at bugs.python.org  Tue Aug 20 12:50:11 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 20 Aug 2013 10:50:11 +0000
Subject: [issue18787] Misleading error from getspnam function of spwd module
In-Reply-To: <1376971981.98.0.467831293927.issue18787@psf.upfronthosting.co.za>
Message-ID: <1376995811.99.0.80123152267.issue18787@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Attached the patch to accomodate Serhiy Storchaka's suggestion by using KeyError exception for backward compatibility.

----------
Added file: http://bugs.python.org/file31382/fix_error_message_getspnam_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18787>
_______________________________________

From report at bugs.python.org  Tue Aug 20 14:43:28 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Aug 2013 12:43:28 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1377002608.43.0.244520856137.issue18606@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I agree with Oscar about sum for decimal.Decimal.  The *ideal* sum for Decimal instances would return the correctly rounded result (i.e., the exact result, rounded to the current context just once using the current rounding mode).  It seems wrong to give a guarantee of behaviour that's in conflict with this ideal.

IEEE 754 recommends a 'sum' operation (in section 9.4, amongst other reduction operations), but doesn't go so far as to either require or recommend that the result be correctly rounded.  Instead, it says "Implementations may associate in any order or evaluate in any wider format.", and then later on, "Numerical results [...] may differ among implementations due to the precision of intermediates and the order of evaluation."  It certainly *doesn't* specify that the results should be as though the context precision and rounding mode were used for every individual addition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Tue Aug 20 15:23:35 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 20 Aug 2013 13:23:35 +0000
Subject: [issue17087] Improve the repr for regular expression match objects
In-Reply-To: <1359589982.45.0.929656950631.issue17087@psf.upfronthosting.co.za>
Message-ID: <1377005015.43.0.479493227654.issue17087@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Here's my patch attempt. The repr of a match object has the following format:
(groups=\d+, span=(start, end), group0=the entire group or the first X characters, where X is represented by a new constant in sre_constants.h, SRE_MATCH_REPR_SIZE).

----------
keywords: +patch
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file31383/sre.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17087>
_______________________________________

From report at bugs.python.org  Tue Aug 20 15:50:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Aug 2013 13:50:38 +0000
Subject: [issue18787] Misleading error from getspnam function of spwd module
In-Reply-To: <1376971981.98.0.467831293927.issue18787@psf.upfronthosting.co.za>
Message-ID: <1377006638.62.0.223739997333.issue18787@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It was not a suggestion, it was a doubt.

See also issue10388.

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18787>
_______________________________________

From report at bugs.python.org  Tue Aug 20 15:51:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Aug 2013 13:51:53 +0000
Subject: [issue10388] spwd returning different value depending on privileges
In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za>
Message-ID: <1377006713.91.0.145858805415.issue10388@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue18787.

----------
nosy: +akuchling, loewis, serhiy.storchaka
versions: +Python 3.3, Python 3.4 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10388>
_______________________________________

From report at bugs.python.org  Tue Aug 20 16:06:16 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Aug 2013 14:06:16 +0000
Subject: [issue18788] Proof of concept: implicit call syntax
In-Reply-To: <1376974748.83.0.329764233469.issue18788@psf.upfronthosting.co.za>
Message-ID: <1377007576.66.0.3902386563.issue18788@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As Serhiy's examples show, the ambiguities this introduces get confusing fast. A more constrained version that (for example) permitted only name references for the callable could resolve that, but it's probably still a bad idea. Still, interesting to know it is *technically* possible, if anyone decides to pursue it further :)

The "silently ignores bare print statements" aspect isn't new - Python 3 already behaves that way, since a print on its own line now just references the builtin without calling it.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18788>
_______________________________________

From report at bugs.python.org  Tue Aug 20 16:08:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Aug 2013 14:08:37 +0000
Subject: [issue17087] Improve the repr for regular expression match objects
In-Reply-To: <1359589982.45.0.929656950631.issue17087@psf.upfronthosting.co.za>
Message-ID: <1377007717.04.0.930941569802.issue17087@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17087>
_______________________________________

From report at bugs.python.org  Tue Aug 20 16:22:54 2013
From: report at bugs.python.org (Joe Tennies)
Date: Tue, 20 Aug 2013 14:22:54 +0000
Subject: [issue18789] XML Vunerability Table Unclear
Message-ID: <1377008574.91.0.12100936862.issue18789@psf.upfronthosting.co.za>


New submission from Joe Tennies:

EASY

This is an issue with the 2.x and 3.x documentation.

http://docs.python.org/3.2/library/xml.html#xml-vulnerabilities
http://docs.python.org/dev/library/xml.html#xml-vulnerabilities
http://docs.python.org/2/library/xml.html#xml-vulnerabilities

This section has a table with a bunch of Trues and Falses. This is a bit confusing, especially for something that is trying to describe security concerns. After looking at the table, I'm pretty sure that True means vunerable (only due to the (1), (2), & (3) comments), but it's not clear. All that is needed is a heading stating "Vunerable", or change the "True" to "Vunerable" and "False" to "Not Vunerable" (probably V and NV w/ a legend).

----------
assignee: docs at python
components: Documentation
messages: 195691
nosy: docs at python, joe-tennies
priority: normal
severity: normal
status: open
title: XML Vunerability Table Unclear
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18789>
_______________________________________

From report at bugs.python.org  Tue Aug 20 16:23:55 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 20 Aug 2013 14:23:55 +0000
Subject: [issue18789] XML Vunerability Table Unclear
In-Reply-To: <1377008574.91.0.12100936862.issue18789@psf.upfronthosting.co.za>
Message-ID: <1377008635.43.0.152326259145.issue18789@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18789>
_______________________________________

From report at bugs.python.org  Tue Aug 20 16:27:05 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 20 Aug 2013 14:27:05 +0000
Subject: [issue10388] spwd returning different value depending on privileges
In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za>
Message-ID: <1377008825.5.0.595232350413.issue10388@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Attached the patch to raise OSError instead of returning empty list if a normal user uses getspall function of spwd module.

I investigated about this issue. There exists situation where /etc/shadow file does not exist:
https://bugs.kde.org/show_bug.cgi?id=117202
https://dev.openwrt.org/ticket/2887

So I think it is better to differentiate the result of the function where a normal user trying to access /etc/shadow file (permission denied, therefore should raise exception) or root user trying to access non-existent /etc/shadow file (therefore should get empty list).

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file31384/fix_error_message_getspall.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10388>
_______________________________________

From report at bugs.python.org  Tue Aug 20 16:28:43 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 20 Aug 2013 14:28:43 +0000
Subject: [issue18787] Misleading error from getspnam function of spwd module
In-Reply-To: <1376971981.98.0.467831293927.issue18787@psf.upfronthosting.co.za>
Message-ID: <1377008923.01.0.513490684687.issue18787@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Sorry about that.

Okay, so for now, we wait for other people's suggestion, which way we should use to handle this situation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18787>
_______________________________________

From report at bugs.python.org  Tue Aug 20 16:32:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Aug 2013 14:32:34 +0000
Subject: [issue18788] Proof of concept: implicit call syntax
In-Reply-To: <1376974748.83.0.329764233469.issue18788@psf.upfronthosting.co.za>
Message-ID: <1377009154.02.0.226335545444.issue18788@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I like a parens-less call syntax, but it is unpythonic and even anti-pythonic. It can be good in some other language (like Forth or Tcl, may be Perl or Ruby) but not in Python. It requires some other coordinated features (a syntax to obtaining a reference to a function/method, perhaps shorter syntax for lambdas, braced blocks, different scoping and binding rules) and different philosophy. It doesn't quack as Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18788>
_______________________________________

From report at bugs.python.org  Tue Aug 20 16:37:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Aug 2013 14:37:58 +0000
Subject: [issue18789] XML Vunerability Table Unclear
In-Reply-To: <1377008574.91.0.12100936862.issue18789@psf.upfronthosting.co.za>
Message-ID: <1377009478.18.0.102951968146.issue18789@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +XML
versions:  -Python 3.2, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18789>
_______________________________________

From report at bugs.python.org  Tue Aug 20 16:42:46 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 20 Aug 2013 14:42:46 +0000
Subject: [issue18788] Proof of concept: implicit call syntax
In-Reply-To: <1376974748.83.0.329764233469.issue18788@psf.upfronthosting.co.za>
Message-ID: <1377009766.28.0.263585684843.issue18788@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

I do not see much use of of implicit call syntax, a good editor will autocomplete the brackets.

----------
nosy: +Ramchandra Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18788>
_______________________________________

From report at bugs.python.org  Tue Aug 20 16:47:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Aug 2013 14:47:05 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1377010025.76.0.973202846677.issue17576@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Tue Aug 20 16:47:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Aug 2013 14:47:22 +0000
Subject: [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1377010042.73.0.877344240495.issue8865@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: gregory.p.smith -> serhiy.storchaka
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8865>
_______________________________________

From report at bugs.python.org  Tue Aug 20 17:04:05 2013
From: report at bugs.python.org (irdb)
Date: Tue, 20 Aug 2013 15:04:05 +0000
Subject: [issue17348] Unicode - encoding seems to be lost for inputs of
 unicode chars in IDLE
In-Reply-To: <1362394177.55.0.407970210278.issue17348@psf.upfronthosting.co.za>
Message-ID: <1377011045.24.0.473472282966.issue17348@psf.upfronthosting.co.za>


Changes by irdb <dalba.wiki at gmail.com>:


----------
nosy: +irdb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17348>
_______________________________________

From report at bugs.python.org  Tue Aug 20 17:16:41 2013
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 20 Aug 2013 15:16:41 +0000
Subject: [issue18786] test_multiprocessing_spawn crashes under PowerLinux
In-Reply-To: <1376948017.66.0.62278437821.issue18786@psf.upfronthosting.co.za>
Message-ID: <1377011801.75.0.588855266628.issue18786@psf.upfronthosting.co.za>


David Edelsohn added the comment:

I am not certain what is going on. Only 3.x appears to be affected, but the problems seem somewhat intermittent. There were some strange processes of another user running on the buildslave, which was driving the load up very high. I have killed the processes and blocked the user. We can see if that affects the test results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18786>
_______________________________________

From report at bugs.python.org  Tue Aug 20 17:17:00 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 20 Aug 2013 15:17:00 +0000
Subject: [issue18788] Proof of concept: implicit call syntax
In-Reply-To: <1376974748.83.0.329764233469.issue18788@psf.upfronthosting.co.za>
Message-ID: <1377011820.47.0.920721742192.issue18788@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Well aren't there other languages (Ruby, Coffeescript) that have the same syntax?  How do they do it?  (Haskell does it too, but I don't think we can learn from it -- but in Ruby and IIRC Coffeescsript it is syntactic sugar for a regular call.)

Heck, even Python's predecessor, ABC, used "f x" to mean "f(x)".  It solved "a b + c" by giving function call binding the *tightest* possible priority though, interpreting it as (a b) + c, and hence (a(b)) + c", which would be no good for Nick's hope that "print x+1, y" can be made to mean print(x+1, y) -- ABC would interpret it as "(print(x)) + 1, y".

Still, I'd like to hear about how Ruby/Coffee solve this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18788>
_______________________________________

From report at bugs.python.org  Tue Aug 20 17:20:07 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 20 Aug 2013 15:20:07 +0000
Subject: [issue18788] Proof of concept: implicit call syntax
In-Reply-To: <1376974748.83.0.329764233469.issue18788@psf.upfronthosting.co.za>
Message-ID: <1377012007.45.0.0795665512581.issue18788@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

I suppose I'm one of the more qualified people to comment on how Ruby does it: a mess of hacks in the lexer/parser. Ruby's case is complicated by the fact that a bare `foo` can either be a local variable or a method call on self. Consider the case `a +b`, should that be parsed as a call to a with a unary + on b, or an addition? In Ruby this depends on whether `a` is already defined as a local. Basically I think this is a terrible idea, and would encourage as strongly as possible to not consider this.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18788>
_______________________________________

From report at bugs.python.org  Tue Aug 20 17:21:26 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 20 Aug 2013 15:21:26 +0000
Subject: [issue18512] sys.stdout.write does not allow bytes in Python 3.x
In-Reply-To: <1374287481.36.0.643885131326.issue18512@psf.upfronthosting.co.za>
Message-ID: <1377012086.6.0.238175178614.issue18512@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> A workaround is to perform sys.stdout.flush() before 
> sys.stdout.buffer.write().

FWIW you can just use print(..., flush=True) from 3.3+.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18512>
_______________________________________

From report at bugs.python.org  Tue Aug 20 17:40:46 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 20 Aug 2013 15:40:46 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1377013245.99.0.597851090186.issue18704@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I think modern editors are expected to have this sort of functionality
> built into them [1].

Mine doesn't :)

> XCode is simply amazing where it will pop up errors and quote the C99
> standard [2].

That's a standard though, the ones in PEP8 are just conventions/guidelines/suggestions.

> We don't expect IDLE to have all that functionality but it seemed to
> us like it would be great to add pep8 or PyFlakes to IDLE.

AFAIU PyFlakes should be able to catch actual problems with the code -- not just simply suggesting a particular style -- so it would be a better candidate.

> It is possible we could create an extension but that would void
> Python's motto "batteries included".

Often editors are able to download extensions automatically from a central place, without having to ship them all by default.  Doing this is probably more work though, but on the other hand it would be more flexible.

> In addition tools like pep8 and PyFlakes could be useful for other purposes as well.

Are you suggesting to include it directly in the stdlib, and not as part of IDLE?

> JayKrish is checking with the authors of pep8 about license issues.

Note that that's not the only issue.  Even if the license is OK, before inclusion we would have to make sure that the module meets the quality standards for the repo and that the author is still active and willing to maintain it for at least a few years in the CPython repo.  A PEP would likely be required, especially if the module gets included directly in the stdlib (as opposed as including it just in IDLE).  This also means that external development of the module should stop and move to the stdlib, and follow the release schedule of Python instead of release whenever they want (in theory they could maintain both, but it's more work).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Tue Aug 20 18:19:27 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 20 Aug 2013 16:19:27 +0000
Subject: [issue18326] Mention 'keyword only' for list.sort, improve  glossary.
In-Reply-To: <1372511136.61.0.278425078947.issue18326@psf.upfronthosting.co.za>
Message-ID: <1377015567.51.0.328048990139.issue18326@psf.upfronthosting.co.za>


Zachary Ware added the comment:

How about this?

----------
Added file: http://bugs.python.org/file31385/issue18326.v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18326>
_______________________________________

From report at bugs.python.org  Tue Aug 20 18:29:10 2013
From: report at bugs.python.org (Jeremy Kloth)
Date: Tue, 20 Aug 2013 16:29:10 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377016150.87.0.0185715295569.issue12641@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Tue Aug 20 18:49:15 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Aug 2013 16:49:15 +0000
Subject: [issue18788] Proof of concept: implicit call syntax
In-Reply-To: <1377012007.45.0.0795665512581.issue18788@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dTzS0yZHzQhZFBdqjkD---NfG3sw4-Drk1HeOXBTF+QA@mail.gmail.com>


Nick Coghlan added the comment:

To clarify how my patch works: leaving out the parentheses is permitted
*only* when the call is a statement unto itself. That's how it avoids
conflicting with any existing syntax like "a *b" or "a **b": the parser
consumes those as part of the initial expression, so you *need* the parens
to control precedence and get it interpreted as a call instead. It was
surprisingly elegant at the implementation level - once I got the new
expr_stmt definition and parsing right, everything later in the chain "just
worked".

A real patch might want to look at the following enhancements:
* constraining the LHS further. This needs to happen at the AST
construction stage, since the parser can't look far enough ahead to limit
it. The patch currently uses the same rules as augmented assignment targets
* constraining the RHS. For example, disallowing generator expressions, so
they need to use the parenthesised form.
* adding an AST node for clean source-to-source transformations
* allowing implicit calls in more places. For example, as an assignment
value, or a return value.

Proving it was possible at all with pgen scratched my itch, so someone else
will need to run with it for it to turn into a concrete proposal that
addresses the readability issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18788>
_______________________________________

From report at bugs.python.org  Tue Aug 20 19:10:18 2013
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 20 Aug 2013 17:10:18 +0000
Subject: [issue18786] test_multiprocessing_spawn crashes under PowerLinux
In-Reply-To: <1376948017.66.0.62278437821.issue18786@psf.upfronthosting.co.za>
Message-ID: <1377018618.07.0.652539642338.issue18786@psf.upfronthosting.co.za>


David Edelsohn added the comment:

The crash seems to have been due to another user abusing the buildslave system.

The remaining failure is a mis-match in the expected GDB output.

AssertionError: "{<object at remote 0x3fffb176a040>, 'b'}" != "{'b'}"
- {<object at remote 0x3fffb176a040>, 'b'}
+ {'b'}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18786>
_______________________________________

From report at bugs.python.org  Tue Aug 20 19:12:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Aug 2013 17:12:00 +0000
Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010
In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za>
Message-ID: <3cKJTC71hvz7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset 826233404be8 by Serhiy Storchaka in branch '3.3':
Issue #13461: Fix a crash in the TextIOWrapper.tell method on 64-bit platforms.
http://hg.python.org/cpython/rev/826233404be8

New changeset 6c9d49b8e3ec by Serhiy Storchaka in branch 'default':
Issue #13461: Fix a crash in the TextIOWrapper.tell method on 64-bit platforms.
http://hg.python.org/cpython/rev/6c9d49b8e3ec

New changeset 5e679ef2a55c by Serhiy Storchaka in branch '2.7':
Issue #13461: Fix a crash in the TextIOWrapper.tell method and in the "replace"
http://hg.python.org/cpython/rev/5e679ef2a55c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13461>
_______________________________________

From report at bugs.python.org  Tue Aug 20 19:59:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Aug 2013 17:59:34 +0000
Subject: [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <3cKKX52zhDzRrM@mail.python.org>


Roundup Robot added the comment:

New changeset 072ba5df77e4 by Serhiy Storchaka in branch '3.3':
Issue #8865: Concurrent invocation of select.poll.poll() now raises a
http://hg.python.org/cpython/rev/072ba5df77e4

New changeset 4543408e2ba6 by Serhiy Storchaka in branch 'default':
Issue #8865: Concurrent invocation of select.poll.poll() now raises a
http://hg.python.org/cpython/rev/4543408e2ba6

New changeset a4091c1de27a by Serhiy Storchaka in branch '2.7':
Issue #8865: Concurrent invocation of select.poll.poll() now raises a
http://hg.python.org/cpython/rev/a4091c1de27a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8865>
_______________________________________

From report at bugs.python.org  Tue Aug 20 20:03:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Aug 2013 18:03:36 +0000
Subject: [issue18786] test_multiprocessing_spawn crashes under PowerLinux
In-Reply-To: <1376948017.66.0.62278437821.issue18786@psf.upfronthosting.co.za>
Message-ID: <1377021816.4.0.315845475003.issue18786@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks David! The test_gdb failure is another issue (not PowerLinux-specific), see issue18772.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18786>
_______________________________________

From report at bugs.python.org  Tue Aug 20 20:23:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Aug 2013 18:23:29 +0000
Subject: [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1377023009.26.0.428290772738.issue8865@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for the report and the patch Christian.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8865>
_______________________________________

From report at bugs.python.org  Tue Aug 20 20:24:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Aug 2013 18:24:04 +0000
Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010
In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za>
Message-ID: <1377023044.19.0.658682647473.issue13461@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for the report S?bastien. Thank you for the patch Yogesh.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13461>
_______________________________________

From report at bugs.python.org  Tue Aug 20 20:33:08 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 20 Aug 2013 18:33:08 +0000
Subject: [issue3158] Doctest fails to find doctests in extension modules
In-Reply-To: <1214015505.39.0.384160170018.issue3158@psf.upfronthosting.co.za>
Message-ID: <1377023588.12.0.31577292474.issue3158@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Ping!

Anyone able to do a review of this patch?  It still applies cleanly to default (or even 3.3, if this qualifies as a bug rather than a new feature).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3158>
_______________________________________

From report at bugs.python.org  Tue Aug 20 20:42:13 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 20 Aug 2013 18:42:13 +0000
Subject: [issue3158] Doctest fails to find doctests in extension modules
In-Reply-To: <1214015505.39.0.384160170018.issue3158@psf.upfronthosting.co.za>
Message-ID: <1377024133.76.0.153642845071.issue3158@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3158>
_______________________________________

From report at bugs.python.org  Tue Aug 20 20:58:24 2013
From: report at bugs.python.org (purplezephyr)
Date: Tue, 20 Aug 2013 18:58:24 +0000
Subject: [issue18790] incorrect text in argparse add_help example
Message-ID: <1377025104.92.0.641943823333.issue18790@psf.upfronthosting.co.za>


New submission from purplezephyr:

The last example under add_help in the documentation for the argparse module has incorrect text.  It is supposed to demonstrate what happens when prefix_chars doesn't include '-', and add_help is True, but the example has the following:

  usage: PROG [-h]

  optional arguments:
    -h, --help  show this help message and exit

instead of:

  usage: PROG [+h]

  optional arguments:
    +h, ++help  show this help message and exit

----------
assignee: docs at python
components: Documentation
messages: 195710
nosy: docs at python, purplezephyr
priority: normal
severity: normal
status: open
title: incorrect text in argparse add_help example
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18790>
_______________________________________

From report at bugs.python.org  Tue Aug 20 21:11:14 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 20 Aug 2013 19:11:14 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1377025874.76.0.901932221913.issue18704@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Summary:
I am in favor of making more Python code analysis available from within Idle. I have an alternate, more generalized proposal. I am opposed to this specific proposal and think this issue should be closed.

Alternatives: when and how to analyze.

1. Local analysis as the user types ('on the fly'). One example is smart indentation, which includes conversion of \t to spaces (this is PEP 8 enforcement!) and backspace to multiple deletes. Others are calltips and code completion.  We might consider doing a bit more syntax checking, but would have to be very careful about style enforcement.

2. Block or whole file analysis within the text widget upon user request. Examples include search, reformatting, and whitespace stripping. The result is shown within the text widget (except for the bug on Windows that search still does not highlight found results while the dialog is active).

3. Analysis of one or more external files with Idle code. 'Find in Files' applies one pattern to file names and another to lines within found files and presents hits in an output (editor) window. The output lines contain file name, line number, and code line formatted so that right click, 'Go to file/line' opens the file if necessary and jumps to the indicated line.

4. Analysis of the saved editor file with external code. 'Run' (normally) does this (and more), with the complication that a socket rather than stdio streams are used for communication. Results appear in the shell window. Although tracebacks put file name and line number on one line and code on the next, 'Go to file/line' works when either is right-clicked. (Although Run now uses the same interpreter that is running Idle, this does not necessarily have to be so.)


Proposal: Run with ... 

What I would like to see is a generic option to save and run the current window with appropriate external programs. This proposal combines ideas from 3. and 4. above. The interface would be the addition of 'Run with ...' to the Run menu. Selecting that would bring up a submenu.

I would use subprocess to start the program (as is done with Run now). A command-line template would be needed for each supported external program. Unlike Run, subprocess would be used to capture stdout and stderr, as needed. The filtered output would be presented in a new Output Window, as done with Find-in-Files.

To me, the main value-added of doing this from Idle is being able to jump from output chunks to targets in an editor window for possible editing. I would only officially support external programs for which this is sensible, whose output includes line numbers and messages for possible action. Each supported program would need an output filter function to add the filename (if not present) to the line number and message and otherwise format as needed.

This proposal needs more details. how are external programs located if installed? (Ezio suggested the possibility of easy download and installation if not. I would start with instructions in the docs.) How is the submenu populated. How might users add templates and filter functions for programs not supported?  Such program might include locally written programs. There should be a PEP or at least PEP-like specification. Since the only stdlib addition would be to idlelib, backporting could be considered.


What I think is wrong with the current proposal.

1. There is no specification.

2. It is limited to one category of analysis. Within that category, it 'plays favorites' by picking a winner. I think users should be able to use whatever style analysis program they have already chosen, with the configuration options they have already selected. Not yet mentioned here are PyLint and PyChecker.

3. Rather than pick the 'best of breed' (if there is one), it picks what some would consider to be the 'worst of breed'. The PEP8 module, or at least the way it has been used, violates PEP 8 by treating guidelines as rigid rules, even though PEP 8 says not to do that. Some of the recent edits to PEP 8 were intended to counteract the negative effect of this module.

4. It proposes to add an external program to the stdlib without the needed PEP. I believe the idea of adding one of PyChecker, PyFlakes, and PyLint has already been rejected for multiple reasons (there is no winner, these are apps or tools, not library 'batteries', they are better off maintained where they are, we cannot maintain what we already have, etc.). The fact that these programs have (or should have) persistent configuration and customization files shows that they are apps, like Idle, and not library modules.

5. It proposes to add the external program in the wrong place. Idlelib should only contain Idle-specific code. Need I add that Idle is also under-maintained?

My proposal would start with a specification, would allow user choice, would generalize to other categories and programs (spell checking?), would not expand the stdlib, and would only add idle-specific glue code to idlelib.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Tue Aug 20 21:30:18 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 20 Aug 2013 19:30:18 +0000
Subject: [issue18592] IDLE: Unit test for SearchDialogBase.py
In-Reply-To: <1375146770.41.0.774627283078.issue18592@psf.upfronthosting.co.za>
Message-ID: <1377027018.63.0.282366419199.issue18592@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

For next edit -- docstring for class SearchDialogBase:
>     +    a row of standard radiobuttons (create_option_buttons);
This is wrong -- these are Checkbuttons
>     +    a row of dialog specific radiobuttons (create_other_buttons).
dialog-specific Radiobuttons

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18592>
_______________________________________

From report at bugs.python.org  Tue Aug 20 21:52:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Aug 2013 19:52:35 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1377028355.32.0.68001079553.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Shouldn't it be PendingDeprecationWarning?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Tue Aug 20 22:17:01 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 20 Aug 2013 20:17:01 +0000
Subject: [issue14971] (unittest) loadTestsFromName does not work on method
 with a decorator
In-Reply-To: <1338490939.51.0.536223048687.issue14971@psf.upfronthosting.co.za>
Message-ID: <1377029821.22.0.867647373482.issue14971@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

The patch for Python 2.7 is pretty similar with the one provided for Python 3.

----------
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file31386/unittest_method_name_difference_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14971>
_______________________________________

From report at bugs.python.org  Tue Aug 20 22:33:44 2013
From: report at bugs.python.org (lolo27)
Date: Tue, 20 Aug 2013 20:33:44 +0000
Subject: [issue18791] PIL freeze reading Jpeg file
Message-ID: <1377030824.64.0.335322556531.issue18791@psf.upfronthosting.co.za>


New submission from lolo27:

With this Python program and 20070517-152405_lovers_4 (copie).jpg  (this file is ok whith Gimp and others programs).

Program "freeze" ( line print "Done" is not processing).

---------------------------------------------
from PIL import Image
from PIL.ExifTags import TAGS
 
def get_exif(fn):
    ret = {}
    i = Image.open(fn)
    info = i._getexif()
    for tag, value in info.items():
        decoded = TAGS.get(tag, tag)
        ret[decoded] = value
    return ret
    
    
get_exif("./20070517-152405_lovers_4 (copie).jpg")
print "Done"

---------------------------------------------
Console output  :

Traceback (most recent call last):
  File "pil_exif.py", line 14, in <module>
    get_exif("./20070517-152405_lovers_4 (copie).jpg")
  File "pil_exif.py", line 7, in get_exif
    info = i._getexif()
  File "/usr/lib/python2.7/dist-packages/PIL/JpegImagePlugin.py", line 381, in _getexif
    info.load(file)
  File "/usr/lib/python2.7/dist-packages/PIL/TiffImagePlugin.py", line 348, in load
    for i in range(i16(fp.read(2))):
  File "/usr/lib/python2.7/dist-packages/PIL/TiffImagePlugin.py", line 68, in il16
    return ord(c[o]) + (ord(c[o+1])<<8)
IndexError: string index out of range
------------------------------------

------------------------------------

Linux Mint : Linux mystation 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux
Python :  2.7.3rc2 (no additional lib installed)
TiffImagePlugin.py : __version__ = "1.3.5"

----------
files: 20070517-152405_lovers_4 (copie).jpg
messages: 195715
nosy: lolo27
priority: normal
severity: normal
status: open
title: PIL freeze reading Jpeg file
type: crash
Added file: http://bugs.python.org/file31387/20070517-152405_lovers_4 (copie).jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18791>
_______________________________________

From report at bugs.python.org  Tue Aug 20 22:34:58 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 20 Aug 2013 20:34:58 +0000
Subject: [issue18791] PIL freeze reading Jpeg file
In-Reply-To: <1377030824.64.0.335322556531.issue18791@psf.upfronthosting.co.za>
Message-ID: <1377030898.28.0.112324363407.issue18791@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

PIL is not part of the standard library, you should report this on the PIL bug tracker.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18791>
_______________________________________

From report at bugs.python.org  Tue Aug 20 23:01:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Aug 2013 21:01:29 +0000
Subject: [issue18792] test_ftplib timeouts
Message-ID: <1377032489.22.0.759563431169.issue18792@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Some ftplib tests sometimes time out. Seem they seem to try to connect to "localhost" (rather than "127.0.0.1"), I was wondering if this could be a DNS issue and if we should resolve "localhost" in advance like Charles-Fran?ois did for some other tests (or simply hardcode "127.0.0.1", actually).

http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/7060/steps/test/logs/stdio

(example:

======================================================================
ERROR: testTimeoutDefault (test.test_ftplib.TestTimeouts)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_ftplib.py", line 953, in testTimeoutDefault
    ftp = ftplib.FTP("localhost")
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py", line 115, in __init__
    self.connect(host)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py", line 150, in connect
    source_address=self.source_address)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\socket.py", line 454, in create_connection
    raise err
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\socket.py", line 445, in create_connection
    sock.connect(sa)
socket.timeout: timed out

)

----------
components: Tests
messages: 195717
nosy: giampaolo.rodola, neologix, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ftplib timeouts
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18792>
_______________________________________

From report at bugs.python.org  Tue Aug 20 23:59:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Aug 2013 21:59:05 +0000
Subject: [issue18793] occasional test_multiprocessing_forkserver failure on
 FreeBSD 10.0
Message-ID: <1377035945.43.0.272426045772.issue18793@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/243

[259/379] test_multiprocessing_forkserver
Process Process-246:
Traceback (most recent call last):
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/process.py", line 255, in _bootstrap
    self.run()
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/process.py", line 92, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/_test_multiprocessing.py", line 3388, in child
    p.start()
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/process.py", line 108, in start
    self._popen = Popen(self)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/popen.py", line 35, in Popen
    return _Popen(process_obj)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/popen_forkserver.py", line 36, in __init__
    super().__init__(process_obj)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/popen_fork.py", line 21, in __init__
    self._launch(process_obj)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/popen_forkserver.py", line 52, in _launch
    self.sentinel, w = forkserver.connect_to_new_process(self._fds)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/forkserver.py", line 67, in connect_to_new_process
    reduction.sendfds(client, allfds)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/reduction.py", line 145, in sendfds
    sock.sendmsg([msg], [(socket.SOL_SOCKET, socket.SCM_RIGHTS, fds)])
OSError: [Errno 9] Bad file descriptor
Traceback (most recent call last):
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/forkserver.py", line 161, in main
    _serve_one(s, listener, alive_r, handler)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/forkserver.py", line 187, in _serve_one
    fds = reduction.recvfds(s, MAXFDS_TO_SEND + 1)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/reduction.py", line 155, in recvfds
    raise EOFError
EOFError
Timeout (1:00:00)!
Thread 0x0000000801c06400:
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/connection.py", line 385 in _recv
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/connection.py", line 408 in _recv_bytes
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/connection.py", line 252 in recv
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/_test_multiprocessing.py", line 3400 in test_lock
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 496 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 535 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/runner.py", line 168 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1637 in _run_suite
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1671 in run_unittest
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1304 in <lambda>
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1305 in runtest_inner
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 998 in runtest
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 796 in main
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1590 in main_in_temp_cwd
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/__main__.py", line 3 in <module>
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/runpy.py", line 73 in _run_code
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/runpy.py", line 160 in _run_module_as_main
*** Error code 1

----------
components: Library (Lib), Tests
keywords: buildbot
messages: 195718
nosy: koobs, pitrou, sbt
priority: normal
severity: normal
status: open
title: occasional test_multiprocessing_forkserver failure on FreeBSD 10.0
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18793>
_______________________________________

From report at bugs.python.org  Wed Aug 21 00:04:11 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 20 Aug 2013 22:04:11 +0000
Subject: [issue17442] code.InteractiveInterpreter doesn't display the
 exception cause
In-Reply-To: <1363468664.92.0.794606977989.issue17442@psf.upfronthosting.co.za>
Message-ID: <1377036251.69.0.596759331175.issue17442@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Here's an updated patch for the stdlib, with adapted tests.

----------
keywords: +patch
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file31388/code.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17442>
_______________________________________

From report at bugs.python.org  Wed Aug 21 00:16:27 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Aug 2013 22:16:27 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1377036987.27.0.0220114327685.issue18772@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'll get on it this evening.  Please be patient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Wed Aug 21 00:20:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Aug 2013 22:20:01 +0000
Subject: [issue18794] select.devpoll objects have no close() method
Message-ID: <1377037201.39.0.250253331.issue18794@psf.upfronthosting.co.za>


New submission from STINNER Victor:

select.epoll and select.kqueue objects have a close() method, but not select.poll objects, whereas all these objects store internally a file descriptor.

select.poll lacks also a fileno() method.

I added the fileno() method in my implementation of the PEP 446 (see issue #18571).

----------
messages: 195721
nosy: gvanrossum, haypo, neologix
priority: normal
severity: normal
status: open
title: select.devpoll objects have no close() method
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18794>
_______________________________________

From report at bugs.python.org  Wed Aug 21 00:21:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Aug 2013 22:21:31 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1377037291.9.0.315890341786.issue16853@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI I created the issue #18794: "select.devpoll objects have no close() method". If this method is added, it should also be called by the close() method of the selector.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Wed Aug 21 00:21:50 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Aug 2013 22:21:50 +0000
Subject: [issue18794] select.devpoll objects have no close() method
In-Reply-To: <1377037201.39.0.250253331.issue18794@psf.upfronthosting.co.za>
Message-ID: <1377037310.7.0.906118617541.issue18794@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also issue #16853 "add a Selector to the select module".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18794>
_______________________________________

From report at bugs.python.org  Wed Aug 21 00:32:21 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 20 Aug 2013 22:32:21 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1377037941.57.0.378700923278.issue16853@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I've lost track -- who is waiting for whom?  I reviewed the patch selector-12.diff and received zero response AFAICT.  (Maybe the email from Rietveld didn't make it?)

I'd like to get this into alpha2, even if the proactor won't make it (though I'd love to see that as well).

Maybe the main issue is that I would prefer if the selector classes were in a separate module (selectors.py) than the low-level select/poll/etc. calls.  I think it makes sense if the selectors module *only* defines the high level classes and not the messy low-level stuff, since an app shouldn't be using both at the same time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Wed Aug 21 00:33:53 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 20 Aug 2013 22:33:53 +0000
Subject: [issue18794] select.devpoll objects have no close() method
In-Reply-To: <1377037201.39.0.250253331.issue18794@psf.upfronthosting.co.za>
Message-ID: <1377038033.12.0.501828611111.issue18794@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

This all sounds fine to fix without waiting for anything else -- can you attach a patch here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18794>
_______________________________________

From report at bugs.python.org  Wed Aug 21 00:37:44 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Aug 2013 22:37:44 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1377038264.14.0.939782439865.issue16853@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Well, I suppose it waits on Charles-Fran?ois to update the patch.

I'd prefer not to add a separate module for this, personally. I think this functionality is fine in the select module. People who know how to use a selector certainly have heard about select() or poll() already :-)
(no strong feelings about it anyway)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Wed Aug 21 00:43:33 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 20 Aug 2013 22:43:33 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1377038613.74.0.460425025834.issue18747@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks Victor, it sounds like a good suggestion. I have modified my patch to use _PyTime_gettimeofday(). Python 2.7 doesn't have _PyTime_gettimeofday() so I'm going to use time(NULL).

----------
Added file: http://bugs.python.org/file31389/openssl_prng_atfork5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 00:55:08 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 20 Aug 2013 22:55:08 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1377039308.7.0.923804149428.issue18747@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


Removed file: http://bugs.python.org/file31389/openssl_prng_atfork5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 00:55:33 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 20 Aug 2013 22:55:33 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1377039333.49.0.591954390434.issue18747@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


Added file: http://bugs.python.org/file31390/openssl_prng_atfork5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 01:28:01 2013
From: report at bugs.python.org (paul j3)
Date: Tue, 20 Aug 2013 23:28:01 +0000
Subject: [issue14191] argparse doesn't allow optionals within positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1377041281.08.0.0981477196317.issue14191@psf.upfronthosting.co.za>


paul j3 added the comment:

It's everything I intend to add.  Now I'm just waiting for a committer to act, either with suggested changes, or a merge.  I'm watching more than a dozen argparse patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14191>
_______________________________________

From report at bugs.python.org  Wed Aug 21 01:40:27 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 20 Aug 2013 23:40:27 +0000
Subject: [issue18782] sqlite3 row factory and multiprocessing map
In-Reply-To: <1376926405.17.0.0447575429203.issue18782@psf.upfronthosting.co.za>
Message-ID: <1377042027.42.0.192497264742.issue18782@psf.upfronthosting.co.za>


Ned Deily added the comment:

I agree with Richard's comments.  The crash appears to be a result of an unsupported usage of SQLite and one that Python can't really protect you from.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18782>
_______________________________________

From report at bugs.python.org  Wed Aug 21 01:46:41 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Aug 2013 23:46:41 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1377042401.07.0.127898528473.issue18747@psf.upfronthosting.co.za>


STINNER Victor added the comment:

openssl_prng_atfork5.patch:

- you should use RAND_pseudo_bytes() instead of RAND_bytes() in the unit test, to not skip the test depending on the entropy
- the change in Misc/NEWS is strange
- please remove dead code ("#if 0")
- PySSL_RAND_atfork_child() comment is wrong, it is no more able to get time with a nanosecond resolution (write "(microseconds or seconds)")
- can you explain the choice of "char stack[72]" (72 bytes): why no more, why not less?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 01:48:12 2013
From: report at bugs.python.org (Alexandre Dias)
Date: Tue, 20 Aug 2013 23:48:12 +0000
Subject: [issue18795] pstats - allow stats sorting by cumulative time per call
 and total time per call
Message-ID: <1377042491.98.0.765142916486.issue18795@psf.upfronthosting.co.za>


New submission from Alexandre Dias:

Me and a couple of colleagues have stumbled upon the need to sometimes sort our profiling stats by time (cumulative and total) per call. I believe this could be useful to other people, and have therefore opened this patch.

Thanks for taking the time to look into it.

-Alexandre

----------
components: Library (Lib)
files: pstats.py
messages: 195731
nosy: alexnvdias
priority: normal
severity: normal
status: open
title: pstats - allow stats sorting by cumulative time per call and total time per call
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file31391/pstats.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18795>
_______________________________________

From report at bugs.python.org  Wed Aug 21 02:16:31 2013
From: report at bugs.python.org (Toshio Kuratomi)
Date: Wed, 21 Aug 2013 00:16:31 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377044191.58.0.292561564195.issue18713@psf.upfronthosting.co.za>


Toshio Kuratomi added the comment:

Nick and I had talked about this at a recent conference and came to it from different directions.  On the one hand, Nick made the point that any encoding of surrogateescape'd text to bytes via a different encoding is corrupting the data as a whole.  On the other hand, I made the point that raising an exception when doing something as basic as printing something that's text type was reintroducing the issues that python2 had wrt unicode, bytes, and encodings -- particularly with the exception being raised far from the source of the problem (when the data is introduced into the program).

After some thought, Nick came up with this solution.  The idea is that surrogateescape was originally accepted to allow roundtripping data from the OS and back when the OS considers it to be a "string" but python does not consider it to be "text".  When that's the case, we know what the encoding was used to attempt to construct the text in python.  If that same encoding is used to re-encode the data on the way back to the OS, then we're successfully roundtripping the data we were given in the first place.  So this is just applying the original goal to another API.

----------
nosy: +a.badger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Wed Aug 21 02:25:20 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Aug 2013 00:25:20 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1377044191.58.0.292561564195.issue18713@psf.upfronthosting.co.za>
Message-ID: <CADiSq7e-_SHG1=pwBTbUYqDT7przVJjSO3RGvDAu+7iC4BTTyg@mail.gmail.com>


Nick Coghlan added the comment:

Which reminds me: I'm curious what "ls" currently does for malformed
filenames. The aim of this change would be to get 'python -c "import os;
print(os.listdir())"' to do the best it can to work without losing data in
such a situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Wed Aug 21 02:31:54 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 00:31:54 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1377044191.58.0.292561564195.issue18713@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbtE_ETOn-W+oc8MVy4eZPJrsnLG90DBC187OCw1oSRDA@mail.gmail.com>


STINNER Victor added the comment:

On Linux, the locale encoding is usually UTF-8. If a filename cannot
be decoded from UTF-8, invalid bytes are escaped to the surrogate
range using the PEP 383. If I create a UTF-8 text file and I try to
write the filename into this text file, the Python UTF-8 encoder
raises an error.

IMO Python must raise an error here because I want to generate a valid
UTF-8 text file, not a text file only readable by Python if the locale
encoding is UTF-8.

So using surrogateescape error handler if the encoding is
sys.getfilesystemencoding() is *not* a good idea.

What is your use case where you need to display a filename? Is it
displayed to the terminal, into a file or in a graphical window? Why
not escaping surrogate just to format the filename, as Gnome does? See
for example:
https://developer.gnome.org/glib/2.34/glib-Character-Set-Conversion.html#g-filename-display-name

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Wed Aug 21 02:37:10 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 00:37:10 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <CADiSq7e-_SHG1=pwBTbUYqDT7przVJjSO3RGvDAu+7iC4BTTyg@mail.gmail.com>
Message-ID: <CAMpsgwYPqmKZRZpVw8WH9ftv8uOXjxuv89mD6O5Rz5ye39ieKQ@mail.gmail.com>


STINNER Victor added the comment:

2013/8/21 Nick Coghlan <report at bugs.python.org>:
> Which reminds me: I'm curious what "ls" currently does for malformed
> filenames. The aim of this change would be to get 'python -c "import os;
> print(os.listdir())"' to do the best it can to work without losing data in
> such a situation.

The "ls" command works on bytes, not on characters. You can
reimplement "ls" with:

* Unicode: os.listdir(str), os.fsencode() and sys.stdout.buffer
* bytes: os.listdir(bytes) and sys.stdout.buffer

os.fsencode() does exactly the opposite of os.fsdecode(). There is a
unit test to check that :-)

I ensured that all OS functions can be used directly with bytes
filenames in Python 3. That's why I added os.environb for example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Wed Aug 21 02:43:57 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Aug 2013 00:43:57 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376603210.07.0.54860483499.issue18738@psf.upfronthosting.co.za>
Message-ID: <52140D4A.2020108@stoneleaf.us>


Ethan Furman added the comment:

Eli Bendersky added the comment:
>
> The whole point of IntEnum and replacing stdlib constants with it was friendly str & repr out of the box.

Sure, friendly str and repr plus an nice way to work them in code.

> This means that "just printing out" an enum member should have a nice string representation.

And when are you going to print out an enum?  Debugger and/or command line.

> And "just printing out" means:
>
> print(member)
> "%s" % member
> "{}".format(member)

Would you seriously use either of those last two in either the debugger 
or the command line?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 21 02:55:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Aug 2013 00:55:30 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
 arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <3cKVm14dH1z7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset 84f40562669f by Barry Warsaw in branch '2.6':
Fix UnboundLocalError regression due to previous incorrect fix for
http://hg.python.org/cpython/rev/84f40562669f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Wed Aug 21 02:57:03 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 21 Aug 2013 00:57:03 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
 arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1377046623.84.0.153771850904.issue16248@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Applied the fix to 2.6 and null merged into 2.7.  This didn't need a NEWS entry because the regression hadn't been released yet.  I'll remove 2.6 from the Versions now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Wed Aug 21 02:57:20 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 21 Aug 2013 00:57:20 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
 arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1377046640.37.0.128357019628.issue16248@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Wed Aug 21 03:26:05 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Aug 2013 01:26:05 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376916338.02.0.276331604909.issue18738@psf.upfronthosting.co.za>
Message-ID: <5214172A.7080509@stoneleaf.us>


Ethan Furman added the comment:

Eric V. Smith added the comment:
>
> this gives the (to me) surprising results of:
>
>>>> format(S.a)
> 'S.a'
>>>> format(S.a, '10')
> 'S.a'
>>>> format(S.a, '10s')
> 'A'

that is surprising: if a __format__ is defined in the Enum class chain 
then it should be used instead of the default.  I'll fix that (I treat 
__new__, __repr__, __getnewargs__, and maybe one other the same way).

> Also, the patch give this:
>
>>>> class E(IntEnum):
> ...   one = 1
> ...   two = 2
> ...
>>>> format(E.one)
> 'E.one'
>>>> format(E.one, 's')
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/home/eric/local/python/cpython/Lib/enum.py", line 463, in __format__
>      return obj.__format__(val, format_spec)
> ValueError: Unknown format code 's' for object of type 'int'
>
> I can't format it using the 's' presentation type, despite the fact it looks like a string. I think you need to add 's' to your _remove_plain_format_chars.

Well, they are Enums, not strings.  And if I add 's' to the remove, then 
a str-derived enum would not pass through to the value correctly.

> And consider this valid (but arguably pathological) code:
>
>>>> format(datetime.datetime.now(), '10')
> '10'
>
> Despite this being a valid datetime format spec, your code would consider it a str spec.

Sounds like the way forward is to specify in the docs how the default 
Enum __format__ behaves (basically honors width and justification 
settings to yield the name, anything else passes through to the Enum 
member) along with advice matching that for __str__ and __repr__: if you 
want something different, write your own method. ;)

And I learned something else:  the format mini-language is really in two 
parts; the first part is selecting the object to be printed ({} or {3} 
or {some_name} or {other.name} etc., etc.) and the second part is the 
format spec for the object selected.  The kicker is that each object can 
specify what it knows about.  So float's treat 'f' as float, but 
something else might treat 'f' as fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 21 03:29:23 2013
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 21 Aug 2013 01:29:23 +0000
Subject: [issue14191] argparse doesn't allow optionals within positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1377048563.85.0.529994384462.issue14191@psf.upfronthosting.co.za>


Glenn Linderman added the comment:

So I read over your code again, and even read the documentation this time, and it all looks good, and I know it works good because I've been using the code. I tried to send a notice through Reitveld, and maybe did, but I don't know where it went, so I'll say this much here, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14191>
_______________________________________

From report at bugs.python.org  Wed Aug 21 03:50:17 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Aug 2013 01:50:17 +0000
Subject: [issue18788] Proof of concept: implicit call syntax
In-Reply-To: <1376974748.83.0.329764233469.issue18788@psf.upfronthosting.co.za>
Message-ID: <1377049817.81.0.166591456393.issue18788@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18788>
_______________________________________

From report at bugs.python.org  Wed Aug 21 04:35:37 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Aug 2013 02:35:37 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <CAMpsgwYPqmKZRZpVw8WH9ftv8uOXjxuv89mD6O5Rz5ye39ieKQ@mail.gmail.com>
Message-ID: <CADiSq7fKZm4c-jnkZymjfROH2OqvjRp=-x=aXNyHDt-ZmgkXdg@mail.gmail.com>


Nick Coghlan added the comment:

Think sysadmins running scripts on Linux, writing to the console or a pipe.
I agree the generalisation is a bad idea, so only consider the original
proposal that was specifically limited to the standard streams.

Specifically, if a system is properly configured to use UTF-8 for all
interfaces, I shouldn't have to live in fear of Python steps in a command
pipeline falling over because it happens to encounter a filename encoded
with latin-1 (etc).

If the bytes oriented os tools like ls don't fall over on it, then neither
should Python. This is about treating the standard streams as OS
interfaces, as long as they're using the filesystem encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Wed Aug 21 04:56:59 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 21 Aug 2013 02:56:59 +0000
Subject: [issue18796] Wrong documentation of show_code function from dis module
Message-ID: <1377053819.02.0.986969704551.issue18796@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

$ ./python
Python 3.4.0a1+ (default:afb1b4797419, Aug 21 2013, 09:54:46) 
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import dis
>>> import sys
>>> def spam(x):
...   return x * 2
... 
>>> dis.show_code(spam, file=sys.stderr)
Name:              spam
Filename:          <stdin>
Argument count:    1
Kw-only arguments: 0
Number of locals:  1
Stack size:        2
Flags:             OPTIMIZED, NEWLOCALS, NOFREE
Constants:
   0: None
   1: 2
Variable names:
   0: x
>>> output = open('/tmp/output.txt', 'w')
>>> dis.show_code(spam, file=output)
>>> output.close()
>>> dis.show_code.__doc__
'Print details of methods, functions, or code to stdout.'

Attached the patch to fix the documentation.

----------
assignee: docs at python
components: Documentation
files: fix_doc_show_code.patch
keywords: patch
messages: 195742
nosy: docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Wrong documentation of show_code function from dis module
versions: Python 3.4
Added file: http://bugs.python.org/file31392/fix_doc_show_code.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18796>
_______________________________________

From report at bugs.python.org  Wed Aug 21 05:09:48 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 21 Aug 2013 03:09:48 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1377054588.87.0.427101392259.issue18704@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Agree with Terry Reedy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Wed Aug 21 05:37:22 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Aug 2013 03:37:22 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <5214172A.7080509@stoneleaf.us>
Message-ID: <521435DD.5040103@trueblade.com>


Eric V. Smith added the comment:

On 8/20/2013 9:26 PM, Ethan Furman wrote:
> Sounds like the way forward is to specify in the docs how the default 
> Enum __format__ behaves (basically honors width and justification 
> settings to yield the name, anything else passes through to the Enum 
> member) along with advice matching that for __str__ and __repr__: if you 
> want something different, write your own method.

I definitely agree on the documentation part.

But I think that IntEnum should have its own __format__, because it
wants something different.

And I still think that any interpretation of the format spec in
Enum.__format__ is a mistake, because you don't know what the string
means to the passed-to object. You're basically trying to guess: does
this look like something that makes sense as a str.__format__ specifier
and I should handle it directly, or does it make sense to the passed-to
object? And you can't know for sure.

> And I learned something else:  the format mini-language is really in two 
> parts; the first part is selecting the object to be printed ({} or {3} 
> or {some_name} or {other.name} etc., etc.) and the second part is the 
> format spec for the object selected.

This is why I've been trying to frame this discussion in terms of
built-in format() or obj.__format__(), and get away from str.format().

> The kicker is that each object can
> specify what it knows about.  So float's treat 'f' as float, but
> something else might treat 'f' as fixed.

And some other object might consider 'f' as being part of a literal
that's always output (like datetime).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 21 06:10:21 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 21 Aug 2013 04:10:21 +0000
Subject: [issue18794] select.devpoll objects have no close() method
In-Reply-To: <1377037201.39.0.250253331.issue18794@psf.upfronthosting.co.za>
Message-ID: <1377058221.44.0.800185340146.issue18794@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18794>
_______________________________________

From report at bugs.python.org  Wed Aug 21 07:28:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Aug 2013 05:28:41 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <3cKcqD2B9rz7Ljt@mail.python.org>


Roundup Robot added the comment:

New changeset be29efa60b68 by Raymond Hettinger in branch 'default':
Issue 18772:  Restore set dummy object back to unicode and restore the identity checks in lookkey().
http://hg.python.org/cpython/rev/be29efa60b68

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Wed Aug 21 07:29:25 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Aug 2013 05:29:25 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1377062965.5.0.875945975894.issue18772@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: http://bugs.python.org/msg195720

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Wed Aug 21 07:34:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 05:34:50 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1377044191.58.0.292561564195.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377063280.2486.7.camel@fsol>


Antoine Pitrou added the comment:

> After some thought, Nick came up with this solution.  The idea is that
> surrogateescape was originally accepted to allow roundtripping data
> from the OS and back when the OS considers it to be a "string" but
> python does not consider it to be "text".  When that's the case, we
> know what the encoding was used to attempt to construct the text in
> python.  If that same encoding is used to re-encode the data on the
> way back to the OS, then we're successfully roundtripping the data we
> were given in the first place.  So this is just applying the original
> goal to another API.

I think that outlook is a bit na?ve. The text source is not always the
same as the text destination, i.e. your surrogateescape-decoded data may
come from a database or some JSON API, so there's no reason to think
that the end of the stdout pipe will share the same convention.

I'm myself quite partial to the "round-tripping" use case, but I'm not
sure we can solve it as bluntly. If it's merely for printing out data,
maybe we can an os.fsescape() function to allow for representation of
broken filenames.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Wed Aug 21 07:47:34 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Aug 2013 05:47:34 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1377064054.88.0.645596281376.issue17576@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Shouldn't it be PendingDeprecationWarning?

Hmm.  Possibly.  I'm not sure what the policy is any more regarding DeprecationWarning versus PendingDeprecationWarning.  Nick?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Wed Aug 21 08:13:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 06:13:40 +0000
Subject: [issue812369] module shutdown procedure based on GC
Message-ID: <1377065620.26.0.493728868074.issue812369@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
superseder: module shutdown procedure based on GC -> Stop purging modules which are garbage collected before shutdown

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812369>
_______________________________________

From report at bugs.python.org  Wed Aug 21 08:29:34 2013
From: report at bugs.python.org (Michael Bikovitsky)
Date: Wed, 21 Aug 2013 06:29:34 +0000
Subject: [issue18790] incorrect text in argparse add_help example
In-Reply-To: <1377025104.92.0.641943823333.issue18790@psf.upfronthosting.co.za>
Message-ID: <1377066574.7.0.158235523299.issue18790@psf.upfronthosting.co.za>


Changes by Michael Bikovitsky <moshe.biko at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31393/doc_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18790>
_______________________________________

From report at bugs.python.org  Wed Aug 21 08:33:12 2013
From: report at bugs.python.org (Michael Bikovitsky)
Date: Wed, 21 Aug 2013 06:33:12 +0000
Subject: [issue18790] incorrect text in argparse add_help example
In-Reply-To: <1377025104.92.0.641943823333.issue18790@psf.upfronthosting.co.za>
Message-ID: <1377066792.39.0.809931709698.issue18790@psf.upfronthosting.co.za>


Changes by Michael Bikovitsky <moshe.biko at gmail.com>:


----------
nosy: +Michael.Bikovitsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18790>
_______________________________________

From report at bugs.python.org  Wed Aug 21 09:05:54 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Aug 2013 07:05:54 +0000
Subject: [issue18794] select.devpoll objects have no close() method
In-Reply-To: <1377037201.39.0.250253331.issue18794@psf.upfronthosting.co.za>
Message-ID: <1377068754.62.0.904557760631.issue18794@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Just to be explicit (there are typos in Victor's original messages): it's about select.devpoll, for Solaris-derivatives with /dev/poll, and not for select.poll, based on poll() syscall.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18794>
_______________________________________

From report at bugs.python.org  Wed Aug 21 09:09:50 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Aug 2013 07:09:50 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1377037941.57.0.378700923278.issue16853@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2-Sk-M-sbq4M4mCKOxA2BNCutFmDkXcDf-J9sDwQafRQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> I've lost track -- who is waiting for whom?  I reviewed the patch selector-12.diff and received zero response AFAICT.  (Maybe the email from Rietveld didn't make it?)

I was on vacation, and then had to cope with many emails :-)
I'll update the patch with your comments soon.

> Maybe the main issue is that I would prefer if the selector classes were in a separate module (selectors.py) than the low-level select/poll/etc. calls.  I think it makes sense if the selectors module *only* defines the high level classes and not the messy low-level stuff, since an app shouldn't be using both at the same time.

I agree with Antoine (i.e. I think select is OK), but if it really
bothers you, I can change it.
I just don't want to do it twice :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Wed Aug 21 09:25:08 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Aug 2013 07:25:08 +0000
Subject: [issue18792] test_ftplib timeouts
In-Reply-To: <1377032489.22.0.759563431169.issue18792@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM00iO5g0YcKHHjEL-b9Kgzkjgxicd3r4fDmaFPkDuBChA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Some ftplib tests sometimes time out. Seem they seem to try to connect to "localhost" (rather than "127.0.0.1"), I was wondering if this could be a DNS issue and if we should resolve "localhost" in advance like Charles-Fran?ois did for some other tests (or simply hardcode "127.0.0.1", actually).

If it only happens on Windows >= 7 buildbots, then it's likely a
consequence of this:
http://serverfault.com/questions/4689/windows-7-localhost-name-resolution-is-handled-within-dns-itself-why

Apparently, since Windows 7, "localhost" doesn't appear in the hosts
file anymore: so, depending on your DNS resolver settings, this could
perfectly explain such timeouts (assuming it's not a firewall issue).

Hard-cording 127.0.0.1 for this test should be OK, because the server
setup explicitly binds an AF_INET socket. We'll probably have to check
the rest of the test suite for similar issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18792>
_______________________________________

From report at bugs.python.org  Wed Aug 21 09:55:45 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Aug 2013 07:55:45 +0000
Subject: [issue18797] Don't needlessly change refcounts of dummy objects for
 sets
Message-ID: <1377071745.56.0.580609331428.issue18797@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

AFAICT, there is no reason for sets to incref and decref dummy objects.  The dummy object address is used as placeholders in the hash table but it is never accessed by set the logic.   As long the one reference is held at the time the dummy object is created, nothing further is served by the increfs and decrefs.

I can take them out entirely or use ifdefs to keep them for debug builds.

Does anyone know of any issues?

----------
components: Interpreter Core
files: no_refcnt_dummy1.diff
keywords: patch
messages: 195751
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Don't needlessly change refcounts of dummy objects for sets
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file31394/no_refcnt_dummy1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18797>
_______________________________________

From report at bugs.python.org  Wed Aug 21 10:04:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 08:04:11 +0000
Subject: [issue18792] test_ftplib timeouts
In-Reply-To: <1377032489.22.0.759563431169.issue18792@psf.upfronthosting.co.za>
Message-ID: <1377072251.9.0.973876835881.issue18792@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Hard-cording 127.0.0.1 for this test should be OK, because the server
> setup explicitly binds an AF_INET socket. We'll probably have to check
> the rest of the test suite for similar issues.

Ok, let's do it!

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18792>
_______________________________________

From report at bugs.python.org  Wed Aug 21 10:05:04 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Aug 2013 08:05:04 +0000
Subject: [issue18797] Don't needlessly change refcounts of dummy objects for
 sets
In-Reply-To: <1377071745.56.0.580609331428.issue18797@psf.upfronthosting.co.za>
Message-ID: <1377072304.58.0.89869418458.issue18797@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18797>
_______________________________________

From report at bugs.python.org  Wed Aug 21 10:11:13 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 08:11:13 +0000
Subject: [issue18797] Don't needlessly change refcounts of dummy objects for
 sets
In-Reply-To: <1377071745.56.0.580609331428.issue18797@psf.upfronthosting.co.za>
Message-ID: <1377072673.66.0.531060693518.issue18797@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +Mark.Shannon, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18797>
_______________________________________

From report at bugs.python.org  Wed Aug 21 10:14:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 08:14:28 +0000
Subject: [issue18797] Don't needlessly change refcounts of dummy objects for
 sets
In-Reply-To: <1377071745.56.0.580609331428.issue18797@psf.upfronthosting.co.za>
Message-ID: <1377072868.16.0.871087207195.issue18797@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I can't think of any counter-indication but I think we shouldn't distinguish between debug and non-debug mode. That way the debug hooks can check that the refcounting optimization is right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18797>
_______________________________________

From report at bugs.python.org  Wed Aug 21 10:58:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 08:58:21 +0000
Subject: [issue18792] test_ftplib timeouts
In-Reply-To: <1377032489.22.0.759563431169.issue18792@psf.upfronthosting.co.za>
Message-ID: <1377075501.82.0.929500692285.issue18792@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch for default.

----------
keywords: +patch
Added file: http://bugs.python.org/file31395/support_host.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18792>
_______________________________________

From report at bugs.python.org  Wed Aug 21 11:03:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 09:03:12 +0000
Subject: [issue18712] Pure Python operator.index doesn't match the C version.
In-Reply-To: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>
Message-ID: <1377075792.21.0.531856196041.issue18712@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18712>
_______________________________________

From report at bugs.python.org  Wed Aug 21 11:13:57 2013
From: report at bugs.python.org (koobs)
Date: Wed, 21 Aug 2013 09:13:57 +0000
Subject: [issue18793] occasional test_multiprocessing_forkserver failure on
 FreeBSD 10.0
In-Reply-To: <1377035945.43.0.272426045772.issue18793@psf.upfronthosting.co.za>
Message-ID: <1377076437.84.0.0385685866538.issue18793@psf.upfronthosting.co.za>


koobs added the comment:

Antoine, did you see: #18762 ? It references the samee failures on 9.x as well.

Do you want to close this as a dupe, or maintain separate issues for each OS?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18793>
_______________________________________

From report at bugs.python.org  Wed Aug 21 11:15:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 09:15:59 +0000
Subject: [issue18793] occasional test_multiprocessing_forkserver failure on
 FreeBSD 10.0
In-Reply-To: <1377035945.43.0.272426045772.issue18793@psf.upfronthosting.co.za>
Message-ID: <1377076559.58.0.776411586182.issue18793@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ha, you're right, we can close this one as a duplicate.

----------
superseder:  -> error in test_multiprocessing_forkserver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18793>
_______________________________________

From report at bugs.python.org  Wed Aug 21 11:25:55 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 09:25:55 +0000
Subject: [issue18794] select.devpoll objects have no close() method
In-Reply-To: <1377037201.39.0.250253331.issue18794@psf.upfronthosting.co.za>
Message-ID: <1377077155.16.0.350558760621.issue18794@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Just to be explicit (there are typos in Victor's original messages): it's about select.devpoll, for Solaris-derivatives with /dev/poll, and not for select.poll, based on poll() syscall."

Oops sorry, yes, I'm talking about select.devpoll, its structure has a "int fd_devpoll;" field:

typedef struct {
    PyObject_HEAD
    int fd_devpoll;
    int max_n_fds;
    int n_fds;
    struct pollfd *fds;
} devpollObject;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18794>
_______________________________________

From report at bugs.python.org  Wed Aug 21 11:31:54 2013
From: report at bugs.python.org (Michael Foord)
Date: Wed, 21 Aug 2013 09:31:54 +0000
Subject: [issue14971] (unittest) loadTestsFromName does not work on method
 with a decorator
In-Reply-To: <1338490939.51.0.536223048687.issue14971@psf.upfronthosting.co.za>
Message-ID: <1377077514.6.0.978674494998.issue14971@psf.upfronthosting.co.za>


Michael Foord added the comment:

Cool, thanks!

----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14971>
_______________________________________

From report at bugs.python.org  Wed Aug 21 11:33:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 09:33:16 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1377077596.58.0.317556542548.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yet some nitpicks.

Currently the code of _PyLong_FromNbInt() is inlined and the do_decref flag is used to prevent needless change refcounts of int objects (see also issue18797). In proposed patch common code is extracted into the _PyLong_FromNbInt() function and int objects increfed and decrefed. Doesn't it affect a performance? PyLong_As* functions used in arguments parsing in a lot of builtins and their .performance is important.

If the patch slowdowns PyLong_As* functions we perhaps should check PyLong_CheckExact() before calling _PyLong_FromNbInt() and use the do_decref flag.

In general the idea and the patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Wed Aug 21 11:37:26 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 09:37:26 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <CAH_1eM2-Sk-M-sbq4M4mCKOxA2BNCutFmDkXcDf-J9sDwQafRQ@mail.gmail.com>
Message-ID: <CAMpsgwbdZTFE2bGzSX5HWtDomxaxDWKxkPakbDVBxGx_aF2=-A@mail.gmail.com>


STINNER Victor added the comment:

I like the idea of renaming select to _select, and add Lib/select.py
for the high-level wrapper (Selector). In my opinion, adding a module
just for 5 classes is overkill. Selector classes are a very thin
abstraction over the low-level objects. A new module can be justified
for something more evolved, something like an event loop with
callbacks and a scheduler, something like the PEP 3156 (tulip) :-)

This issue is for code written in Python. Is it a similar issue for
code written in C? internal_select_ex() of Modules/socketmodule.c and
check_socket_and_wait_for_timeout() of Modules/_ssl.c uses poll() and
select().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Wed Aug 21 11:41:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 09:41:00 +0000
Subject: [issue18794] select.devpoll objects have no close() method
In-Reply-To: <1377037201.39.0.250253331.issue18794@psf.upfronthosting.co.za>
Message-ID: <1377078060.1.0.848784772395.issue18794@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18794>
_______________________________________

From report at bugs.python.org  Wed Aug 21 11:44:27 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Aug 2013 09:44:27 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377078267.22.0.222957122817.issue18713@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think the essential use case is using a python program in a unix pipeline.  I'm very sympathetic to that use case, despite my unease.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Wed Aug 21 11:58:05 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Aug 2013 09:58:05 +0000
Subject: [issue18795] pstats - allow stats sorting by cumulative time per call
 and total time per call
In-Reply-To: <1377042491.98.0.765142916486.issue18795@psf.upfronthosting.co.za>
Message-ID: <1377079085.37.0.457869062171.issue18795@psf.upfronthosting.co.za>


R. David Murray added the comment:

I believe the module already supports sorting by time and cumulative time (determining the top consumers of cpu is a major part of the point of the profile module, after all).  

What exactly is the change that you are proposing?  If you post a diff instead of a modified copy of the module it would be easier to see what you are proposing.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18795>
_______________________________________

From report at bugs.python.org  Wed Aug 21 12:06:15 2013
From: report at bugs.python.org (Alexandre Dias)
Date: Wed, 21 Aug 2013 10:06:15 +0000
Subject: [issue18795] pstats - allow stats sorting by cumulative time per call
 and total time per call
In-Reply-To: <1377042491.98.0.765142916486.issue18795@psf.upfronthosting.co.za>
Message-ID: <1377079575.44.0.334415504392.issue18795@psf.upfronthosting.co.za>


Alexandre Dias added the comment:

It does support sorting by total time and cumulative time spent on a function, but not by the time per each call of that function.

I've uploaded a diff of the patch.

-Alexandre

----------
versions: +Python 3.4 -Python 2.7
Added file: http://bugs.python.org/file31396/pstats-diff-issue18795.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18795>
_______________________________________

From report at bugs.python.org  Wed Aug 21 12:22:18 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 10:22:18 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1377080538.25.0.0551283820478.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

On PyPy 1.8.0 operator.index(True) returns 1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Wed Aug 21 12:23:16 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 10:23:16 +0000
Subject: [issue18794] select.devpoll objects have no close() method
In-Reply-To: <1377037201.39.0.250253331.issue18794@psf.upfronthosting.co.za>
Message-ID: <1377080596.68.0.394641939053.issue18794@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"This all sounds fine to fix without waiting for anything else -- can you attach a patch here?"

I opened the issue as a reminder for me. Here is a patch.

 * Add close() and fileno() methods and a closed attribute (property) to devpoll object
 * Document closed attribute of epoll and kqueue objects
 * Add tests on closed object for devpoll, epoll and kqueue. There was no test for devpoll, epoll nor kqueue :-(

select.poll is still not tested. We should add much more tests, especially tests checking than a fd becomes ready for each implementation. We may develop these tests using #16853 ?

I ran test_select on Linux, so I only checked the epoll unit test.

The "closed" attribute of epoll and kqueue objects should also be documented in Python 2.7 and 3.3.

----------
keywords: +patch
Added file: http://bugs.python.org/file31397/devpoll_close.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18794>
_______________________________________

From report at bugs.python.org  Wed Aug 21 12:25:14 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Aug 2013 10:25:14 +0000
Subject: [issue18792] test_ftplib timeouts
In-Reply-To: <1377075501.82.0.929500692285.issue18792@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1Amj06aC4NqQTUwVJdDuaLzu4+yb3pz_33+=Xmx1S53w@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Changing support.HOST from 'localhost' to '127.0.0.1' means that on dual-stack
hosts (I don't think the test suite would run on IPv6-only hosts anyway), the
tests will now always use IPv4, whereas they are currently using either IPv6 or
IPv4 addresses depending on the host's name resolution settings.
For example, on a RHEL6 box:

>>> socket.getaddrinfo('localhost', 0)
[(10, 1, 6, '', ('::1', 0, 0, 0)), (10, 2, 17, '', ('::1', 0, 0, 0)),
(10, 3, 0, '', ('::1', 0, 0, 0)), (2, 1, 6, '', ('127.0.0.1', 0)), (2,
2, 17, '', ('127.0.0.1', 0)), (2, 3, 0, '', ('127.0.0.1', 0))]

So on this host, 'localhost' resolves to '::1'. I think it would be
better to have support.HOST set to socket.getaddrinfo('localhost', 0)[0][4][0]
(sic), so that the test will use the preferred protocol on the target host, and
also that IPv6 is also tested in tests which don't explicitely use
'::1'. But this
means that we should have an support.HOSTv4 for tests that explicitly rely on
IPv4, e.g.  test_ftplib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18792>
_______________________________________

From report at bugs.python.org  Wed Aug 21 12:25:17 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Aug 2013 10:25:17 +0000
Subject: [issue18795] pstats - allow stats sorting by cumulative time per call
 and total time per call
In-Reply-To: <1377042491.98.0.765142916486.issue18795@psf.upfronthosting.co.za>
Message-ID: <1377080717.47.0.919253789061.issue18795@psf.upfronthosting.co.za>


R. David Murray added the comment:

It would be clearer, I think, to call it average time.  I must admit to not being sure why that is useful.  I'm also worried there might be backward compatibility issues with changing the ordering of the data structure.  If new fields are going to be added they should probably be added at the end.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18795>
_______________________________________

From report at bugs.python.org  Wed Aug 21 12:29:20 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 21 Aug 2013 10:29:20 +0000
Subject: [issue18798] Typo and unused variables in test fcntl
Message-ID: <1377080960.53.0.565624911125.issue18798@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Typo in line 11:
# Skip test if no fnctl module.

Unused variables rv in test_fcntl_file_descriptor method.

Attached the patch to clean up the test.

----------
components: Tests
files: fix_typo_unused_variables_in_test_fcntl.patch
keywords: patch
messages: 195768
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Typo and unused variables in test fcntl
versions: Python 3.4
Added file: http://bugs.python.org/file31398/fix_typo_unused_variables_in_test_fcntl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18798>
_______________________________________

From report at bugs.python.org  Wed Aug 21 12:38:53 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 10:38:53 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1377078267.22.0.222957122817.issue18713@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZSk2k41uRgph3y9fF3jc75Wbss+9wz3wqa2ADHRHoP0A@mail.gmail.com>


STINNER Victor added the comment:

Currently, Python 3 fails miserabily when it gets a non-ASCII
character from stdin or when it tries to write a byte encoded as a
Unicode surrogate to stdout.

It works fine when OS data can be decoded from and encoded to the
locale encoding. Example on Linux with UTF-8 data and UTF-8 locale
encoding:

$ mkdir test
$ cd test
$ touch h?h?.txt
$ ls
h?h?.txt
$ python3 -c 'import os; print(", ".join(os.listdir()))'
h?h?.txt
$ echo "h?h?"|python3 -c 'import sys; sys.stdout.write(sys.stdin.read())'|cat
h?h?

It fails miserabily when OS data cannot be decoded from or encoded to
the locale encoding. Example on Linux with UTF-8 data and ASCII locale
encoding:

$ mkdir test
$ cd test
$ touch h?h?.txt
$ export LANG=  # switch to ASCII locale encoding
$ ls
h??h??.txt
$ python3 -c 'import os; print(", ".join(os.listdir()))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position
1-2: ordinal not in range(128)

$ echo "h?h?"|LANG= python3 -c 'import sys;
sys.stdout.write(sys.stdin.read())'|cat
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/vstinner/prog/python/default/Lib/encodings/ascii.py",
line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
1: ordinal not in range(128)

The ls output is not the expected "h?h?" string, but it is an issue
with the console output, not the ls program. ls does just write raw
bytes to stdout:

$ ls|hexdump -C
00000000  68 c3 a9 68 c3 a9 2e 74  78 74 0a                 |h..h...txt.|
0000000b

("h?h?" encoded to UTF-8 gives b'h\xc3\xa9h\xc3\xa9')

I agree that we can do something to improve the situation on standard
streams, but only on standard streams. It is already possible to
workaround the issue by forcing the surrogateescape error handler on
stdout:

$ LANG= PYTHONIOENCODING=utf-8:surrogateescape python3 -c 'import os;
print(", ".join(os.listdir()))'
h?h?.txt

Something similar can be done in Python. For example,
test.support.regrtest reopens sys.stdout to set the error handle to
"backslashreplace". Extract of the replace_stdout() function:

    sys.stdout = open(stdout.fileno(), 'w',
        encoding=sys.stdout.encoding,
        errors="backslashreplace",
        closefd=False,
        newline='\n')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Wed Aug 21 12:43:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 10:43:57 +0000
Subject: [issue18792] test_ftplib timeouts
In-Reply-To: <CAH_1eM1Amj06aC4NqQTUwVJdDuaLzu4+yb3pz_33+=Xmx1S53w@mail.gmail.com>
Message-ID: <2126158028.2393321.1377081830484.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Changing support.HOST from 'localhost' to '127.0.0.1' means that on
> dual-stack
> hosts (I don't think the test suite would run on IPv6-only hosts
> anyway), the
> tests will now always use IPv4, whereas they are currently using
> either IPv6 or
> IPv4 addresses depending on the host's name resolution settings.

That would only be true if the server we are contacting happens to
listen on both IPv6 and IPv4, right? I don't think we have such a
situation in the test suite. Clients can use create_connection()
for transparent support of IPv6 and IPv4, but servers have to choose
a family when creating their socket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18792>
_______________________________________

From report at bugs.python.org  Wed Aug 21 12:58:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 10:58:38 +0000
Subject: [issue18794] select.devpoll objects have no close() method
In-Reply-To: <1377037201.39.0.250253331.issue18794@psf.upfronthosting.co.za>
Message-ID: <1377082718.11.0.141098949313.issue18794@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

poll, devpoll, epoll and kqueue are tested in test_poll.py, test_devpoll.py, test_epoll.py and test_kqueue.py test files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18794>
_______________________________________

From report at bugs.python.org  Wed Aug 21 13:32:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 11:32:36 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1377084756.17.0.93479943928.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And yet one nitpick. For int subclasses which doesn't overload the __int__ method the patch calls default int.__int__ which creates a copy of int object. This is redundant in PyLong_As* functions because they only extract C int value and drop Python int object. So we can use int subclass object itself as good as int object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Wed Aug 21 13:37:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 11:37:37 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1377085057.31.0.194973740173.issue18738@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

>> print(member)
>> "%s" % member
>> "{}".format(member)
>
> Would you seriously use either of those last two in either the debugger 
or the command line?

Yes, of course. When you need debug output from function or loop inners.

    for ...:
        ...
        print('stage1(%s) = [%s:%s] %s' % (i, start, stop, result))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 21 13:43:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Aug 2013 11:43:29 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <3cKn7h2nzrz7LmC@mail.python.org>


Roundup Robot added the comment:

New changeset 8e1194c39bed by Christian Heimes in branch '3.3':
Issue #18747: Re-seed OpenSSL's pseudo-random number generator after fork.
http://hg.python.org/cpython/rev/8e1194c39bed

New changeset 49e23a3adf26 by Christian Heimes in branch 'default':
Issue #18747: Re-seed OpenSSL's pseudo-random number generator after fork.
http://hg.python.org/cpython/rev/49e23a3adf26

New changeset 2e6aa6c29be2 by Christian Heimes in branch '2.7':
Issue #18747: Re-seed OpenSSL's pseudo-random number generator after fork.
http://hg.python.org/cpython/rev/2e6aa6c29be2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 13:43:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 11:43:54 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1377085434.91.0.776025507487.issue18738@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm proposing to split this issue on two issues. One for C-style formatting (I guess everyone agree that '%i' % <int-like object> should return decimal representation of its numerical value) and other for format() which is more questionable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 21 13:45:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 11:45:28 +0000
Subject: [issue18743] References to non-existant "StringIO" module
In-Reply-To: <1376542911.78.0.658455842148.issue18743@psf.upfronthosting.co.za>
Message-ID: <1377085528.84.0.218997205219.issue18743@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18743>
_______________________________________

From report at bugs.python.org  Wed Aug 21 13:46:05 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Wed, 21 Aug 2013 11:46:05 +0000
Subject: [issue17916] Provide dis.Bytecode based equivalent of dis.distb
In-Reply-To: <1367844864.14.0.49825143621.issue17916@psf.upfronthosting.co.za>
Message-ID: <1377085565.09.0.948361678112.issue17916@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Here's a basic patch, using a classmethod. It doesn't support the full distb API (if the traceback is not given, try to retrieve the last one), because Bytecode.from_tb() looks pretty weird.

----------
keywords: +patch
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file31399/dis.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17916>
_______________________________________

From report at bugs.python.org  Wed Aug 21 13:49:05 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 21 Aug 2013 11:49:05 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1377085745.39.0.491921665481.issue18747@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I have taken care of Antoine's and Victor's reviews. The fix has landed in Python 2.7, 3.3 and 3.4. What about 2.6, 3.1 and 3.2? After all it's a security fix (although I don't consider its severity as high).

----------
nosy: +barry, benjamin.peterson, georg.brandl
stage: patch review -> commit review
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 14:03:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 12:03:07 +0000
Subject: [issue18780] SystemError when formatting int subclass
In-Reply-To: <1376921434.69.0.557024484243.issue18780@psf.upfronthosting.co.za>
Message-ID: <1377086587.91.0.730783072788.issue18780@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think we should just use PyNumber_ToBase() for any int and int subclass. The calling __str__() for special case looks weird.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18780>
_______________________________________

From report at bugs.python.org  Wed Aug 21 14:03:15 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Aug 2013 12:03:15 +0000
Subject: [issue18792] test_ftplib timeouts
In-Reply-To: <2126158028.2393321.1377081830484.JavaMail.root@zimbra10-e2.priv.proxad.net>
Message-ID: <CAH_1eM3K0dK+=4xB8n0gwy=9q8eb3WLofpuQj4EmZ9hayLUN7g@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> That would only be true if the server we are contacting happens to
> listen on both IPv6 and IPv4, right? I don't think we have such a
> situation in the test suite.

Ah, I thought some code was using getaddrinfo() to select an arbitrary
bind() address for localhost.

That's OK then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18792>
_______________________________________

From report at bugs.python.org  Wed Aug 21 14:04:48 2013
From: report at bugs.python.org (irdb)
Date: Wed, 21 Aug 2013 12:04:48 +0000
Subject: [issue15809] IDLE console uses incorrect encoding.
In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za>
Message-ID: <1377086688.97.0.979460545637.issue15809@psf.upfronthosting.co.za>


irdb added the comment:

How about passing on UnicodeError? Will it cause other problems?

----------
Added file: http://bugs.python.org/file31400/PyShell.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15809>
_______________________________________

From report at bugs.python.org  Wed Aug 21 14:08:26 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Aug 2013 12:08:26 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1377085745.39.0.491921665481.issue18747@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM31NVvvy=rgbX8HNdDtW=3wu6MehPQydyfiz=fVHchSEA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Christian Heimes added the comment:
>
> I have taken care of Antoine's and Victor's reviews. The fix has landed in Python 2.7, 3.3 and 3.4. What about 2.6, 3.1 and 3.2? After all it's a security fix (although I don't consider its severity as high).

There's still the #if 0 in the patch you committed.

And basically, because PySSL_RAND_atfork_child() is not async-signal
safe, the interpreter is now subject to random deadlocks/crash in
multi-threaded processes. I personally don't consider this a security
fix...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 14:08:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 12:08:35 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1377085745.39.0.491921665481.issue18747@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbasVtoB+Z6a+8SKmJQPe4CiEFt4cS-ketf25H3RFUeRQ@mail.gmail.com>


STINNER Victor added the comment:

3.52 +#if 0
    3.53 +    fprintf(stderr, "PySSL_RAND_atfork_child() seeds %i
bytes in pid %i\n",
    3.54 +            (int)sizeof(seed), seed.pid);
    3.55 +#endif

Don't you want to remove this debug code?

     1.8 +    def test_random_fork(self):
     1.9 +        status = ssl.RAND_status()
    1.10 +        if not status:
    1.11 +            self.fail("OpenSSL's PRNG has insufficient randomness")

The test uses ssl.RAND_pseudo_bytes(), the check on ssl.RAND_status()
must be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 14:20:24 2013
From: report at bugs.python.org (irdb)
Date: Wed, 21 Aug 2013 12:20:24 +0000
Subject: [issue15809] IDLE console uses incorrect encoding.
In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za>
Message-ID: <1377087624.09.0.638876129066.issue15809@psf.upfronthosting.co.za>


irdb added the comment:

Sorry, it's probably has the same problem as what Martin suggested. Although I think it's better than having program interrupted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15809>
_______________________________________

From report at bugs.python.org  Wed Aug 21 14:22:55 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 21 Aug 2013 12:22:55 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <CAH_1eM31NVvvy=rgbX8HNdDtW=3wu6MehPQydyfiz=fVHchSEA@mail.gmail.com>
Message-ID: <5214B11D.9020205@cheimes.de>


Christian Heimes added the comment:

Am 21.08.2013 14:08, schrieb Charles-Fran?ois Natali:
> And basically, because PySSL_RAND_atfork_child() is not async-signal
> safe, the interpreter is now subject to random deadlocks/crash in
> multi-threaded processes. I personally don't consider this a security
> fix...

Which part of the function is not async-signal safe? It doesn't interact
with any file descriptors nor does it use any syscalls except for
getpid() and time().

Python's _ssl module doesn't re-initialize its locks on fork. That's an
outstanding issue that is not related to the change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 14:26:33 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Aug 2013 12:26:33 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1377085434.91.0.776025507487.issue18738@psf.upfronthosting.co.za>
Message-ID: <5214B1F6.3030004@stoneleaf.us>


Ethan Furman added the comment:

Serhiy Storchaka added the comment:
>
> I'm proposing to split this issue on two issues. One for C-style formatting (I guess everyone agree that '%i' % <int-like object> should return decimal representation of its numerical value) and other for format() which is more questionable.

Not sure that's necessary.  The code to fix the C-style %-formatting is 
already (I think)  in the last patch I attached.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 21 14:45:14 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Aug 2013 12:45:14 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <5214B11D.9020205@cheimes.de>
Message-ID: <CAH_1eM2S0p-XeFOV3WyWOzSkwJSL+pi+tT+dFL4t5C3-_OWEqA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Which part of the function is not async-signal safe? It doesn't interact
> with any file descriptors nor does it use any syscalls except for
> getpid() and time().

gettimeofday() and RAND_add()

The functions which are guaranteed to be async-signal safe are listed here:
https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers

And here's what David Butenhof says about pthread_atfork():
"""
The real answer is that pthread_atfork() is a completely useless and stupid
mechanism that was a well intentioned but ultimately pointless attempt to
carve a "back door" solution out of an inherently insoluable design
conflict.
"""

More here:
https://groups.google.com/forum/#!msg/comp.programming.threads/ThHE32-vRsg/3j-YICgSQzoJ

IMO it's really an openssl issue, and it should be fixed there (mainly
because they are the only one in position of setuping a safe
atfork-hook, like the glibc does for malloc & co).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 15:08:55 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 21 Aug 2013 13:08:55 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1377090535.96.0.400666901962.issue18747@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Do you have a proposal for a better way to fix the issue? I don't think that we can hope for a fix from OpenSSL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 15:23:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 13:23:43 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1377090535.96.0.400666901962.issue18747@psf.upfronthosting.co.za>
Message-ID: <244612104.2745072.1377091416489.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Do you have a proposal for a better way to fix the issue? I don't
> think that we can hope for a fix from OpenSSL.

Instead of reseeding in the child, you can perturb the state in the parent
after fork. As far as I understand, only the "child" callback in
pthread_atfork() needs to be async-signal-safe:

"It is suggested that programs that use fork() call an exec function
very soon afterwards in the child process, thus resetting all states.
In the meantime, only a short list of async-signal-safe library
routines are promised to be available."
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_atfork.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 15:34:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 13:34:08 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1377092048.01.0.372046587379.issue18738@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Not sure that's necessary.  The code to fix the C-style %-formatting is 
already (I think)  in the last patch I attached.

Could you please extract this part of the patch and add tests? It can be reviewed and committed separately. See also issue18780, there is a more serious problem with current code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 21 15:40:12 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Aug 2013 13:40:12 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1377092412.07.0.290091735264.issue18738@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I agree splitting this makes sense, so as to not delay the %-formatting fix. While similar in principle, the fixes are unrelated. We may as well keep this issue the __format__ part, since it's been most discussed here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 21 15:43:13 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 21 Aug 2013 13:43:13 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1377092412.07.0.290091735264.issue18738@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda9wz+b44LiWMap7Ecgd8ByznQH6h-Dr+8mzTNNvRkyBYw@mail.gmail.com>


Eli Bendersky added the comment:

On Wed, Aug 21, 2013 at 6:40 AM, Eric V. Smith <report at bugs.python.org>wrote:

>
> Eric V. Smith added the comment:
>
> I agree splitting this makes sense, so as to not delay the %-formatting
> fix. While similar in principle, the fixes are unrelated. We may as well
> keep this issue the __format__ part, since it's been most discussed here.
>

+1

$REALLIFE took over in the past few days but I'll be back towards the
weekend and want to review this part too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 21 15:47:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 13:47:04 +0000
Subject: [issue15809] IDLE console uses incorrect encoding.
In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za>
Message-ID: <1377092824.36.0.0302345850238.issue15809@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> How about passing on UnicodeError?

I don't see how it will resolve any problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15809>
_______________________________________

From report at bugs.python.org  Wed Aug 21 15:50:32 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 21 Aug 2013 13:50:32 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1377093032.29.0.543929128201.issue18738@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Serhiy, if you feel this is related to #18780 maybe they can be merged into a single issue (since the comment on #18780 says the fix here will work there too)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 21 15:51:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 13:51:30 +0000
Subject: [issue18780] SystemError when formatting int subclass
In-Reply-To: <1376921434.69.0.557024484243.issue18780@psf.upfronthosting.co.za>
Message-ID: <1377093090.25.0.0680794654265.issue18780@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +barry, eli.bendersky, eric.smith, ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18780>
_______________________________________

From report at bugs.python.org  Wed Aug 21 15:56:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 13:56:08 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1377093368.13.0.301343522115.issue18738@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I rather think that two discussions about two almost unrelated series of patches in same issue will be confused.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 21 16:13:14 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 21 Aug 2013 14:13:14 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377094394.74.0.747077666769.issue18713@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Wed Aug 21 16:14:26 2013
From: report at bugs.python.org (irdb)
Date: Wed, 21 Aug 2013 14:14:26 +0000
Subject: [issue15809] IDLE console uses incorrect encoding.
In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za>
Message-ID: <1377094466.55.0.118002026832.issue15809@psf.upfronthosting.co.za>


irdb added the comment:

Oops! My problem is that I get "Unsupported characters in input" when trying to type any Unicode string in IDLE's interactive mode.

e.g. a simple command like: s = u'??????? ?????' gives: Unsupported characters in input

Probably unrelated to the issue at hand. I don't know how I ended up in this thread. Again, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15809>
_______________________________________

From report at bugs.python.org  Wed Aug 21 16:46:08 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Aug 2013 14:46:08 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <244612104.2745072.1377091416489.JavaMail.root@zimbra10-e2.priv.proxad.net>
Message-ID: <CAH_1eM1bmgDkyXVLgd7-Q+F57JCMVMj=LVHdeJO9AWHuXkWJSQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

2013/8/21 Antoine Pitrou <report at bugs.python.org>:
> Instead of reseeding in the child, you can perturb the state in the parent
> after fork.
> As far as I understand, only the "child" callback in pthread_atfork() needs to be async-signal-safe:

That's not completely true: fork() is supposed to be async-signal
safe: it can be called from a signal handler (I wouldn't do this, but
that's allowed), but most notably, it can be called after another
fork().
For example, let's say you have a multi-threaded process, and it
fork()s. If you reseed from "parent" (right before or after fork),
then it's safe. But once you're in the child process, the process
state is "unsafe" until exec(), i.e. you can only call async-signal
safe functions. So if you fork() again before exec() - which is
common, e.g. if you use the double-fork() idiom for daemons - then
you'll call the reseed in an unsafe context. In other words, the
"parent" callback is called in the context of a "child" callback in
the child process.

So it's not really safe either, although the window is narrower.

The only 100% safe way I can think of - apart from ignoring the
problem - would be to check if the PID has changed upon entering ssl
function (caching it to avoid calling getpid() everytime), keeping in
mind that there will still be the risk of deadlock/crash anyway if the
user enters the ssl library before exec()...

Another, probably cleaner way would be to finally add the atfork()
module (issue #16500), and register this reseed hook (which could then
be implemented in ssl.py).

forking() in a multi-threaded context is an unsolvable problem...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 17:27:33 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 21 Aug 2013 15:27:33 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <CAH_1eM1bmgDkyXVLgd7-Q+F57JCMVMj=LVHdeJO9AWHuXkWJSQ@mail.gmail.com>
Message-ID: <5214DC5D.6020002@gmail.com>


Richard Oudkerk added the comment:

On 21/08/2013 3:46pm, Charles-Fran?ois Natali wrote:
> Another, probably cleaner way would be to finally add the atfork()
> module (issue #16500), and register this reseed hook (which could then
> be implemented in ssl.py).

Wouldn't that still suffer from the double-fork() issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 17:27:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 15:27:45 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <CAH_1eM1bmgDkyXVLgd7-Q+F57JCMVMj=LVHdeJO9AWHuXkWJSQ@mail.gmail.com>
Message-ID: <1531961380.2987028.1377098859439.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> [snip insightful explanation]
> So it's not really safe either, although the window is narrower.

Gosh. Well, the narrower window would be fine with me :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 17:47:05 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Aug 2013 15:47:05 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1377100025.48.0.458791410583.issue18772@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Antoine, can you please verify the gdb plug-in is working again?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Wed Aug 21 17:57:23 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 21 Aug 2013 15:57:23 +0000
Subject: [issue18799] Resurrect and fix test_404 in Lib/test/test_xmlrpc.py
Message-ID: <1377100643.52.0.970396135479.issue18799@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

There is a dormant test in Lib/test/test_xmlrpc.py (line 579):

    # [ch] The test 404 is causing lots of false alarms.
    def XXXtest_404(self):
        # send POST with http.client, it should return 404 header and
        # 'Not Found' message.
        conn = httplib.client.HTTPConnection(ADDR, PORT)
        conn.request('POST', '/this-is-not-valid')
        response = conn.getresponse()
        conn.close()

        self.assertEqual(response.status, 404)
        self.assertEqual(response.reason, 'Not Found')

I decided to test it by removing 'XXX' and adding 'import httplib'. Yes, it hung up.

But then I looked at its sibling:

    def test_partial_post(self):
        # Check that a partial POST doesn't make the server loop: issue #14001.
        conn = http.client.HTTPConnection(ADDR, PORT)
        conn.request('POST', '/RPC2 HTTP/1.0\r\nContent-Length: 100\r\n\r\nbye')
        conn.close()

I tried to use http module instead of httplib. It works. I tested it on Linux and Windows Vista. It works on both platforms.

Attached the patch to fix the resurrect and fix the test_404.

----------
components: Tests
files: fix_test_404.patch
keywords: patch
messages: 195800
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Resurrect and fix test_404 in Lib/test/test_xmlrpc.py
versions: Python 3.4
Added file: http://bugs.python.org/file31401/fix_test_404.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18799>
_______________________________________

From report at bugs.python.org  Wed Aug 21 18:15:14 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 21 Aug 2013 16:15:14 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <CAMpsgwbdZTFE2bGzSX5HWtDomxaxDWKxkPakbDVBxGx_aF2=-A@mail.gmail.com>
Message-ID: <CAP7+vJKP=mkOhqS6VnbLf3bjRnM8RdAVYCbUDdkgKznM_rMyWQ@mail.gmail.com>


Guido van Rossum added the comment:

On Wed, Aug 21, 2013 at 2:37 AM, STINNER Victor <report at bugs.python.org>wrote:

>
> STINNER Victor added the comment:
>
> I like the idea of renaming select to _select, and add Lib/select.py
> for the high-level wrapper (Selector). In my opinion, adding a module
> just for 5 classes is overkill. Selector classes are a very thin
> abstraction over the low-level objects. A new module can be justified
> for something more evolved, something like an event loop with
> callbacks and a scheduler, something like the PEP 3156 (tulip) :-)
>

OK, I'm just going to impose my decision. I want a separate selectors.py.
The rename business feels unpleasant, *and* the interface abstraction level
is different.

> This issue is for code written in Python. Is it a similar issue for
> code written in C? internal_select_ex() of Modules/socketmodule.c and
> check_socket_and_wait_for_timeout() of Modules/_ssl.c uses poll() and
> select().
>

Let's leave those alone. AFAIK they are mostly to simulate timeouts in
*blocking* code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Wed Aug 21 18:22:22 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 21 Aug 2013 16:22:22 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1377102142.6.0.811685482026.issue18747@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Oh heck, signal, threads and fork really don't mix. :(
Under which condition can a non-async safe function cause trouble? Is it just fork() inside a signal handler or can an incoming signal during fork() also cause havoc?

The OpenSSL PRNG is only buggy when used in a forking application where the master process initializes the PRNG but never uses it. All child processes inherit the same state. OpenSSL tries to work around the problem by feeding the PID into the PRNG state. But as soon as PIDs get recycled, subsequent child processes get the same random numbers.

Antoine's proposal works, too, because it perturbs the master's PRNG state regularly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 18:27:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Aug 2013 16:27:53 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
 functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <3cKvRr2NQsz7LjV@mail.python.org>


Roundup Robot added the comment:

New changeset 84d74eb7a341 by Charles-Fran?ois Natali in branch '2.7':
Issue #15233: Python now guarantees that callables registered with the atexit
http://hg.python.org/cpython/rev/84d74eb7a341

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15233>
_______________________________________

From report at bugs.python.org  Wed Aug 21 18:45:23 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Aug 2013 16:45:23 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <5214DC5D.6020002@gmail.com>
Message-ID: <CAH_1eM16NDNvsX2nGpeeDx0u1zZX51CtDvps_0ppJQr+ypKuuw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

>> Another, probably cleaner way would be to finally add the atfork()
>> module (issue #16500), and register this reseed hook (which could then
>> be implemented in ssl.py).
>
> Wouldn't that still suffer from the double-fork() issue?

Not for the "officially" supported way of creating child processes,
subprocess, since it calls fork() + exec() from C.
The problem with pthread_atfork() is that it would make the whole
interpreter non-safe even for correct code paths that call fork() +
exec(), which is not the case now.

Not reseeding with pthread_atfork() or atfork module, but only when
the ssl library is entered, just means that if a deadlock must occur,
it will only occur if the process re-enters the ssl library after
fork().

> Under which condition can a non-async safe function cause trouble? Is it just fork() inside a signal handler or can an incoming signal during fork() also cause havoc?

Actually, it doesn't need a signal to cause havoc: imagine that thread
A is inside an ssl function, holding a mutex protecting process-wide
internal ssl data. Then, thread B forks: in the child process, the ssl
mutex is already held (since the adress space is COW), so upon next
ssl library call in the child, the process will deadlock (trying to
acquire a mutex already held). That's an example with lock, but the
same holds if the library uses a global/static variable, etc. As an
approximation, sync-signal safe means "reentrant" (async-signal safe
comes from the fact that such restrictions apply to signal handler,
for the exact same reasons).

So you can pretty much only use reentrant functions between fork() and
exec() in a multi-threaded process (i.e. no malloc(), no strtok()...).
Which basically means that you can't run Python code at all between
fork() and exec() in a multi-threaded code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Wed Aug 21 18:47:44 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Aug 2013 16:47:44 +0000
Subject: [issue15233] atexit: guarantee order of execution of registered
 functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1377103664.14.0.756293823332.issue15233@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Backported to 2.7.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15233>
_______________________________________

From report at bugs.python.org  Wed Aug 21 18:49:24 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Aug 2013 16:49:24 +0000
Subject: [issue18792] test_ftplib timeouts
In-Reply-To: <1377032489.22.0.759563431169.issue18792@psf.upfronthosting.co.za>
Message-ID: <1377103764.03.0.835590981055.issue18792@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18792>
_______________________________________

From report at bugs.python.org  Wed Aug 21 19:04:37 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Aug 2013 17:04:37 +0000
Subject: [issue18799] Resurrect and fix test_404 in Lib/test/test_xmlrpc.py
In-Reply-To: <1377100643.52.0.970396135479.issue18799@psf.upfronthosting.co.za>
Message-ID: <1377104677.16.0.533854845073.issue18799@psf.upfronthosting.co.za>


R. David Murray added the comment:

"A lot of false alarms" means usually it works, but then sometimes it doesn't.  So just testing it on a couple of platforms isn't sufficient, unfortunately.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18799>
_______________________________________

From report at bugs.python.org  Wed Aug 21 19:05:46 2013
From: report at bugs.python.org (icedream91)
Date: Wed, 21 Aug 2013 17:05:46 +0000
Subject: [issue18800] Document Fraction's numerator and denominator properties
Message-ID: <1377104746.66.0.571132107535.issue18800@psf.upfronthosting.co.za>


New submission from icedream91:

The document (http://docs.python.org/3/library/fractions.html) doesn't mention Fraction's numerator and denominator properties, I knew these properties from dir().

Since sometimes these two properties are very useful, for example: http://projecteuler.net/problem=33 and http://projecteuler.net/problem=57 , I think document should mention them. 

Thanks.

----------
assignee: docs at python
components: Documentation
messages: 195808
nosy: docs at python, icedream91
priority: normal
severity: normal
status: open
title: Document Fraction's numerator and denominator properties
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18800>
_______________________________________

From report at bugs.python.org  Wed Aug 21 19:14:27 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Wed, 21 Aug 2013 17:14:27 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1377016150.94.0.826022208403.issue12641@psf.upfronthosting.co.za>
Message-ID: <CAHVvXxTaYv9a66PVEXqJBOR=0tfnTvQGeJjf0SK65P-L3z-ZHQ@mail.gmail.com>


Oscar Benjamin added the comment:

I just noticed today that the fix that implemented by these patches
(only providing -mno-cygwin if gcc_ver < 4) is also used by numpy's
distutils. You can see the relevant code here:

https://github.com/numpy/numpy/blob/master/numpy/distutils/mingw32ccompiler.py#L117

The relevant commit was three years ago:

https://github.com/numpy/numpy/commit/9dd7c7b8ad826beefbbc0c10ff457c62f1be223d

They haven't bothered with checking for cygwin gcc (my patches only do
this to try and show a helpful error message).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Aug 21 19:16:35 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Aug 2013 17:16:35 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1376691835.07.0.666456900735.issue18763@psf.upfronthosting.co.za>
Message-ID: <1377105395.68.0.441955483316.issue18763@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Wed Aug 21 19:48:18 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Aug 2013 17:48:18 +0000
Subject: [issue18797] Don't needlessly change refcounts of dummy objects for
 sets
In-Reply-To: <1377071745.56.0.580609331428.issue18797@psf.upfronthosting.co.za>
Message-ID: <1377107298.79.0.403986014227.issue18797@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> I think we shouldn't distinguish between debug and non-debug mode.

That makes good sense.
Attaching a new patch without the #ifdefs.

----------
Added file: http://bugs.python.org/file31402/no_refcnt_dummy2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18797>
_______________________________________

From report at bugs.python.org  Wed Aug 21 20:08:53 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Aug 2013 18:08:53 +0000
Subject: [issue16611] Cookie.py does not parse httponly or secure cookie flags
In-Reply-To: <1354654224.49.0.677339520856.issue16611@psf.upfronthosting.co.za>
Message-ID: <1377108533.46.0.321681030597.issue16611@psf.upfronthosting.co.za>


R. David Murray added the comment:

Backward compatibility is a concern.  However, having the flags test true when present, which they don't currently, should be considered a bug fix, I think.

So, I added a some tests to confirm the current behavior, and wrote a new patch that *just* fixes the 'test true if present' bug, leaving the other behaviors unchanged.  Reviews appreciated.  And if anyone can think of tests I missed, please let me know; I'm a little nervous about the regex change (I hate dealing with regexes :)

This issue was originally about other bugs as well, but I'm changing the title to reflect just this fix.  If there are still other remaining bugs, please open a new issues for them.

Thanks for the patch, Julien.  Although I didn't use your code, it did inform my work.

----------
stage: needs patch -> patch review
title: multiple problems with Cookie.py -> Cookie.py does not parse httponly or secure cookie flags
versions: +Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31403/cookie_flags.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16611>
_______________________________________

From report at bugs.python.org  Wed Aug 21 20:11:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Aug 2013 18:11:20 +0000
Subject: [issue16611] Cookie.py does not parse httponly or secure cookie flags
In-Reply-To: <1354654224.49.0.677339520856.issue16611@psf.upfronthosting.co.za>
Message-ID: <1377108680.96.0.0220603667359.issue16611@psf.upfronthosting.co.za>


R. David Murray added the comment:

Woops, corrupted patch, and I see a bug...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16611>
_______________________________________

From report at bugs.python.org  Wed Aug 21 20:11:41 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Aug 2013 18:11:41 +0000
Subject: [issue16611] Cookie.py does not parse httponly or secure cookie flags
In-Reply-To: <1354654224.49.0.677339520856.issue16611@psf.upfronthosting.co.za>
Message-ID: <1377108701.49.0.73596609373.issue16611@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file31403/cookie_flags.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16611>
_______________________________________

From report at bugs.python.org  Wed Aug 21 20:17:34 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Aug 2013 18:17:34 +0000
Subject: [issue18780] SystemError when formatting int subclass
In-Reply-To: <1376921434.69.0.557024484243.issue18780@psf.upfronthosting.co.za>
Message-ID: <1377109054.75.0.751637263171.issue18780@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I'll get my patch separated and over here when I get back home (on a business trip at the moment).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18780>
_______________________________________

From report at bugs.python.org  Wed Aug 21 20:19:34 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 18:19:34 +0000
Subject: [issue18794] select.devpoll objects have no close() method
In-Reply-To: <1377037201.39.0.250253331.issue18794@psf.upfronthosting.co.za>
Message-ID: <1377109174.09.0.666476006797.issue18794@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Updated patch: move tests to the right test files and test that close() can be called more than once.

----------
Added file: http://bugs.python.org/file31404/devpoll_close-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18794>
_______________________________________

From report at bugs.python.org  Wed Aug 21 20:19:48 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Aug 2013 18:19:48 +0000
Subject: [issue16611] Cookie.py does not parse httponly or secure cookie flags
In-Reply-To: <1354654224.49.0.677339520856.issue16611@psf.upfronthosting.co.za>
Message-ID: <1377109188.06.0.891486165727.issue16611@psf.upfronthosting.co.za>


R. David Murray added the comment:

Corrected patch.

----------
Added file: http://bugs.python.org/file31405/cookie_flags.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16611>
_______________________________________

From report at bugs.python.org  Wed Aug 21 20:41:53 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 21 Aug 2013 18:41:53 +0000
Subject: [issue18793] occasional test_multiprocessing_forkserver failure on
 FreeBSD 10.0
In-Reply-To: <1377035945.43.0.272426045772.issue18793@psf.upfronthosting.co.za>
Message-ID: <1377110513.53.0.00689874466142.issue18793@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18793>
_______________________________________

From report at bugs.python.org  Wed Aug 21 20:44:31 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Aug 2013 18:44:31 +0000
Subject: [issue6923] Need pthread_atfork-like functionality in CPython
In-Reply-To: <1253131394.22.0.862355202249.issue6923@psf.upfronthosting.co.za>
Message-ID: <1377110671.66.0.384210054744.issue6923@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> Add an 'atfork' module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6923>
_______________________________________

From report at bugs.python.org  Wed Aug 21 20:47:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Aug 2013 18:47:26 +0000
Subject: [issue18762] error in test_multiprocessing_forkserver
In-Reply-To: <1376684380.66.0.0393627862698.issue18762@psf.upfronthosting.co.za>
Message-ID: <3cKyXs4zBKz7Lk4@mail.python.org>


Roundup Robot added the comment:

New changeset e1fdd79cfb01 by Richard Oudkerk in branch 'default':
Issue #18762: Print debug info on failure to create new forkserver process.
http://hg.python.org/cpython/rev/e1fdd79cfb01

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18762>
_______________________________________

From report at bugs.python.org  Wed Aug 21 20:48:03 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 21 Aug 2013 18:48:03 +0000
Subject: [issue18794] select.devpoll objects have no close() method
In-Reply-To: <1377037201.39.0.250253331.issue18794@psf.upfronthosting.co.za>
Message-ID: <1377110883.19.0.577714155713.issue18794@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18794>
_______________________________________

From report at bugs.python.org  Wed Aug 21 20:56:35 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Aug 2013 18:56:35 +0000
Subject: [issue17119] Integer overflow when passing large string or tuple to
 Tkinter
In-Reply-To: <1359920139.05.0.774798858282.issue17119@psf.upfronthosting.co.za>
Message-ID: <3cKylQ45qHz7Lk8@mail.python.org>


Roundup Robot added the comment:

New changeset 6bc533d06cf1 by Serhiy Storchaka in branch '3.3':
Issue #17119: Fixed integer overflows when processing large strings and tuples
http://hg.python.org/cpython/rev/6bc533d06cf1

New changeset b500daaee7d0 by Serhiy Storchaka in branch 'default':
Issue #17119: Fixed integer overflows when processing large strings and tuples
http://hg.python.org/cpython/rev/b500daaee7d0

New changeset ee0bb673536c by Serhiy Storchaka in branch '2.7':
Issue #17119: Fixed integer overflows when processing large Unicode strings
http://hg.python.org/cpython/rev/ee0bb673536c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17119>
_______________________________________

From report at bugs.python.org  Wed Aug 21 21:08:52 2013
From: report at bugs.python.org (vengefulgash45)
Date: Wed, 21 Aug 2013 19:08:52 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377112132.68.0.305027859423.issue12641@psf.upfronthosting.co.za>


Changes by vengefulgash45 <turkeysam71 at gmail.com>:


Added file: http://bugs.python.org/file31406/test1.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Aug 21 21:18:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Aug 2013 19:18:23 +0000
Subject: [issue15175] pydoc -k zip throws segmentation fault
In-Reply-To: <1340581488.74.0.233169752541.issue15175@psf.upfronthosting.co.za>
Message-ID: <1377112703.41.0.0379664066366.issue15175@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15175>
_______________________________________

From report at bugs.python.org  Wed Aug 21 21:20:03 2013
From: report at bugs.python.org (fancyguidebook6)
Date: Wed, 21 Aug 2013 19:20:03 +0000
Subject: [issue12641] Test
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377112803.37.0.700295570233.issue12641@psf.upfronthosting.co.za>


Changes by fancyguidebook6 <turkeysam71 at gmail.com>:


----------
title: Remove -mno-cygwin from distutils -> Test
Added file: http://bugs.python.org/file31407/test1.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Aug 21 21:22:30 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Aug 2013 19:22:30 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377112950.16.0.275493728812.issue12641@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
title: Test -> Remove -mno-cygwin from distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Aug 21 21:23:53 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 21 Aug 2013 19:23:53 +0000
Subject: [issue16938] pydoc confused by __dir__
In-Reply-To: <1357944129.98.0.501949279766.issue16938@psf.upfronthosting.co.za>
Message-ID: <1377113033.43.0.661516006066.issue16938@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16938>
_______________________________________

From report at bugs.python.org  Wed Aug 21 21:27:06 2013
From: report at bugs.python.org (spiffykismet73)
Date: Wed, 21 Aug 2013 19:27:06 +0000
Subject: [issue12641] Test
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377113226.84.0.484668474192.issue12641@psf.upfronthosting.co.za>


Changes by spiffykismet73 <turkeysam71 at gmail.com>:


----------
title: Remove -mno-cygwin from distutils -> Test
Added file: http://bugs.python.org/file31408/test1.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Aug 21 21:30:44 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 21 Aug 2013 19:30:44 +0000
Subject: [issue17972] inspect module docs omits many functions
In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za>
Message-ID: <1377113444.15.0.037230337702.issue17972@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17972>
_______________________________________

From report at bugs.python.org  Wed Aug 21 21:46:12 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Aug 2013 19:46:12 +0000
Subject: [issue12641] Test
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377114372.26.0.642389879707.issue12641@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file31408/test1.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Aug 21 21:46:18 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Aug 2013 19:46:18 +0000
Subject: [issue12641] Test
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377114378.1.0.0325600106239.issue12641@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file31407/test1.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Aug 21 21:46:19 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Aug 2013 19:46:19 +0000
Subject: [issue12641] Test
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377114379.26.0.643366812053.issue12641@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file31406/test1.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Aug 21 21:51:34 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 21 Aug 2013 19:51:34 +0000
Subject: [issue18801] inspect.classify_class_attrs() misclassifies
 object.__new__()
Message-ID: <1377114694.59.0.675744683781.issue18801@psf.upfronthosting.co.za>


New submission from Eric Snow:

>>> pprint.pprint(inspect.classify_class_attrs(object))
[Attribute(name='__class__', kind='data', defining_class=<class 'object'>, object=<attribute '__class__' of 'object' objects>),
...
 Attribute(name='__init__', kind='method', defining_class=<class 'object'>, object=<slot wrapper '__init__' of 'object' objects>),
...
 Attribute(name='__new__', kind='data', defining_class=<class 'object'>, object=<built-in method __new__ of type object at 0x8aee20>),
...
]

I haven't had a chance to look into why __new__() falls through the cracks but expect it's due to how __new__() is treated like a staticmethod without being one.  I suppose there could be other similar cases, but __new__() is probably the only oddball here.

An extra test using isbuiltin() fixes this.

         else:
             obj_via_getattr = getattr(cls, name)
             if (ismethod(obj_via_getattr) or
-                ismethoddescriptor(obj_via_getattr)):
+                ismethoddescriptor(obj_via_getattr) or
+                isbuiltin(obj_via_getattr)):
                 kind = "method"
             else:
                 kind = "data"

----------
components: Library (Lib)
messages: 195818
nosy: eric.snow
priority: normal
severity: normal
stage: test needed
status: open
title: inspect.classify_class_attrs() misclassifies object.__new__()
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18801>
_______________________________________

From report at bugs.python.org  Wed Aug 21 22:12:19 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 21 Aug 2013 20:12:19 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377115939.97.0.741680325721.issue12641@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
title: Test -> Remove -mno-cygwin from distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Aug 21 22:22:43 2013
From: report at bugs.python.org (Alexandre Dias)
Date: Wed, 21 Aug 2013 20:22:43 +0000
Subject: [issue18795] pstats - allow stats sorting by cumulative time per call
 and total time per call
In-Reply-To: <1377042491.98.0.765142916486.issue18795@psf.upfronthosting.co.za>
Message-ID: <1377116563.92.0.845497147745.issue18795@psf.upfronthosting.co.za>


Alexandre Dias added the comment:

Average time would indeed be a better description. 

As for its usefulness: let's say that for example you would want to find the function in which your code spends the most time on average, in order to later optimise said function. If one of the calls to another function has its execution time spike momentarily, it will be at the top of the total time column on the result. However, that does not necessarily mean that it was the function in which on average the most time was spent on, and thus the one that the optimisation effort should be focused on.
Also, when seeing the profiling results, I would expect to be able to sort by any of the columns shown, and that is currently not possible for the average cumulative and total time per call.

Do you mind clarifying your worries with backwards compatibility? Unless I'm mistaken, "fcn_list "is the only outside effect of the method I'm changing. It is built from the last element of each tuple in stats_list, whose ordering is what I'm proposing to be able to change (thus changing the ordering of the function list, but that is already done by other sort options).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18795>
_______________________________________

From report at bugs.python.org  Wed Aug 21 22:23:52 2013
From: report at bugs.python.org (gaudyallure52)
Date: Wed, 21 Aug 2013 20:23:52 +0000
Subject: [issue12641] Test
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377116632.78.0.257098182679.issue12641@psf.upfronthosting.co.za>


gaudyallure52 added the comment:

Test

----------
nosy: +gaudyallure52
title: Remove -mno-cygwin from distutils -> Test
Added file: http://bugs.python.org/file31409/test1.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Aug 21 22:31:49 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Aug 2013 20:31:49 +0000
Subject: [issue12641] Test
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377117109.97.0.348043338029.issue12641@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg195820

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Aug 21 22:38:49 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 21 Aug 2013 20:38:49 +0000
Subject: [issue12641] Test
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377117529.34.0.738729367131.issue12641@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


Removed file: http://bugs.python.org/file31409/test1.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Aug 21 22:57:41 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Aug 2013 20:57:41 +0000
Subject: [issue18795] pstats - allow stats sorting by cumulative time per call
 and total time per call
In-Reply-To: <1377042491.98.0.765142916486.issue18795@psf.upfronthosting.co.za>
Message-ID: <1377118661.88.0.19658886186.issue18795@psf.upfronthosting.co.za>


R. David Murray added the comment:

There may not be a problem.  I'm not familiar enough with the pstats code to review the patch for real without some study.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18795>
_______________________________________

From report at bugs.python.org  Wed Aug 21 23:00:57 2013
From: report at bugs.python.org (Jon Foster)
Date: Wed, 21 Aug 2013 21:00:57 +0000
Subject: [issue18802] ipaddress documentation errors
Message-ID: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za>


New submission from Jon Foster:

I recently looked at using the ipaddress module in a project, and noticed some discrepencies between the code and the documentation, and some things that weren't documented.  A patch to fix these is attached.

* The IPv4Network.__init__ documentation wrongly claims that "/0.0.0.0"
  would be interpreted as a host mask i.e. "/32".  It's actually
  interpreted as a net mask, i.e. "/0".

* The IPv[46]Network.netmask property is not documented

* The IPv[46]Network.hostmask property is wrongly called "host mask"
  (with a space!) in the docs

* The IPv[46]Network.hostmask property is wrongly documented as a
  string but it's actually an IPv[46]Address

* The IPv6Network.__init__ documentation wrongly claims that a netmask
  can be specified, but this is not supported by the code.  The code
  only supports prefix lengths.

* The documentation should explain how network objects are ordered,
  since it's not obvious.

* The documentation should explain how interface objects are compared,
  both with other interface objects and with address objects, as it's
  not obvious.

* It's probably a good idea to document that you can't always pass a
  IPv4Interface object to a function that expects a IPv4Address.

* It would be nice to mention that address, network and interface objects
  are all hashable.

Kind regards,

Jon

----------
components: Library (Lib)
files: ipaddress_docs_v1.patch
keywords: patch
messages: 195822
nosy: jongfoster
priority: normal
severity: normal
status: open
title: ipaddress documentation errors
versions: Python 3.4
Added file: http://bugs.python.org/file31410/ipaddress_docs_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18802>
_______________________________________

From report at bugs.python.org  Wed Aug 21 23:13:17 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Aug 2013 21:13:17 +0000
Subject: [issue18802] ipaddress documentation errors
In-Reply-To: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za>
Message-ID: <1377119597.05.0.541355186014.issue18802@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +ncoghlan, pmoody

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18802>
_______________________________________

From report at bugs.python.org  Wed Aug 21 23:16:05 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Wed, 21 Aug 2013 21:16:05 +0000
Subject: [issue18803] Fix more typos in .py files
Message-ID: <1377119764.79.0.128935070292.issue18803@psf.upfronthosting.co.za>


New submission from F?vry Thibault:

Just like issue 18741 and 18705.

It also fixes one typo in a C file.

----------
assignee: docs at python
components: Documentation
files: more_typos.diff
keywords: patch
messages: 195823
nosy: docs at python, iwontbecreative
priority: normal
severity: normal
status: open
title: Fix more typos in .py files
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31411/more_typos.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18803>
_______________________________________

From report at bugs.python.org  Wed Aug 21 23:32:15 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Aug 2013 21:32:15 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1377064054.88.0.645596281376.issue17576@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dHVRrLSJT_LRhhksHgG8W9dJbKvRn9BNchzashHnGkMQ@mail.gmail.com>


Nick Coghlan added the comment:

On 21 Aug 2013 15:47, "Mark Dickinson" <report at bugs.python.org> wrote:
>
>
> Mark Dickinson added the comment:
>
> > Shouldn't it be PendingDeprecationWarning?
>
> Hmm.  Possibly.  I'm not sure what the policy is any more regarding
DeprecationWarning versus PendingDeprecationWarning.  Nick?

Not sure if this is written down anywhere, but I use
PendingDeprecationWarning for "definitely still around next release, may
not have a set date for removal" and DeprecationWarning for "may be removed
next release".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Wed Aug 21 23:36:07 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 21 Aug 2013 21:36:07 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a traceback
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1377120967.47.0.413923661129.issue16396@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

We can argue about whether it's a bugfix or not. But I don't see how having this patch in 2.7 helps anyone, since ctypes.wintypes is useless on non-Windows platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Thu Aug 22 00:21:04 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Aug 2013 22:21:04 +0000
Subject: [issue18794] select.devpoll objects have no close() method
In-Reply-To: <1377037201.39.0.250253331.issue18794@psf.upfronthosting.co.za>
Message-ID: <3cL3HN25yXz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset ccbe2132392b by Victor Stinner in branch 'default':
Close #18794: Add a fileno() method and a closed attribute to select.devpoll
http://hg.python.org/cpython/rev/ccbe2132392b

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18794>
_______________________________________

From report at bugs.python.org  Thu Aug 22 00:21:47 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 22:21:47 +0000
Subject: [issue18794] select.devpoll objects have no close() method
In-Reply-To: <1377037201.39.0.250253331.issue18794@psf.upfronthosting.co.za>
Message-ID: <1377123707.6.0.486844869862.issue18794@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Charles-Fran?ois Natali and Guido van Rossum: thanks for your reviews ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18794>
_______________________________________

From report at bugs.python.org  Thu Aug 22 00:22:18 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 22:22:18 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377123738.72.0.794735558306.issue12641@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Test -> Remove -mno-cygwin from distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Thu Aug 22 00:26:12 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 22:26:12 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1376691835.07.0.666456900735.issue18763@psf.upfronthosting.co.za>
Message-ID: <1377123972.12.0.476433854562.issue18763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Your change looks perfectly valid, except this minor nit:

+        self.assertTrue(remaining_fds <= set([0, 1, 2]))

Using self.assertLessEqual() would provide better message on error.

Note: with the PEP 446, you would not have to care of closing file descriptors :-D

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Thu Aug 22 00:26:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 22:26:45 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1376691835.07.0.666456900735.issue18763@psf.upfronthosting.co.za>
Message-ID: <1377124005.74.0.621583632892.issue18763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

You don't want to fix Python 2.7 and 3.3? It is a bug in my opinion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Thu Aug 22 00:36:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 22:36:46 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1377100025.48.0.458791410583.issue18772@psf.upfronthosting.co.za>
Message-ID: <1377124598.2480.0.camel@fsol>


Antoine Pitrou added the comment:

> Antoine, can you please verify the gdb plug-in is working again?

test_gdb works fine here, yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Thu Aug 22 00:39:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Aug 2013 22:39:57 +0000
Subject: [issue18792] test_ftplib timeouts
In-Reply-To: <1377032489.22.0.759563431169.issue18792@psf.upfronthosting.co.za>
Message-ID: <3cL3j866hdz7LkN@mail.python.org>


Roundup Robot added the comment:

New changeset 085ba7d85eb2 by Antoine Pitrou in branch 'default':
Issue #18792: Use "127.0.0.1" or "::1" instead of "localhost" as much as possible, since "localhost" goes through a DNS lookup under recent Windows versions.
http://hg.python.org/cpython/rev/085ba7d85eb2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18792>
_______________________________________

From report at bugs.python.org  Thu Aug 22 00:41:44 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 22:41:44 +0000
Subject: [issue17070] PEP 433: Use the new cloexec to improve security and
 avoid bugs
In-Reply-To: <1359464957.74.0.458887600287.issue17070@psf.upfronthosting.co.za>
Message-ID: <1377124904.49.0.177042109727.issue17070@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Time to close this one, since the PEP has been superseeded by PEP 446?

I prefer to wait until Guido decided for the PEP 446.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17070>
_______________________________________

From report at bugs.python.org  Thu Aug 22 00:49:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Aug 2013 22:49:00 +0000
Subject: [issue18792] test_ftplib timeouts
In-Reply-To: <1377032489.22.0.759563431169.issue18792@psf.upfronthosting.co.za>
Message-ID: <3cL3vb54t8z7Lk1@mail.python.org>


Roundup Robot added the comment:

New changeset 7728b073c77c by Antoine Pitrou in branch '3.3':
Issue #18792: Use "127.0.0.1" or "::1" instead of "localhost" as much as possible, since "localhost" goes through a DNS lookup under recent Windows versions.
http://hg.python.org/cpython/rev/7728b073c77c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18792>
_______________________________________

From report at bugs.python.org  Thu Aug 22 00:58:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Aug 2013 22:58:36 +0000
Subject: [issue18792] test_ftplib timeouts
In-Reply-To: <1377032489.22.0.759563431169.issue18792@psf.upfronthosting.co.za>
Message-ID: <3cL46h2Wrqz7LkS@mail.python.org>


Roundup Robot added the comment:

New changeset 48de8df194d9 by Antoine Pitrou in branch '2.7':
Issue #18792: Use "127.0.0.1" or "::1" instead of "localhost" as much as possible, since "localhost" goes through a DNS lookup under recent Windows versions.
http://hg.python.org/cpython/rev/48de8df194d9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18792>
_______________________________________

From report at bugs.python.org  Thu Aug 22 00:59:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 22:59:07 +0000
Subject: [issue18792] test_ftplib timeouts
In-Reply-To: <1377032489.22.0.759563431169.issue18792@psf.upfronthosting.co.za>
Message-ID: <1377125947.37.0.403546190398.issue18792@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Done, thanks :)

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18792>
_______________________________________

From report at bugs.python.org  Thu Aug 22 01:07:47 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 23:07:47 +0000
Subject: [issue18804] pythorun.c: is_valid_fd() should not duplicate the file
 descriptor
Message-ID: <1377126467.82.0.012503473328.issue18804@psf.upfronthosting.co.za>


New submission from STINNER Victor:

is_valid_fd() of Python/pythorun.c should use fstat() to check if a file descriptor is valid, instead of duplicating it using dup() (and then closing it).

If Windows needs a special check, it would be better to run checks on the handle of the file descriptor.

The function was added by the following changeset:

----------------------------
branch:      3.2
parent:      73773:661fb211f220
user:        Antoine Pitrou <solipsis at pitrou.net>
date:        Mon Nov 28 19:08:36 2011 +0100
files:       Lib/test/test_cmd_line.py Misc/NEWS Python/pythonrun.c
description:
Issue #7111: Python can now be run without a stdin, stdout or stderr stream.

It was already the case with Python 2.  However, the corresponding
sys module entries are now set to None (instead of an unusable file object).
----------------------------


See also issue #17797 "Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program".

----------
messages: 195836
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: pythorun.c: is_valid_fd() should not duplicate the file descriptor
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18804>
_______________________________________

From report at bugs.python.org  Thu Aug 22 01:08:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 23:08:58 +0000
Subject: [issue18804] pythorun.c: is_valid_fd() should not duplicate the file
 descriptor
In-Reply-To: <1377126467.82.0.012503473328.issue18804@psf.upfronthosting.co.za>
Message-ID: <1377126530.2480.1.camel@fsol>


Antoine Pitrou added the comment:

> is_valid_fd() of Python/pythorun.c should use fstat() to check if a
> file descriptor is valid, instead of duplicating it using dup() (and
> then closing it).

Why should it?
fstat() may be expensive, while dup() is cheap.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18804>
_______________________________________

From report at bugs.python.org  Thu Aug 22 01:24:14 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 23:24:14 +0000
Subject: [issue18804] pythorun.c: is_valid_fd() should not duplicate the file
 descriptor
In-Reply-To: <1377126467.82.0.012503473328.issue18804@psf.upfronthosting.co.za>
Message-ID: <1377127454.68.0.0959739237761.issue18804@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Why should it?

fstat() does not need to create a new file descriptor. Creating a new file descriptor can fail (ex: limit of the number of open files).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18804>
_______________________________________

From report at bugs.python.org  Thu Aug 22 01:26:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 23:26:35 +0000
Subject: [issue18804] pythorun.c: is_valid_fd() should not duplicate the file
 descriptor
In-Reply-To: <1377127454.68.0.0959739237761.issue18804@psf.upfronthosting.co.za>
Message-ID: <1377127587.2480.2.camel@fsol>


Antoine Pitrou added the comment:

> > Why should it?
> 
> fstat() does not need to create a new file descriptor. Creating a new
> file descriptor can fail (ex: limit of the number of open files).

Why should I care? fstat() can fail too.
The only important thing is whether dup() returns EBADF or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18804>
_______________________________________

From report at bugs.python.org  Thu Aug 22 01:28:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 23:28:45 +0000
Subject: [issue18804] pythorun.c: is_valid_fd() should not duplicate the file
 descriptor
In-Reply-To: <1377126467.82.0.012503473328.issue18804@psf.upfronthosting.co.za>
Message-ID: <1377127725.51.0.200546677787.issue18804@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

By the way, can you please mention the actual changeset id? (not only the parent)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18804>
_______________________________________

From report at bugs.python.org  Thu Aug 22 01:33:21 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 23:33:21 +0000
Subject: [issue18804] pythorun.c: is_valid_fd() should not duplicate the file
 descriptor
In-Reply-To: <1377126467.82.0.012503473328.issue18804@psf.upfronthosting.co.za>
Message-ID: <1377128001.61.0.0369478901472.issue18804@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> By the way, can you please mention the actual changeset id? (not only the parent)

Oh, I failed to copy/paste the changeset, sorry :-) It is the changeset f15943505db0:

changeset:   73775:f15943505db0
branch:      3.2
parent:      73773:661fb211f220
user:        Antoine Pitrou <solipsis at pitrou.net>
date:        Mon Nov 28 19:08:36 2011 +0100
files:       Lib/test/test_cmd_line.py Misc/NEWS Python/pythonrun.c
description:
Issue #7111: Python can now be run without a stdin, stdout or stderr stream.

It was already the case with Python 2.  However, the corresponding
sys module entries are now set to None (instead of an unusable file object).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18804>
_______________________________________

From report at bugs.python.org  Thu Aug 22 01:34:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Aug 2013 23:34:53 +0000
Subject: [issue18804] pythorun.c: is_valid_fd() should not duplicate the file
 descriptor
In-Reply-To: <1377126467.82.0.012503473328.issue18804@psf.upfronthosting.co.za>
Message-ID: <1377128093.15.0.566815537571.issue18804@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks. I guess is_valid_fd() could be improved to check for EBADF, but other than that I don't see the problem. dup() is better than fstat() which may do some actual I/O.
Did you encounter this in real life?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18804>
_______________________________________

From report at bugs.python.org  Thu Aug 22 01:39:57 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 23:39:57 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1377128397.61.0.244045594197.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file31412/43697011a273.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Thu Aug 22 01:42:40 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 23:42:40 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1377128560.52.0.564573058345.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file31235/e4e6f45668c7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Thu Aug 22 01:42:43 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 23:42:43 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1377128563.73.0.338765950839.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file31378/00df7fc6d2ef.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Thu Aug 22 01:59:04 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Aug 2013 23:59:04 +0000
Subject: [issue18326] Mention 'keyword only' for list.sort, improve  glossary.
In-Reply-To: <1372511136.61.0.278425078947.issue18326@psf.upfronthosting.co.za>
Message-ID: <1377129544.52.0.491454186038.issue18326@psf.upfronthosting.co.za>


R. David Murray added the comment:

In this expository context, I prefer the issue18326.that.diff version, but the index link to the keyword-only_parameter ref should still be added to it (on "only be passed by keyword").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18326>
_______________________________________

From report at bugs.python.org  Thu Aug 22 02:28:59 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 00:28:59 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1377131339.19.0.238069550658.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file31413/775890a666bf.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Thu Aug 22 02:29:44 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 00:29:44 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1377131384.05.0.800168467885.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file31412/43697011a273.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Thu Aug 22 02:36:29 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 00:36:29 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377131789.41.0.386680783224.issue18713@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Attached patch changes the error handle of stdin, stdout and stderr to surrogateescape by default. It can still be changed explicitly using the PYTHONIOENCODING environment variable.

----------
keywords: +patch
Added file: http://bugs.python.org/file31414/surrogateescape.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 02:36:50 2013
From: report at bugs.python.org (Jon Foster)
Date: Thu, 22 Aug 2013 00:36:50 +0000
Subject: [issue18802] ipaddress documentation errors
In-Reply-To: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za>
Message-ID: <1377131810.39.0.460353330961.issue18802@psf.upfronthosting.co.za>


Jon Foster added the comment:

(If this is accepted, please consider it for backport to 3.3 too.  It is just a documentation improvement).

----------
type:  -> enhancement
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18802>
_______________________________________

From report at bugs.python.org  Thu Aug 22 02:38:38 2013
From: report at bugs.python.org (Jon Foster)
Date: Thu, 22 Aug 2013 00:38:38 +0000
Subject: [issue18805] ipaddress netmask/hostmask parsing bugs
Message-ID: <1377131918.88.0.806374780855.issue18805@psf.upfronthosting.co.za>


New submission from Jon Foster:

Short version:
Validation of netmasks and hostmasks in IPv4Network is wrong: it rejects many
valid netmasks, it accepts many invalid netmasks and hostmasks, and it sometimes
throws the wrong exception.  Patch attached.


Long version:


Wrongly rejecting hostmasks
---------------------------

Creating IPv4Network objects using a hostmask only works for 3 of the 31 possible hostmasks.
It works fine for /8, /16, and /24 networks, but anything else fails.  E.g. first let's
calculate the hostmask for a /21 network:

  >>> from ipaddress import IPv4Network
  >>> IPv4Network('0.0.0.0/21').hostmask
  IPv4Address('0.0.7.255')

Then try using it:
  >> IPv4Network('0.0.0.0/0.0.7.255')
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "c:\Python33\lib\ipaddress.py", line 1443, in __init__
      % addr[1])
  ipaddress.NetmaskValueError: '0.0.7.255' is not a valid netmask

The problem is that there is a list of "_valid_mask_octets".  Although the values listed
are correct for netmasks, they are wrong for host masks.  In binary, a netmask has 1s
in the most significant <prefixlen> bits and 0s everywhere else; a hostmask has 0s
in the most significant <prefixlen> bits and 1s everywhere else.  So netmasks have
octet values 0b11111111, 0b11111110, 0b11111100, etc, whereas hostmasks have
octet values 0b11111111, 0b01111111, 0b00111111, etc.


Wrongly accepting hostmasks
---------------------------

Once the individual octets have been validated, the hostmask validation just checks
the first octet is less than the last octet.  This accepts values like "0.255.0.255",
which is not a valid hostmask.  The IPv4Network object then has wierd nonsensical
values.


Wrongly accepting netmasks
---------------------------

Once the individual octets have been validated, the netmask validation just checks
each octet is no greater than the one before.  This accepts values like "254.192.128.0",
which is not a valid netmask.  The IPv4Network object then has wierd nonsensical
values.


Inconsistent parsing
--------------------

The existing validation code includes its own parsing code.  If the netmask/hostmask
passes that vaildation, it then goes into _ip_int_from_string() to be parsed and
used.  _ip_int_from_string() checks things that aren't caught by the validation
code, leading to AddressValueError being thrown when NetmaskValueError was expected:

  >>> IPv4Network('1.2.0.0/0.0.0255.255')
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "c:\Python33\lib\ipaddress.py", line 1440, in __init__
      self._ip_int_from_string(addr[1]) ^ self._ALL_ONES)
    File "c:\Python33\lib\ipaddress.py", line 1055, in _ip_int_from_string
      raise AddressValueError("%s in %r" % (exc, ip_str)) from None
  ipaddress.AddressValueError: At most 3 characters permitted in '0255' in '0.0.0255.255'

The correct fix for this one is obviously to use the same parser in all the places
we parse the netmask/hostmask.


The patch
---------

I'm attaching a patch, with tests, that fixes these issues.  Reusing the existing
_ip_int_from_string() function to parse the netmask/hostmask simplified the
validation code a lot.

My hope is that this patch is suitable for a backport to 3.3, as well as trunk.

----------
components: Library (Lib)
files: ipaddress_masks_v1.patch
keywords: patch
messages: 195846
nosy: jongfoster, ncoghlan, pmoody
priority: normal
severity: normal
status: open
title: ipaddress netmask/hostmask parsing bugs
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31415/ipaddress_masks_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18805>
_______________________________________

From report at bugs.python.org  Thu Aug 22 02:39:53 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Aug 2013 00:39:53 +0000
Subject: [issue18802] ipaddress documentation errors
In-Reply-To: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za>
Message-ID: <1377131993.39.0.865479742809.issue18802@psf.upfronthosting.co.za>


R. David Murray added the comment:

Documentation fixes are always backported.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18802>
_______________________________________

From report at bugs.python.org  Thu Aug 22 03:14:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Aug 2013 01:14:27 +0000
Subject: [issue14360] email.encoders.encode_quopri doesn't work with python 3.2
In-Reply-To: <1332063395.16.0.293436373736.issue14360@psf.upfronthosting.co.za>
Message-ID: <3cL77Q3xcNz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 64e004737837 by R David Murray in branch '3.3':
#18324: set_payload now correctly handles binary input.
http://hg.python.org/cpython/rev/64e004737837

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14360>
_______________________________________

From report at bugs.python.org  Thu Aug 22 03:14:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Aug 2013 01:14:27 +0000
Subject: [issue1717] Get rid of more references to __cmp__
In-Reply-To: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
Message-ID: <3cL77R27ktz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 64e004737837 by R David Murray in branch '3.3':
#18324: set_payload now correctly handles binary input.
http://hg.python.org/cpython/rev/64e004737837

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
_______________________________________

From report at bugs.python.org  Thu Aug 22 03:14:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Aug 2013 01:14:28 +0000
Subject: [issue18324] set_payload does not handle binary payloads correctly
In-Reply-To: <1372446982.29.0.852040030503.issue18324@psf.upfronthosting.co.za>
Message-ID: <3cL77S0G8Xz7Ljh@mail.python.org>


Roundup Robot added the comment:

New changeset 64e004737837 by R David Murray in branch '3.3':
#18324: set_payload now correctly handles binary input.
http://hg.python.org/cpython/rev/64e004737837

New changeset a4afcf93ef7b by R David Murray in branch 'default':
Merge #18324: set_payload now correctly handles binary input.
http://hg.python.org/cpython/rev/a4afcf93ef7b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18324>
_______________________________________

From report at bugs.python.org  Thu Aug 22 03:14:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Aug 2013 01:14:29 +0000
Subject: [issue16564] email.generator.BytesGenerator fails with bytes payload
In-Reply-To: <1354027130.07.0.897738205773.issue16564@psf.upfronthosting.co.za>
Message-ID: <3cL77S5Xz8z7LkS@mail.python.org>


Roundup Robot added the comment:

New changeset 64e004737837 by R David Murray in branch '3.3':
#18324: set_payload now correctly handles binary input.
http://hg.python.org/cpython/rev/64e004737837

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16564>
_______________________________________

From report at bugs.python.org  Thu Aug 22 03:15:28 2013
From: report at bugs.python.org (pmoody)
Date: Thu, 22 Aug 2013 01:15:28 +0000
Subject: [issue17400] ipaddress.is_private needs to take into account of
 rfc6598
In-Reply-To: <1363052217.02.0.113831391012.issue17400@psf.upfronthosting.co.za>
Message-ID: <1377134128.7.0.576309685982.issue17400@psf.upfronthosting.co.za>


pmoody added the comment:

is_private was, as you note, basically shorthand for is_RFC1918 (and is_RFC4193 for v6). It's not a particularly well-named method, but at the time that I wrote it (~5 years ago?), it did what I needed it to do.

I'm not sure what you mean by an 'is_natted()' method; there's nothing in particular preventing someone from natting a globally unique address. is_global() makes some sense to me, and it appears that I most likely have to update is_reserved, but I don't understand is_forwardable().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17400>
_______________________________________

From report at bugs.python.org  Thu Aug 22 03:18:56 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Aug 2013 01:18:56 +0000
Subject: [issue18324] set_payload does not handle binary payloads correctly
In-Reply-To: <1372446982.29.0.852040030503.issue18324@psf.upfronthosting.co.za>
Message-ID: <1377134336.06.0.44966970603.issue18324@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Vajrasky. The v2 patch was almost correct.  What you couldn't know without being as deeply enmeshed in this code as I am is that the test failures from the encoders module were actually invalid.  We'd previously "fixed" them, but the fixes were incorrectly compensating for this bug in set_payload.  Once this bug was fixed, those "fixes" just needed to be backed out, a 'decode=True' added to their get_payload calls, and all the tests pass.

I *think* this is the last inconsistency in the model.  I hope.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18324>
_______________________________________

From report at bugs.python.org  Thu Aug 22 03:23:23 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 22 Aug 2013 01:23:23 +0000
Subject: [issue18805] ipaddress netmask/hostmask parsing bugs
In-Reply-To: <1377131918.88.0.806374780855.issue18805@psf.upfronthosting.co.za>
Message-ID: <1377134603.56.0.92945734984.issue18805@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I haven't had time to review this yet, but at least several of these, if true, are definitely bugs that should be backported. "254.192.128.0" as a netmask? Descending octets as the condition? Yikes.

----------
nosy: +eric.smith
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18805>
_______________________________________

From report at bugs.python.org  Thu Aug 22 04:07:16 2013
From: report at bugs.python.org (Renato Silva)
Date: Thu, 22 Aug 2013 02:07:16 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377137236.76.0.401469354951.issue12641@psf.upfronthosting.co.za>


Changes by Renato Silva <br.renatosilva at gmail.com>:


----------
nosy:  -renatosilva

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Thu Aug 22 04:43:11 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 22 Aug 2013 02:43:11 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1377002608.43.0.244520856137.issue18606@psf.upfronthosting.co.za>
Message-ID: <52157AB8.6000308@pearwood.info>


Steven D'Aprano added the comment:

On 20/08/13 22:43, Mark Dickinson wrote:

> I agree with Oscar about sum for decimal.Decimal.  The *ideal* sum for Decimal instances would return the correctly rounded result (i.e., the exact result, rounded to the current context just once using the current rounding mode).  It seems wrong to give a guarantee of behaviour that's in conflict with this ideal.

Okay, I know when I'm beaten :-)

Documentation will no longer make reference to "honouring the context", as currently stated, and specific example shown will be dropped. Patch to follow. Changing the actual implementation of sum will follow later. If Oscar is willing, I'd like to discuss some of his ideas off-list, but that may take some time.

What else is needed before I can ask for a decision on the PEP?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Thu Aug 22 04:49:48 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 22 Aug 2013 02:49:48 +0000
Subject: [issue18805] ipaddress netmask/hostmask parsing bugs
In-Reply-To: <1377134603.56.0.92945734984.issue18805@psf.upfronthosting.co.za>
Message-ID: <CADiSq7d2HMWKcReX3TMoFUvX0hU1Y=BY0WE_VK+2oqV_m0OChA@mail.gmail.com>


Nick Coghlan added the comment:

Right, I don't see any issues with backporting these fixes. One of the
reasons for the PEP 411 provisional status of the API was to ensure
there were no questions about what should be backported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18805>
_______________________________________

From report at bugs.python.org  Thu Aug 22 06:01:27 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 22 Aug 2013 04:01:27 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1377144087.24.0.806542453766.issue18772@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thank you.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Thu Aug 22 06:46:58 2013
From: report at bugs.python.org (irdb)
Date: Thu, 22 Aug 2013 04:46:58 +0000
Subject: [issue15809] IDLE console uses incorrect encoding.
In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za>
Message-ID: <1377146818.23.0.499490281878.issue15809@psf.upfronthosting.co.za>


irdb added the comment:

I really think this information might help, if not, I promise not to post anything else. :)

This is a sample program I run:

'''
# -*- coding: utf-8 -*-
import sys
import locale

de = sys.getdefaultencoding()
pd = locale.getpreferredencoding()
print de, pd

s1 = '????'
print s1
s2 = u'????'
print s2
'''

I tried to run it before and after applying suggested patches.
Before applying any patch:

'''
Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART ================================
>>> 
ascii cp1256
????????
????
>>> s3 = '????'
>>> s4 = u'????'
>>> s3
'\xd3\xe1\xc7\xe3'
>>> s4
u'\xd3\xe1\xc7\xe3'
>>> print s3
????
>>> print s4
????
>>> s = u'??????? ?????'
Unsupported characters in input
'''

After applying loewis's patch:

'''
Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART ================================
>>> 
ascii cp1256
????????
????
>>> s3 = '????'
>>> s4 = u'????'
>>> s3
'\xd8\xb3\xd9\x84\xd8\xa7\xd9\x85'
>>> s4
u'\u0633\u0644\u0627\u0645'
>>> print s3
????????
>>> print s4
????
>>> s = u'??????? ?????'
>>> print s
??????? ?????
>>> 
'''

After applying serhiy.storchaka's patch:

'''
Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART ================================
>>> 
ascii cp1256
????????
????
>>> s3 = '????'
>>> s4 = u'????'
>>> s3
'\xd3\xe1\xc7\xe3'
>>> s4
u'\u0633\u0644\u0627\u0645'
>>> print s3
????
>>> print s4
????
>>> s = u'??????? ?????'
Unsupported characters in input
'''

My point is that printing s3 and s4 in interactive mode, should produce the same results as printing s1 and s2 from source file. Loewis's patch handled this as I expected. Also this patch solves my problem of not being able to print u'??????? ?????' (that is due to my Windows locale being set to Persian, not Russian.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15809>
_______________________________________

From report at bugs.python.org  Thu Aug 22 07:44:15 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 Aug 2013 05:44:15 +0000
Subject: [issue18806] socketmodule: fix/improve setipaddr() numeric addresses
 handling
Message-ID: <1377150255.36.0.551541174341.issue18806@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Currently, setipaddr() has this code to special-case numeric IPv4 addresses and avoid a name resolution:

"""
    if (sscanf(name, "%d.%d.%d.%d%c", &d1, &d2, &d3, &d4, &ch) == 4 &&
        0 <= d1 && d1 <= 255 && 0 <= d2 && d2 <= 255 &&
        0 <= d3 && d3 <= 255 && 0 <= d4 && d4 <= 255) {
        struct sockaddr_in *sin;
        sin = (struct sockaddr_in *)addr_ret;
        sin->sin_addr.s_addr = htonl(
            ((long) d1 << 24) | ((long) d2 << 16) |
            ((long) d3 << 8) | ((long) d4 << 0));
        sin->sin_family = AF_INET;
#ifdef HAVE_SOCKADDR_SA_LEN
        sin->sin_len = sizeof(*sin);
#endif
        return 4;
    }
"""

- it's sub-optimal to hand-parse an IP address while we have inet_pton() and getaddrinfo()
- it doesn't work for IPv6 addresses
- it's also subject to integer overflow due to the scanf formatter

Wouldn't it be better getaddrinfo() with AI_NUMERICHOST instead?

----------
components: Library (Lib)
messages: 195859
nosy: loewis, neologix
priority: normal
severity: normal
status: open
title: socketmodule: fix/improve setipaddr() numeric addresses handling
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18806>
_______________________________________

From report at bugs.python.org  Thu Aug 22 07:47:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 05:47:47 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377150467.74.0.78539952282.issue18713@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The surrogateescape error handler works only with UTF-8.

As a side effect of this change an input from stdin will be incompatible in general with extensions which implicitly encode a string to bytes with UTF-8 (e.g. tkinter, XML parsers, sqlite3, datetime, locale, curses, etc.)

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 08:08:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 06:08:52 +0000
Subject: [issue15809] IDLE console uses incorrect encoding.
In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za>
Message-ID: <1377151732.5.0.172361307333.issue15809@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Use cp1256 encoding in your source file. It is expected that usually your source files encoding is same as your locale encoding. In such case printing string literals and Unicode string literals produces same result (as they look in the sources).

s1 is '\xd8\xb3\xd9\x84\xd8\xa7\xd9\x85' (u'????'.encode('utf-8')) and when it printed in utf-8 locale it produces "????", but when it printed in cp1256 locale it produces a mojibake.

When you convert your source file to cp1256 and change a header, s1 will be '\xd3\xe1\xc7\xe3' (u'????'.encode('cp1256')) and will produce "????" when printed in your cp1256 locale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15809>
_______________________________________

From report at bugs.python.org  Thu Aug 22 08:27:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 06:27:48 +0000
Subject: [issue16685] Deprecate accepting strings as arguments in audioop
 functions
In-Reply-To: <1355506655.59.0.00344503753899.issue16685@psf.upfronthosting.co.za>
Message-ID: <1377152868.67.0.966722123522.issue16685@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16685>
_______________________________________

From report at bugs.python.org  Thu Aug 22 08:53:28 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 06:53:28 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1377150467.74.0.78539952282.issue18713@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY+YuNiRRJtKAMZnEH1oaUY73E+CGv6RbzngixUPft05g@mail.gmail.com>


STINNER Victor added the comment:

"The surrogateescape error handler works with any codec."

The surrogatepass only works with utf-8 if I remember correctly. The
surrogateescape error handler works with any codec, especially ascii.

"As a side effect of this change an input from stdin will be incompatible
in general with extensions which implicitly encode a string to bytes with
UTF-8 (e.g. tkinter, XML parsers, sqlite3, datetime, locale, curses, etc.)"

Correct, but it's not something new: os.listdir(), sys.argv, os.environ and
other functions using os.fsdecode(). Applications should already have to
support surrogates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 09:08:45 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 22 Aug 2013 07:08:45 +0000
Subject: [issue18799] Resurrect and fix test_404 in Lib/test/test_xmlrpc.py
In-Reply-To: <1377100643.52.0.970396135479.issue18799@psf.upfronthosting.co.za>
Message-ID: <1377155325.68.0.352643573998.issue18799@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Yes, I agree with you, R. David Murray.

But there are some reasons why I try to resurrect this dormant test:

1. This test was disabled on 19 January 2008.
http://hg.python.org/cpython/rev/859bf85a556a

It has been more than 5 years. Many things happened.

2. In the last commit about this test, they used httplib not http library to access the server. If you see this commit:
http://hg.python.org/cpython/rev/5756b295b6fb

, the intuition (at least my intuition) suggests that the similar way can be applied to the dormant test. This commit is in 2012.

3. The http server in the test_xmlrpc.py differs than the http server 5 years ago.

But again, you are maybe right.

So let's hear from the person who disabled this test. Christian Heimes, what do you say about this ticket?

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18799>
_______________________________________

From report at bugs.python.org  Thu Aug 22 09:11:34 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 Aug 2013 07:11:34 +0000
Subject: [issue18806] socketmodule: fix/improve setipaddr() numeric addresses
 handling
In-Reply-To: <1377150255.36.0.551541174341.issue18806@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3hPUp7a5yUC=g-apuPs7gzBOqPz41OU8eB7YK=hNyfKA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Hum...
Apparently, before this bug was fixed, glibc's getaddrinfo() would
retrieve the list of interfaces at every call, even if AI_ADDRCONFIG
was not set:
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fa3fc0fe5f452d0aa7e435d8f32e992958683819

Which can mean a large overhead.
Also, from a quick look at the source, it will also retrieve the list
of interfaces if more than one address matches (e.g. for TCP, UDP, or
if AF_UNSPEC is passed).
So using getaddrinfo() could incur a non-negligible overhead.

So it might be better to just use inet_pton() instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18806>
_______________________________________

From report at bugs.python.org  Thu Aug 22 09:27:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 07:27:08 +0000
Subject: [issue15204] Deprecate the 'U' open mode
In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za>
Message-ID: <1377156428.89.0.995046878618.issue15204@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is an updated patch. I think we can combine 1 and 2 stages (change the documentation and add warnings).

----------
Added file: http://bugs.python.org/file31416/deprecate-U-mode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15204>
_______________________________________

From report at bugs.python.org  Thu Aug 22 09:35:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 07:35:04 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377156904.96.0.238045047021.issue18713@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> "The surrogateescape error handler works with any codec."

Ah, sorry. You are correct.

> Correct, but it's not something new: os.listdir(), sys.argv, os.environ and
other functions using os.fsdecode(). Applications should already have to
support surrogates.

I'm only saying that this will increase a number of cases when an exception will raised in unexpected place.

Perhaps it will be safe left the "strict" default error handler and make the errors attribute of text streams modifiable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 10:20:24 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 08:20:24 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1377156904.96.0.238045047021.issue18713@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYR-y0MCpru991EtndyLQHMwhuS-_vAhkwcj6bukKavaw@mail.gmail.com>


STINNER Victor added the comment:

> I'm only saying that this will increase a number of cases
> when an exception will raised in unexpected place.

The print() instruction is much more common than input(). IMO changing
the error handle should fix more issues than adding regressions.

Python functions decoding OS data from the filesystem encoding with
surrogateescape:

- sys.thread_info.version
- sys.argv
- os.environ, os.getenv()
- os.fsdecode()
- _ssl._SSLSocket.compression
- os.ttyname(), os.ctermid(), os.getcwd(), os.listdir(), os.uname(),
os.getlogin(), os.readlink(), os.confstr(), os.listxattr(), nis.cat()
- grp.getgrpgid(), grp.getgrpnam(), grp.getgrpall()
- spwd.spwd_getspnam(), spwd.spwd_getspall()
- pwd.getpwuid(), pwd.getpwnam(), pwd.getpwall()
- socket.socket.accept(), socket.socket.getsockname(),
socket.socket.getpeername(), socket.socket.recvfrom(),
socket.gethostname(), socket.if_nameindex(), socket.if_indextoname()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 10:37:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 08:37:11 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377160631.39.0.853590295401.issue18713@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Shouldn't be safer use surrogateescape for output and strict for input.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 11:04:10 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 Aug 2013 09:04:10 +0000
Subject: [issue18806] socketmodule: fix/improve setipaddr() numeric addresses
 handling
In-Reply-To: <CAH_1eM3hPUp7a5yUC=g-apuPs7gzBOqPz41OU8eB7YK=hNyfKA@mail.gmail.com>
Message-ID: <CAH_1eM3e9Z+DO7HjQowU1Nvp_Q1mxTiYEtwkev2qTL_TxzRG5g@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> So it might be better to just use inet_pton() instead.

But then it won't set the scope ID if the user doesn't provide it...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18806>
_______________________________________

From report at bugs.python.org  Thu Aug 22 11:08:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 09:08:49 +0000
Subject: [issue16700] Document that bytes OS API can returns unusable results
 on Windows
In-Reply-To: <1355677117.39.0.191453655217.issue16700@psf.upfronthosting.co.za>
Message-ID: <1377162529.15.0.564969085958.issue16700@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16700>
_______________________________________

From report at bugs.python.org  Thu Aug 22 11:12:47 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 09:12:47 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1377160631.39.0.853590295401.issue18713@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYJa2rL3529z+qO7u3W3Z_P8fKky7dUKrXQa=CBRa6h1Q@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> Shouldn't be safer use surrogateescape for output and strict for input.

Nick wrote "Think sysadmins running scripts on Linux, writing to the
console or a pipe."

See my message msg195769: Python3 cannot be simply used as a pipe
because it wants to be kind by decoding binary data to Unicode,
whereas no everybody cares of Unicode :-)

Hum, I realized that the subprocess should also be patched to be
consistent: subprocess already uses surrogateescape for the command
line arguments and environment variables, why not using the same error
handler for stdin, stdout and stderr?

Serhiy Storchaka also noticed (in the review of my patch) than errors
is "strict" when PYTHONIOENCODING=utf-8 is used. We should also use
surrogateescape if only the encoding is changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 11:20:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Aug 2013 09:20:16 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <CAMpsgwYJa2rL3529z+qO7u3W3Z_P8fKky7dUKrXQa=CBRa6h1Q@mail.gmail.com>
Message-ID: <1889745240.4617020.1377163209613.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> See my message msg195769: Python3 cannot be simply used as a pipe
> because it wants to be kind by decoding binary data to Unicode,
> whereas no everybody cares of Unicode :-)

If somebody doesn't care about unicode, they can use sys.stdin.buffer.
Problem solved :-)

Note: enabling surrogateescape on stdin enables precisely the
"exception being raised far from the source of the problem" people
are afraid of.  surrogateescape on stdin allows invalid unicode strings
to slip into your application, only for a later encoding to utf-8
to fail (since lone surrogates are not allowed).  For example if you
are sending that user data over an utf-8 network protocol (perhaps
JSON-encoded or XML-encoded)...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 11:21:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Aug 2013 09:21:46 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <CAMpsgwYJa2rL3529z+qO7u3W3Z_P8fKky7dUKrXQa=CBRa6h1Q@mail.gmail.com>
Message-ID: <461460788.4620661.1377163300378.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Serhiy Storchaka also noticed (in the review of my patch) than errors
> is "strict" when PYTHONIOENCODING=utf-8 is used. We should also use
> surrogateescape if only the encoding is changed.

I don't understand what you say. Could you rephrase?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 11:24:54 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 09:24:54 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <461460788.4620661.1377163300378.JavaMail.root@zimbra10-e2.priv.proxad.net>
Message-ID: <CAMpsgwamQKbFY4o5L2zMHyg886RvVjxSs=ksLx=rFOBypdm-ZA@mail.gmail.com>


STINNER Victor added the comment:

>> Serhiy Storchaka also noticed (in the review of my patch) than errors
>> is "strict" when PYTHONIOENCODING=utf-8 is used. We should also use
>> surrogateescape if only the encoding is changed.
> I don't understand what you say. Could you rephrase?

With my patch, sys.stdin.errors is "surrogateescape" by default, but
it is "strict" when the PYTHONIOENCODING environment variable is set
to "utf-8".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 11:27:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Aug 2013 09:27:00 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377163620.62.0.213472787237.issue18713@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Is it a bug in your patch, or is it deliberate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 11:50:50 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 22 Aug 2013 09:50:50 +0000
Subject: [issue15204] Deprecate the 'U' open mode
In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za>
Message-ID: <1377165050.16.0.979426380806.issue15204@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

http://bugs.python.org/review/15204/diff/9032/Tools/iobench/iobench.py

Line 10 in New:
import io

But io module is never used.

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15204>
_______________________________________

From report at bugs.python.org  Thu Aug 22 12:47:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Aug 2013 10:47:31 +0000
Subject: [issue18762] error in test_multiprocessing_forkserver
In-Reply-To: <1376684380.66.0.0393627862698.issue18762@psf.upfronthosting.co.za>
Message-ID: <3cLMrf2lbcz7Ljp@mail.python.org>


Roundup Robot added the comment:

New changeset a94555d5070f by Richard Oudkerk in branch 'default':
Issue #18762: Fix EBADF error when using forkserver.
http://hg.python.org/cpython/rev/a94555d5070f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18762>
_______________________________________

From report at bugs.python.org  Thu Aug 22 13:24:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Aug 2013 11:24:13 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <3cLNg02dcqz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset 39c9dbed3aa1 by Christian Heimes in branch '3.3':
Issue #18747: Use a parent atfork handler instead of a child atfork handler.
http://hg.python.org/cpython/rev/39c9dbed3aa1

New changeset 25e05147d662 by Christian Heimes in branch 'default':
Issue #18747: Use a parent atfork handler instead of a child atfork handler.
http://hg.python.org/cpython/rev/25e05147d662

New changeset d542f905081a by Christian Heimes in branch '2.7':
Issue #18747: Use a parent atfork handler instead of a child atfork handler.
http://hg.python.org/cpython/rev/d542f905081a

New changeset 6ec43643c54f by Christian Heimes in branch '3.3':
Issue #18747: Update Misc/NEWS to reflect the latest changeset.
http://hg.python.org/cpython/rev/6ec43643c54f

New changeset 956261a143eb by Christian Heimes in branch 'default':
Issue #18747: Update Misc/NEWS to reflect the latest changeset.
http://hg.python.org/cpython/rev/956261a143eb

New changeset 14490ced507e by Christian Heimes in branch '2.7':
Issue #18747: Update Misc/NEWS to reflect the latest changeset.
http://hg.python.org/cpython/rev/14490ced507e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 22 13:50:52 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 11:50:52 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1377163620.62.0.213472787237.issue18713@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYgTb7sMHFEpRRZ3rZU8uJyTDZ0NmfhE4DCNfu_+m3Cgw@mail.gmail.com>


STINNER Victor added the comment:

> Is it a bug in your patch, or is it deliberate?

It was not deliberate, and I think that it would be more consistent to
use the same error handler (surrogateescape) when only the encoding is
changed by the PYTHONIOENCODING environment variable. So
surrogateescape should be used even with PYTHONIOENCODING=utf-8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 13:54:09 2013
From: report at bugs.python.org (Yury V. Zaytsev)
Date: Thu, 22 Aug 2013 11:54:09 +0000
Subject: [issue15806] Add context manager for the "try: ... except: pass"
 pattern
In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za>
Message-ID: <1377172449.35.0.494389782273.issue15806@psf.upfronthosting.co.za>


Yury V. Zaytsev added the comment:

Hi Raymond,

This is a brilliant idea, but before it hits the streets, couldn't you possibly consider extending it with a kwarg to control the depth of the exception stack?

The use case I have for that are snippets like this:

    with ignored(ValueError, TypeError), ignored(ValueError, TypeError), ignored(ValueError, TypeError):
        a()
        b()
        c()

Or else I could write this as

    with ignored(ValueError, TypeError):
        a()

    with ignored(ValueError, TypeError):
        b()

    with ignored(ValueError, TypeError):
        c()

... but either way it looks bad. This looks a bit better to me:

    with ignored(ValueError, TypeError, depth=3):
        a()
        b()
        c()

If you deem this to be unacceptably unpythonic, then please ignore my suggestion.

----------
nosy: +zaytsev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15806>
_______________________________________

From report at bugs.python.org  Thu Aug 22 13:57:50 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Thu, 22 Aug 2013 11:57:50 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <52157AB8.6000308@pearwood.info>
Message-ID: <CAHVvXxTFriBV9ST5WjSq=jLcdW=-uEL_anTBHJQYHSh4NdrxdQ@mail.gmail.com>


Oscar Benjamin added the comment:

On 22 August 2013 03:43, Steven D'Aprano <report at bugs.python.org> wrote:
>
> If Oscar is willing, I'd like to discuss some of his ideas off-list, but that may take some time.

I am willing and it will take time.

I've started reading the paper that Raymond Hettinger references for
the algorithm used in his accurate float sum recipe. I'm not sure why
yet but the algorithm is apparently provably exact only for binary
radix floats so isn't appropriate for decimals. It does seem to give
*very* accurate results for decimals though so I suspect the issue is
just about cases that are on the cusp of the rounding mode. In any
case the paper cites a previous work that gives an algorithm that
apparently works for floating point types with arbitrary radix and
exact rounding; it would be good for that to live somewhere in Python
but I haven't had a chance to look at the paper yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Thu Aug 22 14:33:58 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 22 Aug 2013 12:33:58 +0000
Subject: [issue18762] error in test_multiprocessing_forkserver
In-Reply-To: <1376684380.66.0.0393627862698.issue18762@psf.upfronthosting.co.za>
Message-ID: <1377174838.6.0.0506108978042.issue18762@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

Hopefully this is fixed now.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18762>
_______________________________________

From report at bugs.python.org  Thu Aug 22 14:47:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 12:47:09 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377175629.65.0.731718249091.issue18713@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The surrogateescape error handler is dangerous with utf-16/32. It can produce globally invalid output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 15:03:46 2013
From: report at bugs.python.org (Andrea Corbellini)
Date: Thu, 22 Aug 2013 13:03:46 +0000
Subject: [issue18807] Allow venv to create copies,
 even when symlinks are supported
Message-ID: <1377176626.74.0.056181108419.issue18807@psf.upfronthosting.co.za>


New submission from Andrea Corbellini:

I'd really appreciate if `venv` could create environments without symlinks.

Working on many Python projects, each one with different requirements, I prefer to keep everything I need in a single virtualenv directory, rather than two (one for the virtualenv and one for the built Python).

So I'd like to have a --copies option that lets me force venv not to create symlinks. I can work on a patch if this issue is accepted.

----------
components: Library (Lib)
messages: 195883
nosy: candrea
priority: normal
severity: normal
status: open
title: Allow venv to create copies, even when symlinks are supported
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18807>
_______________________________________

From report at bugs.python.org  Thu Aug 22 15:10:17 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 22 Aug 2013 13:10:17 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1377177017.88.0.460601348715.issue18747@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Some typos on last commit....

"current time (miliseconds or seconds) and an uninitialized arry."

should be

"current time (miliseconds or seconds) and an uninitialized array."


"instead of a child handler because fork() is suppose to be async-signal"

should be

"instead of a child handler because fork() is supposed to be async-signal"


"A pthread_atfork() parent handler is used to seeded the PRNG with pid, time"

should be

"A pthread_atfork() parent handler is used to seed the PRNG with pid, time"

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 22 15:15:47 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 22 Aug 2013 13:15:47 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1377177347.95.0.272621044139.issue18747@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks, that's embarrassing. :( I'm going to install a spell checker ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 22 15:18:23 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 13:18:23 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377177503.29.0.600213251678.issue18713@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The surrogateescape error handler is dangerous with utf-16/32. It can produce globally invalid output.

I don't understand, can you give an example? surrogateescape generate invalid encoded string with any encoding. Example with UTF-8:

>>> b"a\xffb".decode("utf-8", "surrogateescape")
'a\udcffb'

>>> 'a\udcffb'.encode("utf-8", "surrogateescape")
b'a\xffb'

>>> b'a\xffb'.decode("utf-8")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 1: invalid start byte

So str.encode("utf-8", "surrogateescape") produces an invalid UTF-8 sequence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 15:20:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 13:20:20 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1377177347.95.0.272621044139.issue18747@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZZ+MJC+n7fZJKDp_5ZEMzSruODR1s4pntgHRY22Mb4RA@mail.gmail.com>


STINNER Victor added the comment:

PySSL_RAND_atfork_parent() still uses getpid(). This number is not
very random in the *parent* process :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 22 15:27:53 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 Aug 2013 13:27:53 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <CAMpsgwZZ+MJC+n7fZJKDp_5ZEMzSruODR1s4pntgHRY22Mb4RA@mail.gmail.com>
Message-ID: <CAH_1eM1j6bsnMrEnhgYAYxnz_C9a2u5=U7CV+=tUuv2oDhHMUQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> STINNER Victor added the comment:
>
> PySSL_RAND_atfork_parent() still uses getpid(). This number is not
> very random in the *parent* process :-)

:-)

IMO this patch has been rushed in and should be reverted for now.
It's still not async-signal safe, had typos, plus this problem noted by Victor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 22 15:29:10 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 13:29:10 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <CAH_1eM1j6bsnMrEnhgYAYxnz_C9a2u5=U7CV+=tUuv2oDhHMUQ@mail.gmail.com>
Message-ID: <CAMpsgwbW2A5U9rP34hiTHjtWVmmcyaZ+OhA-+v0-iAfgUnC1gQ@mail.gmail.com>


STINNER Victor added the comment:

> IMO this patch has been rushed in and should be reverted for now.

Agreed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 22 15:40:53 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 22 Aug 2013 13:40:53 +0000
Subject: [issue18800] Document Fraction's numerator and denominator properties
In-Reply-To: <1377104746.66.0.571132107535.issue18800@psf.upfronthosting.co.za>
Message-ID: <1377178853.99.0.0496392239975.issue18800@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18800>
_______________________________________

From report at bugs.python.org  Thu Aug 22 15:43:58 2013
From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=)
Date: Thu, 22 Aug 2013 13:43:58 +0000
Subject: [issue18540] imaplib.IMAP4() ends with "Name or service not known" on
 Fedora 18
In-Reply-To: <1374657571.18.0.17831195671.issue18540@psf.upfronthosting.co.za>
Message-ID: <1377179038.92.0.0253580078818.issue18540@psf.upfronthosting.co.za>


Changes by Dani?l van Eeden <launchpad at myname.nl>:


----------
nosy: +dveeden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18540>
_______________________________________

From report at bugs.python.org  Thu Aug 22 15:44:28 2013
From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=)
Date: Thu, 22 Aug 2013 13:44:28 +0000
Subject: [issue11245] Implementation of IMAP IDLE in imaplib?
In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za>
Message-ID: <1377179068.68.0.428826423214.issue11245@psf.upfronthosting.co.za>


Changes by Dani?l van Eeden <launchpad at myname.nl>:


----------
nosy: +dveeden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11245>
_______________________________________

From report at bugs.python.org  Thu Aug 22 15:44:51 2013
From: report at bugs.python.org (Yury V. Zaytsev)
Date: Thu, 22 Aug 2013 13:44:51 +0000
Subject: [issue15806] Add context manager for the "try: ... except: pass"
 pattern
In-Reply-To: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za>
Message-ID: <1377179091.14.0.656117129041.issue15806@psf.upfronthosting.co.za>


Yury V. Zaytsev added the comment:

Actually, please disregard my idea. It's way to dangerous, especially in the case of multiple exceptions to ignore :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15806>
_______________________________________

From report at bugs.python.org  Thu Aug 22 15:56:37 2013
From: report at bugs.python.org (Tamas K)
Date: Thu, 22 Aug 2013 13:56:37 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
Message-ID: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>


New submission from Tamas K:

When a thread is started in CPython, t_bootstrap [Modules/threadmodule.c] creates a PyThreadState object and then calls Thread.__bootstrap_inner [Lib/threading.py] which calls Thread.run, protected with self.__block, a Condition. Thread.join uses the same __block to block until Thread.run finished.

When Thread.run finished, __bootstrap_inner notifies on __block, so join will return. Here lies a race condition, if a thread switch to Thread.join occures before __bootstrap_inner returns to t_bootstrap. Then join will return before the PyThreadState for the thread is destroyed by t_bootstrap.

It is mostly harmless for general use, as __bootstrap_inner eventually gets scheduled again and PyThreadState is taken care of.

However. Py_EndInterpreter [Python/pythonrun.c] can be called when only the main interpreter thread is running. So when we want to call Py_EndInterpreter, we signal every other thread to stop, and join them. And when Thread.join returns, we call Py_EndInterpreter. Py_EndInterpreter checks if there are any other PyThreadStates still around and does a Py_FatalError.

As a workaround, we now do a sleep after join.

----------
components: Interpreter Core, Library (Lib)
messages: 195891
nosy: Tamas.K
priority: normal
severity: normal
status: open
title: Thread.join returns before PyThreadState is destroyed
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Thu Aug 22 15:57:56 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 22 Aug 2013 13:57:56 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <CAMpsgwZZ+MJC+n7fZJKDp_5ZEMzSruODR1s4pntgHRY22Mb4RA@mail.gmail.com>
Message-ID: <521618E2.1080309@cheimes.de>


Christian Heimes added the comment:

Am 22.08.2013 15:20, schrieb STINNER Victor:
> 
> STINNER Victor added the comment:
> 
> PySSL_RAND_atfork_parent() still uses getpid(). This number is not
> very random in the *parent* process :-)

That's fine and doesn't diminish the properties of the PRNG. In fact the
patch could use a hard coded value to perturb the PRNG. It's only
important to modify the PRNG state of the *parent* process so that
recycled PIDs of *child* processes don't lead to repeated pseudo-random
values.

PID, time and stack are just hard-to-guess properties of the process.
That's all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 22 16:04:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 14:04:14 +0000
Subject: [issue18800] Document Fraction's numerator and denominator properties
In-Reply-To: <1377104746.66.0.571132107535.issue18800@psf.upfronthosting.co.za>
Message-ID: <1377180254.37.0.737339992681.issue18800@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +easy
nosy: +mark.dickinson, rhettinger
stage:  -> needs patch
versions: +Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18800>
_______________________________________

From report at bugs.python.org  Thu Aug 22 16:05:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 14:05:12 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377180312.31.0.207792744419.issue18808@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +pitrou
stage:  -> test needed
versions: +Python 3.4 -Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Thu Aug 22 16:08:30 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 22 Aug 2013 14:08:30 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1377180510.02.0.0779825382797.issue18747@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Yet another good blog post about the issue:

OpenSSL PRNG Is Not (Really) Fork-safe
http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 22 16:16:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 14:16:13 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377180973.52.0.75482631978.issue18713@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

>>> ('\udcff' + 'qwerty').encode('utf-16le', 'surrogateescape')
b'\xff\xdcq\x00w\x00e\x00r\x00t\x00y\x00'
>>> ('\udcff' + 'qwerty').encode('utf-16le', 'surrogateescape').decode('utf-16le', 'surrogateescape')
'\udcff\udcdcqwerty'
>>> ('\udcff' + 'qwerty').encode('utf-16le', 'surrogateescape').decode('utf-16le', 'surrogateescape').encode('utf-16le', 'surrogateescape')
b'\xff\xdc\xdc\xdcq\x00w\x00e\x00r\x00t\x00y\x00'
>>> ('\udcff' + 'qwerty').encode('utf-16le', 'surrogateescape').decode('utf-16le', 'surrogateescape').encode('utf-16le', 'surrogateescape').decode('utf-16le', 'surrogateescape')
'\udcff\udcdc\udcdc\udcdcqwerty'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 16:16:32 2013
From: report at bugs.python.org (Tamas K)
Date: Thu, 22 Aug 2013 14:16:32 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377180992.53.0.71679955014.issue18808@psf.upfronthosting.co.za>


Tamas K added the comment:

The bug was found in 2.6.5, but after a quick eyeballing, current HEAD has the same problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Thu Aug 22 16:26:35 2013
From: report at bugs.python.org (Travis)
Date: Thu, 22 Aug 2013 14:26:35 +0000
Subject: [issue12641] Interface
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377181594.99.0.753989280552.issue12641@psf.upfronthosting.co.za>


Travis added the comment:

Interface

----------
nosy: +honorableinvasi
title: Remove -mno-cygwin from distutils -> Interface
Added file: http://bugs.python.org/file31417/test2.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Thu Aug 22 16:42:05 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 22 Aug 2013 14:42:05 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377182525.34.0.504141141625.issue18713@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Note that the specific case I'm really interested is printing on systems that are properly configured to use UTF-8, but are getting bad metadata from an OS API. I'm OK with the idea of *only* changing it for UTF-8 rather than for arbitrary encodings, as well as restricting it to sys.stdout when the codec used matches the default filesystem encoding.

To double check the current behaviour, I created a directory to tinker with this. Filenames were created with the following:

>>> open("??????".encode("utf-8"), "w")
>>> open("basic_ascii".encode("utf-8"), "w")
>>> b"\xd0\xd1\xd2\xd3".decode("latin-1")
'????'
>>> open(b"\xd0\xd1\xd2\xd3", "w")

That last generates an invalid UTF-8 filename. "ls" actually degrades less gracefully than I thought, and just prints question marks for the bad file:

$ ls -l
total 0
-rw-rw-r--. 1 ncoghlan ncoghlan 0 Aug 23 00:04 ????
-rw-rw-r--. 1 ncoghlan ncoghlan 0 Aug 23 00:01 basic_ascii
-rw-rw-r--. 1 ncoghlan ncoghlan 0 Aug 23 00:01 ??????

Python 2 & 3 both work OK if you just print the directory listing directly, since repr() happily displays the surrogate escaped string:

$ python -c "import os; print(os.listdir('.'))"
['basic_ascii', '\xd0\xd1\xd2\xd3', '\xe2\x84\x99\xc6\xb4\xe2\x98\x82\xe2\x84\x8c\xc3\xb8\xe1\xbc\xa4']
$ python3 -c "import os; print(os.listdir('.'))"
['basic_ascii', '\udcd0\udcd1\udcd2\udcd3', '??????']

Where it falls down is when you try to print the strings directly in Python 3:

$ python3 -c "import os; [print(fname) for fname in os.listdir('.')]"
basic_ascii
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<string>", line 1, in <listcomp>
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcd0' in position 0: surrogates not allowed

While setting the IO encoding produces behaviour closer to that of the native tools:
$ PYTHONIOENCODING=utf-8:surrogateescape python3 -c "import os; [print(fname) for fname in os.listdir('.')]"
basic_ascii
????
??????

On the other hand, setting PYTHONIOENCODING as shown provides an environmental workaround, and http://bugs.python.org/issue15216 will provide an improved programmatic workaround (which tools like http://code.google.com/p/pyp/ could use to configure surrogateescape by default).

So perhaps pursuing #15216 further would be a better approach than selectively changing the default behaviour? And better documentation for ways to handle the surrogate escape error when it arises?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 16:42:33 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 22 Aug 2013 14:42:33 +0000
Subject: [issue18809] Expose mtime check in importlib.machinery.FileFinder
Message-ID: <1377182553.5.0.719157877901.issue18809@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If you have enough control over your environment you really don't need to waste a stat call checking if the directory has been modified. That makes the idea of having the check of whether the directory has changed be exposed publicly a useful idea (code: http://hg.python.org/cpython/file/caf72b44240b/Lib/importlib/_bootstrap.py#l1387).

Maybe a check_mtime(old_mtime) where we guarantee that old_mtime is negative if this is the first check? That way the _path_mtime stays private but the check itself is exposed for people to do things like
``return 0`` so that the cache is built once on first use of find_loader() but otherwise never re-calculated.

----------
components: Library (Lib)
messages: 195898
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Expose mtime check in importlib.machinery.FileFinder
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18809>
_______________________________________

From report at bugs.python.org  Thu Aug 22 16:42:47 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 22 Aug 2013 14:42:47 +0000
Subject: [issue18809] Expose mtime check in importlib.machinery.FileFinder
In-Reply-To: <1377182553.5.0.719157877901.issue18809@psf.upfronthosting.co.za>
Message-ID: <1377182567.11.0.896575379083.issue18809@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
stage:  -> test needed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18809>
_______________________________________

From report at bugs.python.org  Thu Aug 22 16:45:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Aug 2013 14:45:47 +0000
Subject: [issue16809] Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works)
In-Reply-To: <1356763107.47.0.647000150457.issue16809@psf.upfronthosting.co.za>
Message-ID: <3cLT7Y3sR0z7Ljp@mail.python.org>


Roundup Robot added the comment:

New changeset 6b841e1ee3b8 by Serhiy Storchaka in branch '3.3':
Issue #16809: Tkinter's splitlist() and split() methods now accept Tcl_Obj
http://hg.python.org/cpython/rev/6b841e1ee3b8

New changeset 85285e6e28f4 by Serhiy Storchaka in branch 'default':
Issue #16809: Tkinter's splitlist() and split() methods now accept Tcl_Obj
http://hg.python.org/cpython/rev/85285e6e28f4

New changeset 2d96764a66fa by Serhiy Storchaka in branch '2.7':
Issue #16809: Tkinter's splitlist() and split() methods now accept Tcl_Obj
http://hg.python.org/cpython/rev/2d96764a66fa

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16809>
_______________________________________

From report at bugs.python.org  Thu Aug 22 16:49:46 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 22 Aug 2013 14:49:46 +0000
Subject: [issue18810] Stop doing stat calls in importlib.machinery.FileFinder
 to see if something is a file or folder
Message-ID: <1377182986.55.0.892405433608.issue18810@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If the check was done based on simply the format what was being searched for (e.g. just assume it's a file if "module.py" exists in the directory) then a couple of stat calls per search could be saved.

If that is deemed to dangerous due to backwards-compatibility, at least extract an API so people can skip the stat calls if they know they are not going to do something as silly as have something named module.py that is not a file.

----------
components: Library (Lib)
messages: 195900
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Stop doing stat calls in importlib.machinery.FileFinder to see if something is a file or folder
type: performance
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18810>
_______________________________________

From report at bugs.python.org  Thu Aug 22 16:56:01 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Aug 2013 14:56:01 +0000
Subject: [issue16809] Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works)
In-Reply-To: <1356763107.47.0.647000150457.issue16809@psf.upfronthosting.co.za>
Message-ID: <3cLTMP0H5Nz7Ljk@mail.python.org>


Roundup Robot added the comment:

New changeset 516b0cd87a90 by Serhiy Storchaka in branch '3.3':
Issue #16809: Fixed some tkinter incompabilities with Tcl/Tk 8.6.
http://hg.python.org/cpython/rev/516b0cd87a90

New changeset 5b5ef012cd4e by Serhiy Storchaka in branch 'default':
Issue #16809: Fixed some tkinter incompabilities with Tcl/Tk 8.6.
http://hg.python.org/cpython/rev/5b5ef012cd4e

New changeset 06244031b608 by Serhiy Storchaka in branch '2.7':
Issue #16809: Fixed some tkinter incompabilities with Tcl/Tk 8.6.
http://hg.python.org/cpython/rev/06244031b608

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16809>
_______________________________________

From report at bugs.python.org  Thu Aug 22 17:03:07 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 22 Aug 2013 15:03:07 +0000
Subject: [issue12641] Interface
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377183787.77.0.680517301365.issue12641@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file31417/test2.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Thu Aug 22 17:03:24 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 22 Aug 2013 15:03:24 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377183804.98.0.86964239109.issue12641@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: Interface -> Remove -mno-cygwin from distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Thu Aug 22 17:05:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 15:05:30 +0000
Subject: [issue16809] Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works)
In-Reply-To: <1356763107.47.0.647000150457.issue16809@psf.upfronthosting.co.za>
Message-ID: <1377183930.04.0.956691067238.issue16809@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you alejandro. Fixed.

I'm afraid this is not all problems with 8.6 and so left this issue open.

----------
priority: high -> critical
stage: needs patch -> commit review
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16809>
_______________________________________

From report at bugs.python.org  Thu Aug 22 17:13:19 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 22 Aug 2013 15:13:19 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377184399.0.0.381864861346.issue12641@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg195896

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Thu Aug 22 17:20:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Aug 2013 15:20:15 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <CAH_1eM1j6bsnMrEnhgYAYxnz_C9a2u5=U7CV+=tUuv2oDhHMUQ@mail.gmail.com>
Message-ID: <1346371474.5422328.1377184808830.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> IMO this patch has been rushed in and should be reverted for now.
> It's still not async-signal safe, had typos, plus this problem noted
> by Victor.

That's not really a problem. You merely have to *perturb* the random
state in the parent, so that the next child gets a different initial
state. As pointed out in a mailing-list message, mixing in a constant
could be enough to perturb the state.

As for not being async-signal safe, it's only in the double fork()
case, which is much less of an issue IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 22 17:20:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Aug 2013 15:20:43 +0000
Subject: [issue18797] Don't needlessly change refcounts of dummy objects for
 sets
In-Reply-To: <1377071745.56.0.580609331428.issue18797@psf.upfronthosting.co.za>
Message-ID: <3cLTvt4WTyz7Ljp@mail.python.org>


Roundup Robot added the comment:

New changeset ac6dab1819c4 by Raymond Hettinger in branch 'default':
Issue 18797:  Remove unneeded refcount adjustments for dummy objects.
http://hg.python.org/cpython/rev/ac6dab1819c4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18797>
_______________________________________

From report at bugs.python.org  Thu Aug 22 17:21:27 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 Aug 2013 15:21:27 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <521618E2.1080309@cheimes.de>
Message-ID: <CAH_1eM3GPaxEBTUygAm+qZYWoROduQbJNBWfEwzuOXZGNEPxsg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

>> PySSL_RAND_atfork_parent() still uses getpid(). This number is not
>> very random in the *parent* process :-)
>
> That's fine and doesn't diminish the properties of the PRNG. In fact the
> patch could use a hard coded value to perturb the PRNG. It's only
> important to modify the PRNG state of the *parent* process so that
> recycled PIDs of *child* processes don't lead to repeated pseudo-random
> values.

Yeah, it doesn't weaken the PRNG, but since we're using current time
and stack content to reseed it, using the parent PID which doesn't
change doesn't bring much (since we chose to add entropy and not just
a constant, which would be sufficient as you noted).

Anyway, for those interested, here's a reproducer.

----------
Added file: http://bugs.python.org/file31418/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________
-------------- next part --------------
import os
import ssl
import time


def get_random():
    return ssl.RAND_bytes(10)

get_random()

refpid = os.fork()
if refpid == 0:
    # first child
    print("PID: %d, random: %s" % (os.getpid(), get_random()))
    os._exit(0)
else:
    os.waitpid(refpid, 0)

while True:
    pid = os.fork()
    if pid == refpid:
        os.waitpid(pid, 0)
        break
    elif pid == 0:
        if os.getpid() == refpid:
            print("PID: %d, random: %s" % (os.getpid(), get_random()))
        os._exit(0)

From report at bugs.python.org  Thu Aug 22 17:30:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Aug 2013 15:30:22 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377185422.9.0.740708583608.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I *think* we could remove that limitation in Py_EndInterpreter(). After all, Py_Finalize() is able to join() non-daemon threads, so there's no reason for Py_EndInterpreter() to allow it too. We must keep the fatal error for daemon threads, though.

As for ensuring the thread state is destroyed before Thread.join() returns, I don't know how to do it: the thread state isn't a PyObject, we can't access it from Python code.

----------
nosy: +grahamd, ncoghlan
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Thu Aug 22 17:34:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 15:34:25 +0000
Subject: [issue17803] Calling Tkinter.Tk() with a baseName keyword argument
 throws UnboundLocalError
In-Reply-To: <1366459067.56.0.563805479218.issue17803@psf.upfronthosting.co.za>
Message-ID: <1377185665.95.0.42486083662.issue17803@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed in changesets fa82071bb7e1 and 0f17aed78168.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> Security bug in tkinter allows for untrusted, arbitrary code execution.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17803>
_______________________________________

From report at bugs.python.org  Thu Aug 22 17:40:38 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Aug 2013 15:40:38 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377186038.8.0.16299145899.issue18713@psf.upfronthosting.co.za>


R. David Murray added the comment:

If you pipe the ls (eg: ls >temp) the bytes are preserved.  Since setting the escape handler via PYTHONIOENCODING sets it for both stdin in and stdout, it sounds like that solves the sysadmin use case.  The sysadmin can just put that environment variable setting in their default profile, and python will once again work like the other unix shell tools.  (I double checked, and this does indeed work...doing the equivalent of ls >temp via python preserves the bytes with that PYTHONIOENCODING setting.  I don't quite understand, however, why I get the ? chars if I don't redirect the output.). 

I'd be inclined to consider the above as reason enough to close this issue.  As usual with Python, explicit is better than implicit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Thu Aug 22 17:50:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Aug 2013 15:50:43 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377186643.24.0.379718698941.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(Actually, it would almost be possible to combine weakrefs and thread locals to ensure that join() only returns when the thread state is cleared. However, the thread state is cleared before it is untied from the interpreter, and there would still be a small window for a race condition if some destructor called by clearing the thread state released the GIL.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Thu Aug 22 17:52:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Aug 2013 15:52:16 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377186736.39.0.00420893166574.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(Of course, the latter problem can be solved by having a dedicated sentinel in the thread state that gets DECREF'efed only *after* the thread state is removed from the interpreter...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Thu Aug 22 18:01:38 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 22 Aug 2013 16:01:38 +0000
Subject: [issue18797] Don't needlessly change refcounts of dummy objects for
 sets
In-Reply-To: <1377071745.56.0.580609331428.issue18797@psf.upfronthosting.co.za>
Message-ID: <1377187298.86.0.150470143722.issue18797@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18797>
_______________________________________

From report at bugs.python.org  Thu Aug 22 18:05:05 2013
From: report at bugs.python.org (Tamas K)
Date: Thu, 22 Aug 2013 16:05:05 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377187505.04.0.286801733972.issue18808@psf.upfronthosting.co.za>


Tamas K added the comment:

Removing the last thread check sounds good, what we actually need is a Py_EndInterpreter that does not casually abort() on us, we don't really care about PyThreadStates that much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Thu Aug 22 18:15:59 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 16:15:59 +0000
Subject: [issue17119] Integer overflow when passing large string or tuple to
 Tkinter
In-Reply-To: <1359920139.05.0.774798858282.issue17119@psf.upfronthosting.co.za>
Message-ID: <1377188159.28.0.433415642151.issue17119@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17119>
_______________________________________

From report at bugs.python.org  Thu Aug 22 19:04:00 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 Aug 2013 17:04:00 +0000
Subject: [issue18811] add ssl-based generator to random module
Message-ID: <1377191040.61.0.301981053683.issue18811@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Now that the ssl module exposes RAND_bytes() (issue #12049), it might be interesting to implement a SSLRandom generator to the random module, to have a cryptographically strong generator without the os.urandom() overhead.

Thoughts?

----------
messages: 195912
nosy: christian.heimes, haypo, neologix, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: add ssl-based generator to random module
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18811>
_______________________________________

From report at bugs.python.org  Thu Aug 22 19:45:24 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 22 Aug 2013 17:45:24 +0000
Subject: [issue18811] add ssl-based generator to random module
In-Reply-To: <1377191040.61.0.301981053683.issue18811@psf.upfronthosting.co.za>
Message-ID: <1377193524.1.0.750459467534.issue18811@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I'm -1

It doesn't look like OpenSSL's PRNG is much faster than /dev/urandom if Python keeps a persistent fd:

$ python3.3 prng.py 
loops: 1000000
bytes: 16
/dev/urandom (fd)        1.2181
os.urandom()             3.2892
RAND_pseudo_bytes        1.2924
RAND_bytes               1.2945

Some crypto experts also say that the PRNG of a stock OpenSSL build is sub par. The algorithm is neither standardized by NIST nor carefully developed by a cryptographer. FIPS builds of OpenSSL have a better PRNG.

----------
versions: +Python 3.4
Added file: http://bugs.python.org/file31419/prng.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18811>
_______________________________________

From report at bugs.python.org  Thu Aug 22 20:47:26 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 Aug 2013 18:47:26 +0000
Subject: [issue18811] add ssl-based generator to random module
In-Reply-To: <1377193524.1.0.750459467534.issue18811@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1LG8EMf6qGNR++QeuOydYXF7Ph2tUwWc6rRTAcrJYMcw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> It doesn't look like OpenSSL's PRNG is much faster than /dev/urandom if
> Python keeps a persistent fd:
>
> $ python3.3 prng.py
> loops: 1000000
> bytes: 16
> /dev/urandom (fd)        1.2181
> os.urandom()             3.2892
> RAND_pseudo_bytes        1.2924
> RAND_bytes               1.2945

Except that your benchmark uses 4096-bytes buffering for /dev/urandom
with a persistent FD, which is not the case with the implementation
proposed in #issue18756. Without buffering (i.e. one read() syscall
per invokation), the numbers change:

$ ./python  ~/prng.py
loops: 100000
bytes: 16
/dev/urandom (fd)        1.37106
os.urandom()             1.4446
RAND_pseudo_bytes        0.83635
RAND_bytes               0.75604

Also, you use CLOCK_PROCESS_CPUTIME_ID which only accounts for CPU
time, not wall-clock time, but it doesn't change much.

> Some crypto experts also say that the PRNG of a stock OpenSSL build is sub
> par. The algorithm is neither standardized by NIST nor carefully developed
> by a cryptographer. FIPS builds of OpenSSL have a better PRNG.

That's an implementation detail, it could very well improve.

But I don't have a strong feeling, so if that's not deemed useful, I
won't take it personally :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18811>
_______________________________________

From report at bugs.python.org  Thu Aug 22 21:00:11 2013
From: report at bugs.python.org (Rob Bairos)
Date: Thu, 22 Aug 2013 19:00:11 +0000
Subject: [issue18812] PyImport_Import redundant calls to find module
Message-ID: <1377198011.48.0.462132559828.issue18812@psf.upfronthosting.co.za>


New submission from Rob Bairos:

Why does PyImport_Import (import.c) call __import__ then immediately discard the result, and then look for the module again in the module dictionary?  

It will return the same value in both cases no?

Ive included the relevant portion of the code below.
Its breaking an embedded application we've built where a hierarchy of modules are maintained outside the sys.modules dictionary.


 /* Call the __import__ function with the proper argument list
    Always use absolute import here.
    Calling for side-effect of import. */
 r = PyObject_CallFunction(import, "OOOOi", module_name, globals,
                           globals, silly_list, 0, NULL);
 if (r == NULL)
     goto err;

//-------------------------- WHY IS THIS SECTION NEEDED? --------
 Py_DECREF(r);
 modules = PyImport_GetModuleDict();
 r = PyDict_GetItem(modules, module_name);
 if (r != NULL)
//---------------------------------------------------------------
     Py_INCREF(r);

----------
components: Interpreter Core
messages: 195915
nosy: Rob.Bairos
priority: normal
severity: normal
status: open
title: PyImport_Import redundant calls to find module
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18812>
_______________________________________

From report at bugs.python.org  Thu Aug 22 21:09:21 2013
From: report at bugs.python.org (Rob Bairos)
Date: Thu, 22 Aug 2013 19:09:21 +0000
Subject: [issue18812] PyImport_Import redundant calls to find module
In-Reply-To: <1377198011.48.0.462132559828.issue18812@psf.upfronthosting.co.za>
Message-ID: <1377198561.31.0.220760993801.issue18812@psf.upfronthosting.co.za>


Changes by Rob Bairos <rbairos at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18812>
_______________________________________

From report at bugs.python.org  Thu Aug 22 21:27:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 19:27:10 +0000
Subject: [issue16840] Tkinter doesn't support large integers
In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za>
Message-ID: <1377199630.7.0.471526511608.issue16840@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Patch updated.

----------
Added file: http://bugs.python.org/file31420/tkinter_bignum_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16840>
_______________________________________

From report at bugs.python.org  Thu Aug 22 22:38:28 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 22 Aug 2013 20:38:28 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1377085745.39.0.491921665481.issue18747@psf.upfronthosting.co.za>
Message-ID: <20130822163824.1f1dce55@anarchist>


Barry A. Warsaw added the comment:

On Aug 21, 2013, at 11:49 AM, Christian Heimes wrote:

>I have taken care of Antoine's and Victor's reviews. The fix has landed in
>Python 2.7, 3.3 and 3.4. What about 2.6, 3.1 and 3.2? After all it's a
>security fix (although I don't consider its severity as high).

I'd like to get this into 2.6.  I'll apply the patch after I fix my
environment so it can actually build 2.6 with ssl enabled.  I'll follow up
here with status.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Thu Aug 22 22:52:52 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 22 Aug 2013 20:52:52 +0000
Subject: [issue18813] Speed up slice object processing
Message-ID: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The get/set/delitem slicing protocol has replaced the old Py2.x get/set/delslice protocol in Py3.x. This change introduces a substantial overhead due to processing indices as Python objects rather than plain Py_ssize_t values. This overhead should be reduced as much as possible.

This ticket can be seen as a more general follow-up to issue10227.

----------
components: Interpreter Core
messages: 195918
nosy: pitrou, scoder
priority: normal
severity: normal
status: open
title: Speed up slice object processing
type: performance
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Thu Aug 22 22:55:14 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 22 Aug 2013 20:55:14 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>
Message-ID: <1377204914.2.0.444415177979.issue18813@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

This tiny patch adds a fast-path to _PyEval_SliceIndex() that speeds up the slicing-heavy "fannkuch" benchmark by 8% for me.

----------
keywords: +patch
Added file: http://bugs.python.org/file31421/faster_PyEval_SliceIndex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Thu Aug 22 23:15:56 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 22 Aug 2013 21:15:56 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>
Message-ID: <1377206156.21.0.567875133009.issue18813@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Sorry, broken patch. Here's a new one (same results).

----------
Added file: http://bugs.python.org/file31422/faster_PyEval_SliceIndex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Thu Aug 22 23:18:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 21:18:20 +0000
Subject: [issue18811] add ssl-based generator to random module
In-Reply-To: <CAH_1eM1LG8EMf6qGNR++QeuOydYXF7Ph2tUwWc6rRTAcrJYMcw@mail.gmail.com>
Message-ID: <CAMpsgwZcDewxb5bAPg7WC_eOK=8wmBqt11UTMKaHbN3hZcKnNA@mail.gmail.com>


STINNER Victor added the comment:

Use time.perf_counter() for benchmarkks!!!

It would be interesting to compare performances on other platforms:
Windows, Solaris, Mac OS X, ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18811>
_______________________________________

From report at bugs.python.org  Thu Aug 22 23:22:44 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 22 Aug 2013 21:22:44 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>
Message-ID: <1377206564.37.0.414392412615.issue18813@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Another patch, originally proposed in issue10227 by Kristj?n Valur J?nsson. It uses local variables instead of pointers in PySlice_GetIndicesEx(). I see no performance difference whatsoever (Linux/gcc 4.7), but also I can't see a reason not to do this. I think it cleans up the code a bit.

----------
Added file: http://bugs.python.org/file31423/use_locals_in_PySlice_GetIndicesEx.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Thu Aug 22 23:23:53 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 Aug 2013 21:23:53 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1377123972.12.0.476433854562.issue18763@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2pPCz-NDgL3qKuua8HBmG0BdGNpFSMoyhQ2oVW8bb6Wg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Using self.assertLessEqual() would provide better message on error.

Done.

> You don't want to fix Python 2.7 and 3.3? It is a bug in my opinion.

Patch for 2.7 attached (without test though, because 2.7 lacks a
fd_status.py helper, which would make this quite complicated).

----------
Added file: http://bugs.python.org/file31424/subprocess_close-default.diff
Added file: http://bugs.python.org/file31425/subprocess_close-27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________
-------------- next part --------------
diff -r 49e23a3adf26 Lib/test/test_subprocess.py
--- a/Lib/test/test_subprocess.py	Wed Aug 21 13:26:34 2013 +0200
+++ b/Lib/test/test_subprocess.py	Thu Aug 22 21:19:52 2013 +0200
@@ -1972,6 +1972,19 @@
         self.assertRaises(OSError, os.waitpid, pid, 0)
         self.assertNotIn(ident, [id(o) for o in subprocess._active])
 
+    def test_close_fds_after_preexec(self):
+        fd_status = support.findfile("fd_status.py", subdir="subprocessdata")
+
+        # FDs created by preexec_fn should be closed in the child
+        p = subprocess.Popen([sys.executable, fd_status],
+                             stdout=subprocess.PIPE, close_fds=True,
+                             preexec_fn=os.pipe)
+        output, ignored = p.communicate()
+
+        remaining_fds = set(map(int, output.split(b',')))
+
+        self.assertLessEqual(remaining_fds, set([0, 1, 2]))
+
 
 @unittest.skipUnless(mswindows, "Windows specific tests")
 class Win32ProcessTestCase(BaseTestCase):
diff -r 49e23a3adf26 Modules/_posixsubprocess.c
--- a/Modules/_posixsubprocess.c	Wed Aug 21 13:26:34 2013 +0200
+++ b/Modules/_posixsubprocess.c	Thu Aug 22 21:19:52 2013 +0200
@@ -412,17 +412,6 @@
         POSIX_CALL(close(errwrite));
     }
 
-    if (close_fds) {
-        int local_max_fd = max_fd;
-#if defined(__NetBSD__)
-        local_max_fd = fcntl(0, F_MAXFD);
-        if (local_max_fd < 0)
-            local_max_fd = max_fd;
-#endif
-        /* TODO HP-UX could use pstat_getproc() if anyone cares about it. */
-        _close_open_fd_range(3, local_max_fd, py_fds_to_keep);
-    }
-
     if (cwd)
         POSIX_CALL(chdir(cwd));
 
@@ -451,6 +440,18 @@
         /* Py_DECREF(result); - We're about to exec so why bother? */
     }
 
+    /* close FDs after executing preexec_fn, which might open FDs */
+    if (close_fds) {
+        int local_max_fd = max_fd;
+#if defined(__NetBSD__)
+        local_max_fd = fcntl(0, F_MAXFD);
+        if (local_max_fd < 0)
+            local_max_fd = max_fd;
+#endif
+        /* TODO HP-UX could use pstat_getproc() if anyone cares about it. */
+        _close_open_fd_range(3, local_max_fd, py_fds_to_keep);
+    }
+
     /* This loop matches the Lib/os.py _execvpe()'s PATH search when */
     /* given the executable_list generated by Lib/subprocess.py.     */
     saved_errno = 0;
-------------- next part --------------
diff -r 84d74eb7a341 Lib/subprocess.py
--- a/Lib/subprocess.py	Wed Aug 21 18:25:00 2013 +0200
+++ b/Lib/subprocess.py	Thu Aug 22 23:20:40 2013 +0200
@@ -1247,16 +1247,17 @@
                                     os.close(fd)
                                     closed.add(fd)
 
-                            # Close all other fds, if asked for
-                            if close_fds:
-                                self._close_fds(but=errpipe_write)
-
                             if cwd is not None:
                                 os.chdir(cwd)
 
                             if preexec_fn:
                                 preexec_fn()
 
+                            # Close all other fds, if asked for - after
+                            # preexec_fn(), which might open FDs
+                            if close_fds:
+                                self._close_fds(but=errpipe_write)
+
                             if env is None:
                                 os.execvp(executable, args)
                             else:

From report at bugs.python.org  Thu Aug 22 23:39:03 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 22 Aug 2013 21:39:03 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a traceback
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1377207543.85.0.732024068503.issue16396@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

The first thing it helps is that it eliminates a ValueError on import. Without it, code must catch both ValueError and ImportError to run portably:

import ctypes

try:
  import ctypes.wintypes
except ImportError, ValueError:
  # catch ImportError and ValueError due to issue16396
  pass

...

def code_that_runs_only_on_win():
  ctypes.wintypes.foo

One _could_ cause ctypes.wintypes to always raise an ImportError on non-Windows systems, allowing the import routine to be simpler:

try:
  import ctypes.wintypes
except ImportError:
  pass

But it would be even nicer if ctypes.wintypes always imported on any platform, such that the statement could be simply:

import ctypes.wintypes

But it's conceivable that certain functionality in wintypes might be useful on other systems. Consider, for example, a routine that works with pickles produced on a Windows system, or simply a comparison of some object in ctypes.wintypes against a value produced on a Windows system.

The argument for that need (esp. on Python 2.7) is not strong, but since the patch to address the ValueError is simple, straightforward, and perhaps even simpler than something that would address the ValueError specifically, it seems worthwhile to accept the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Thu Aug 22 23:48:47 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 22 Aug 2013 21:48:47 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>
Message-ID: <1377208127.05.0.0910132813065.issue18813@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

And in fact, callgrind shows an *increase* in the number of instructions executed for the "use locals" patch (898M with vs. 846M without that patch when running the fannkuch benchmark twice). That speaks against making that change, I guess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Thu Aug 22 23:54:45 2013
From: report at bugs.python.org (Meador Inge)
Date: Thu, 22 Aug 2013 21:54:45 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a traceback
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1377208485.8.0.721778072329.issue16396@psf.upfronthosting.co.za>


Meador Inge added the comment:

Using 'ctypes.wintypes' on non-Windows systems is most likely a bad idea.  Most of the types are defined in terms of the types for the target that the interpreter is built for.  Comparing serializations thereof in a cross platform manner doesn't make sense for a lot of cases.  

I really think it is only useful for Windows platforms and allowing it to silently import is misleading.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Fri Aug 23 00:02:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 22:02:47 +0000
Subject: [issue18686] Tkinter focus_get on menu results in KeyError
In-Reply-To: <1375980942.46.0.944431245569.issue18686@psf.upfronthosting.co.za>
Message-ID: <1377208967.63.0.414511557766.issue18686@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue734176.

Thank you for your example Jeffrey.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Make Tkinter.py's nametowidget work with cloned menu widgets

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18686>
_______________________________________

From report at bugs.python.org  Fri Aug 23 00:02:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Aug 2013 22:02:52 +0000
Subject: [issue734176] Make Tkinter.py's nametowidget work with cloned menu
 widgets
Message-ID: <1377208972.59.0.813980643105.issue734176@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

issue18686 have a script which demonstrates the proposed feature.

However Guilherme's patch is a little wrong. Here is updated patch.

Note that even this patch is not absolute correct, because Tk adds count if new name is not unique. I.e. if .#12345 already exists it try .#123451, .#123452, .#123453, etc. It is impossible restore original name in general case.

----------
nosy: +serhiy.storchaka
versions: +Python 2.7, Python 3.3, Python 3.4 -Python 3.2
Added file: http://bugs.python.org/file31426/nametowidget_clonedmenus_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue734176>
_______________________________________

From report at bugs.python.org  Fri Aug 23 00:11:49 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 22:11:49 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377209509.92.0.695833940274.issue18713@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>>> ('\udcff' + 'qwerty').encode('utf-16le', 'surrogateescape')
b'\xff\xdcq\x00w\x00e\x00r\x00t\x00y\x00'

Oh, this is a bug in the UTF-16 encoder: it should not encode surrogate characters => see issue #12892

I read that it's possible to set a standard stream like stdout in UTF-16 mode on Windows. I don't know if it's commonly used, nor it would impact Python. I never see a platform using UTF-16 or UTF-32 for standard streams.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Fri Aug 23 00:35:14 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 22:35:14 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1377210914.94.0.253438052574.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file31427/17211acb65b1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Fri Aug 23 00:55:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Aug 2013 22:55:32 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1377212132.35.0.589311576682.issue18571@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I tested 17211acb65b1.diff on my x86_64 VMs:

Linux: Linux-3.9.4-200.fc18.x86_64-x86_64-with-fedora-18-Spherical_Cow
=> 358 tests OK.

OpenIndiana: Solaris-2.11-i86pc-i386-32bit-ELF
=> 3 tests failed: test_locale test_tcl test_uuid -- none of these failures are related to the PEP and also occurs in default

Mac OS X: Darwin-10.8.0-i386-64bit
=> 352 tests OK.

FreeBSD: FreeBSD-9.1-RELEASE-amd64-64bit-ELF
=> 351 tests OK.

Windows: Windows-7-6.1.7601-SP1
=> 329 tests OK

So it works on all (tested) platforms ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Fri Aug 23 01:04:42 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 22 Aug 2013 23:04:42 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1377186038.8.0.16299145899.issue18713@psf.upfronthosting.co.za>
Message-ID: <CADiSq7chcoDYZD+vBZqxa7Dv_8crqmo4y6OCTaAK7tuTuwV9Gg@mail.gmail.com>


Nick Coghlan added the comment:

On 23 Aug 2013 01:40, "R. David Murray" <report at bugs.python.org> wrote:
.  (I double checked, and this does indeed work...doing the equivalent of
ls >temp via python preserves the bytes with that PYTHONIOENCODING setting.
 I don't quite understand, however, why I get the ? chars if I don't
redirect the output.).

I assume the terminal window is doing the substitution for the improperly
encoded bytes.

Regarding the issue, perhaps we should convert this to a docs bug? Attempt
to make the "PYTHONIOENCODING=utf-8:surrogateescape" easier to discover?
Heck, it may be worth creating a stable URL that we can include in
surrogate related error messages...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Fri Aug 23 01:06:36 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 22 Aug 2013 23:06:36 +0000
Subject: [issue18713] Enable surrogateescape on stdin and stdout when
 appropriate
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377212796.73.0.980347872449.issue18713@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I think it would be great to have a "Unicode/bytes" howto with information like this included.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Fri Aug 23 01:40:46 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 22 Aug 2013 23:40:46 +0000
Subject: [issue18811] add ssl-based generator to random module
In-Reply-To: <1377191040.61.0.301981053683.issue18811@psf.upfronthosting.co.za>
Message-ID: <1377214846.31.0.298737361802.issue18811@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Improved benchmark script:

Loops: 500000           1       4       8       16      32      64      128
urandom (fd)            0.091   0.185   0.306   0.544   1.060   1.989   3.876
urandom (fd, no buf)    0.504   0.502   0.502   0.806   1.398   2.324   4.086
os.urandom()            1.155   1.154   1.154   1.498   2.052   2.975   4.910
RAND_pseudo_bytes       0.436   0.436   0.435   0.555   0.753   1.064   1.664
RAND_bytes              0.412   0.417   0.417   0.534   0.741   1.046   1.708

----------
Added file: http://bugs.python.org/file31428/prng.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18811>
_______________________________________

From report at bugs.python.org  Fri Aug 23 01:57:26 2013
From: report at bugs.python.org (Valerie Lambert)
Date: Thu, 22 Aug 2013 23:57:26 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>
Message-ID: <1377215846.58.0.25075626571.issue18623@psf.upfronthosting.co.za>


Valerie Lambert added the comment:

I have included a patch that moves _SuppressCoreFiles into test.support and a test that checks whether resource.RLIMIT_CORE is being properly set and reset. It would be nice if there was a more explicit way to test the creation of core files, however.
The patch also corrects a comment that stated ulimit was being set to (0, 0) when in the code only the soft limit was being set to 0. I'm pretty sure that the later should be done because then we don't run into trouble when we have to restore the hard limit to its original (higher) limit.

----------
keywords: +patch
nosy: +lambertv
Added file: http://bugs.python.org/file31429/issue-18623.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18623>
_______________________________________

From report at bugs.python.org  Fri Aug 23 02:07:27 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 23 Aug 2013 00:07:27 +0000
Subject: [issue18811] add ssl-based generator to random module
In-Reply-To: <1377191040.61.0.301981053683.issue18811@psf.upfronthosting.co.za>
Message-ID: <1377216447.25.0.586388154984.issue18811@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


Removed file: http://bugs.python.org/file31419/prng.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18811>
_______________________________________

From report at bugs.python.org  Fri Aug 23 02:18:33 2013
From: report at bugs.python.org (Tim Mooney)
Date: Fri, 23 Aug 2013 00:18:33 +0000
Subject: [issue16902] Add OSS module support for Solaris
In-Reply-To: <1357720040.2.0.175199652567.issue16902@psf.upfronthosting.co.za>
Message-ID: <1377217113.52.0.695853044545.issue16902@psf.upfronthosting.co.za>


Tim Mooney added the comment:

For what it's worth, I've been using a patch nearly identical to this one with python 2.6.x and 2.7.x with good success, and in my case it was under Solaris 10 with the no-cost "oss" package from 4Front.  I now have a new workstation and I've installed OpenIndiana (one of the OpenSolaris derivatives) on it, so I've had to revisit my patch slightly to get it to work with Python 2.7.5.

It causes no real harm to attempt to build ossaudiodev even on earlier Solaris platforms that don't have the package installed.  With Brian's patch or mine, the build reports that it expected to build ossaudiodev but that build failed.  There are other modules that setup.py expects to have work on Solaris that do not, so this is not the first instance of trying something only to have it gracefully fail.  It's really no different from what's being done with linux -- setup.py attempts to build ossaudiodev for all Linux distributions, even though some of them have ripped out support for OSS, in favor of ALSA or Pulse.

I would agree that using individual ifdef's for each define is useful; it appears that the oss package from 4Front provides more of the defines than the modified "Boomer" OSS headers that are part of the OpenSolaris derivatives.

My recommendation would be that Brian's patch or something like it be included as a bug fix in any releases of Python, not as just a "new feature" in the latest release.

----------
nosy: +enchanter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16902>
_______________________________________

From report at bugs.python.org  Fri Aug 23 02:55:20 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 23 Aug 2013 00:55:20 +0000
Subject: [issue18812] PyImport_Import redundant calls to find module
In-Reply-To: <1377198011.48.0.462132559828.issue18812@psf.upfronthosting.co.za>
Message-ID: <1377219320.61.0.655861079581.issue18812@psf.upfronthosting.co.za>


Eric Snow added the comment:

My guess is that, in part, it's left-over code from before the switch to importlib.  However, it relies on builtins.__import__(), which isn't guaranteed to work correctly, hence one last sync with sys.modules.  I'm not convinced that justifies not simply returning the result of calling __import__().

Brett, am I missing something here?

----------
nosy: +brett.cannon, eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18812>
_______________________________________

From report at bugs.python.org  Fri Aug 23 03:46:29 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 23 Aug 2013 01:46:29 +0000
Subject: [issue18811] add ssl-based generator to random module
In-Reply-To: <1377191040.61.0.301981053683.issue18811@psf.upfronthosting.co.za>
Message-ID: <1377222389.23.0.758131887401.issue18811@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18811>
_______________________________________

From report at bugs.python.org  Fri Aug 23 06:02:32 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 23 Aug 2013 04:02:32 +0000
Subject: [issue18814] Add tools for "cleaning" surrogate escaped strings
Message-ID: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Prompted by issue 18713 and http://lucumr.pocoo.org/2013/7/2/the-updated-guide-to-unicode/, here are some possible utilities we could add to the codecs module to help deal with/debug issues related to surrogate escaped strings:

    def has_escaped_bytes(s):
        """Returns true if string contains surrogate escaped bytes"""
        ...

    def replace_escaped_bytes(s):
        """Replaces each surrogate escaped byte with a valid code point"""
        ...

    def decode_escaped_bytes(s, nominal_encoding, actual_encoding):
        """Reinterprets incorrectly decoded text using a new encoding"""
        return s.encode(nominal_encoding, 'surrogateescape').decode(actual_encoding)

----------
messages: 195937
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add tools for "cleaning" surrogate escaped strings
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Fri Aug 23 06:08:18 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 23 Aug 2013 04:08:18 +0000
Subject: [issue18713] Clearly document the use of PYTHONIOENCODING to set
 surrogateescape
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377230898.79.0.357977419834.issue18713@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Note: I created issue 18814 to cover some additional tools for working with surrogate escaped strings.

For this issue, we currently have http://docs.python.org/3/howto/unicode.html, which aims to be a more comprehensive guide to understanding Unicode issues.

I'm thinking we may want a "Debugging Unicode Errors" document, which defers to the existing howto guide for those that really want to understand Unicode, and instead focuses on quick fixes for resolving various problems that may present themselves.

Application developers will likely want to read the longer guide, while the debugging document would be aimed at getting script writers past their immediate hurdle, without necessarily gaining a full understanding of Unicode.

The would be for this page to become the top hit for "python surrogates not allowed", rather than the current top hit, which is a rejected bug report about it (http://bugs.python.org/issue13717).

For example:

================================
What is the meaning of "UnicodeEncodeError: surrogates not allowed"?
--------------------------------------------------------------------

Operating system metadata on POSIX based systems like Linux and Mac OS X may include improperly encoded text values. To cope with this, Python uses the "surrogateescape" error handler to store those arbitrary bytes inside a Unicode object. When converted back to bytes using the same encoding and error handler, the original byte sequence is reproduced exactly. This allows operations like opening a file based on a directory listing to work correctly, even when the metadata is not properly encoded according to the system settings.

The "surrogates not allowed" error appears when a string from one of these operating system interfaces contains an embedded arbitrary byte sequence, but an attempt is made to encode it using the default "strict" error handler rather than the "surrogateescape" handler. This commonly occurs when printing improperly encoded operating system data to the console, or writing it to a file, database or other serialised interface.

The ``PYTHONIOENCODING`` environment variable can be used to ensure operating system metadata can always be read via sys.stdin and written via sys.stdout. The following command will display the encoding Python will use by default to interact with the operating system::

    $ python3 -c "import sys; print(sys.getfilesystemencoding())"
    utf-8

This can then be used to specify an appropriate setting for ``PYTHONIOENCODING``:: 


    $ export PYTHONIOENCODING=utf-8:surrogateescape

For other interfaces, there is no such general solution. If allowing the invalid byte sequence to propagate further is acceptable, then enabling the surrogateescape handler may be appropriate. Alternatively, it may be better to track these corrupted strings back to their point of origin, and either fix the underlying metadata, or else filter them out early on.
================================

If issue 18814 is implemented, then it could point to those tools. Similarly, issue 15216 could be referenced if that is implemented.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: Enable surrogateescape on stdin and stdout when appropriate -> Clearly document the use of PYTHONIOENCODING to set surrogateescape

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Fri Aug 23 06:20:01 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 23 Aug 2013 04:20:01 +0000
Subject: [issue18815] DOCUMENTATION: "mmap .close()" doesn't close the
 underlying file
Message-ID: <1377231601.59.0.456805422296.issue18815@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

In documentation http://docs.python.org/3.3/library/mmap.html#mmap.close you can read: "Close the file". I could interpret that it is going to close the file vinculated to the MMAP. But it doesn't. It only close the MMAP object (as it should).

Please, update doc to clear possible misunderstandings. Thanks.

----------
assignee: docs at python
keywords: easy
messages: 195939
nosy: docs at python, jcea
priority: normal
severity: normal
status: open
title: DOCUMENTATION: "mmap .close()" doesn't close the underlying file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18815>
_______________________________________

From report at bugs.python.org  Fri Aug 23 06:24:01 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 23 Aug 2013 04:24:01 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a traceback
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1377231841.5.0.599838154016.issue16396@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

This is not a regression, though, so most people wouldn't be able to simplify their code because they have to support older Python versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Fri Aug 23 06:39:55 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 23 Aug 2013 04:39:55 +0000
Subject: [issue18814] Add tools for "cleaning" surrogate escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1377232795.23.0.464245532356.issue18814@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Fri Aug 23 06:55:08 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 23 Aug 2013 04:55:08 +0000
Subject: [issue18816] "mmap.flush()" is always synchronous, hurting performance
Message-ID: <1377233708.52.0.141761715851.issue18816@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

Currently, "mmap.flush()" does a synchronous write to the backend file. The call will wait until data is actually flushed to disk, because internally it is doing a "msync(MS_SYNC)".

But the value of "mmap.flush()" is to synchronize file and memory. You don't need a synchronous write in the general case.

I propose to add an optional keyword parameter with default value "SYNC" (compatibility) but that can be "ASYNC", "INVALIDATE" (can be "SYNC|INVALIDATE" and "ASYNC|INVALIDATE" too).

I am talking about UNIX MMAP. No idea about Windows.

Check "man msync" for useful cases.

----------
components: Extension Modules
keywords: easy
messages: 195941
nosy: jcea
priority: normal
severity: normal
status: open
title: "mmap.flush()" is always synchronous, hurting performance
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18816>
_______________________________________

From report at bugs.python.org  Fri Aug 23 07:05:30 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Aug 2013 05:05:30 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>
Message-ID: <1377234330.97.0.228777902125.issue18623@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Could you post your patch without the '--git' option?
Apparently it doesn't work well with the code review tool.

> It would be nice if there was a more explicit way to test the
> creation of core files, however.

One possibility would be to fork() a child process, and make it call os.abort(). In the parent, call os.waitpid(), and call os.WCOREDUMP() on the status.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18623>
_______________________________________

From report at bugs.python.org  Fri Aug 23 07:13:15 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 23 Aug 2013 05:13:15 +0000
Subject: [issue18817] Got resource warning when running Lib/aifc.py
Message-ID: <1377234795.91.0.783821607183.issue18817@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

The python is compiled with debug option.

<omitted>cpython$ ./python Lib/aifc.py Lib/test/sndhdrdata/sndhdr.aiff 
Reading Lib/test/sndhdrdata/sndhdr.aiff
nchannels = 2
nframes   = 5
sampwidth = 2
framerate = 44100
comptype  = b'NONE'
compname  = b'not compressed'
sys:1: ResourceWarning: unclosed file <_io.BufferedReader name='Lib/test/sndhdrdata/sndhdr.aiff'>

Attached the patch to close the file automatically and print "Done." message not just with writing mode but for reading mode as well.

----------
components: Library (Lib)
files: fix_resource_warning_aifc.patch
keywords: patch
messages: 195943
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Got resource warning when running Lib/aifc.py
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file31430/fix_resource_warning_aifc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18817>
_______________________________________

From report at bugs.python.org  Fri Aug 23 08:31:53 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 23 Aug 2013 06:31:53 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>
Message-ID: <1377239513.48.0.47694430994.issue18813@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Here is another patch that remembers the Py_ssize_t slice indices if they are known at instantiation time. It only makes a very small difference for the "fannkuch" benchmark, so that's no reason to add both the complexity and the (IMHO ignorable) memory overhead.

However, it also adds a public C-API function PySlice_FromIndices() that allows setting the values from C code at instantiation time, thus avoiding the overhead of having to do the conversion back again.

It might also be worth exploring if we can't instantiate the Python object indices at first request using properties, iff the slice was created with integer indices. Meaning, we'd leave the PyObject* fields NULL in that case until they are being used. That would reduce the overhead of creating the slice object in the first place. Since we added the one-instance cache, it's now dominated by the creation of the index value objects when _PySlice_FromIndices() is being used internally (e.g. when calling PySequence_Get/Set/DelSlice()).

----------
Added file: http://bugs.python.org/file31431/cache_slice_indices.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Fri Aug 23 08:41:47 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 23 Aug 2013 06:41:47 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377240107.58.0.561397740158.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Ok, so what are we going to do for the next alpha?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug 23 08:45:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 06:45:48 +0000
Subject: [issue18818] Empty PYTHONIOENCODING is not the same as nonexistent
Message-ID: <1377240348.58.0.0824436318174.issue18818@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ PYTHONIOENCODING= ./python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: 
Aborted (core dumped)

As a consequence we can't set only the error handler.

$ PYTHONIOENCODING=:surrogateescape ./python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: 
Aborted (core dumped)

Here is a patch which allows accepting empty encoding as default encoding.

----------
components: Interpreter Core
files: empty_pythonioencoding.patch
keywords: patch
messages: 195946
nosy: haypo, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Empty PYTHONIOENCODING is not the same as nonexistent
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31432/empty_pythonioencoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18818>
_______________________________________

From report at bugs.python.org  Fri Aug 23 08:46:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 06:46:35 +0000
Subject: [issue18713] Clearly document the use of PYTHONIOENCODING to set
 surrogateescape
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377240395.59.0.911169057582.issue18713@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Empty PYTHONIOENCODING is not the same as nonexistent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Fri Aug 23 08:54:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 06:54:45 +0000
Subject: [issue18818] Empty PYTHONIOENCODING is not the same as nonexistent
In-Reply-To: <1377240348.58.0.0824436318174.issue18818@psf.upfronthosting.co.za>
Message-ID: <1377240885.41.0.21436494609.issue18818@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file31432/empty_pythonioencoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18818>
_______________________________________

From report at bugs.python.org  Fri Aug 23 08:55:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 06:55:05 +0000
Subject: [issue18818] Empty PYTHONIOENCODING is not the same as nonexistent
In-Reply-To: <1377240348.58.0.0824436318174.issue18818@psf.upfronthosting.co.za>
Message-ID: <1377240905.26.0.433584004839.issue18818@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file31433/empty_pythonioencoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18818>
_______________________________________

From report at bugs.python.org  Fri Aug 23 09:07:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 07:07:02 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>
Message-ID: <1377241622.93.0.706085726593.issue18813@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +mark.dickinson, serhiy.storchaka
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Fri Aug 23 09:44:43 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 23 Aug 2013 07:44:43 +0000
Subject: [issue18818] Empty PYTHONIOENCODING is not the same as nonexistent
In-Reply-To: <1377240348.58.0.0824436318174.issue18818@psf.upfronthosting.co.za>
Message-ID: <1377243883.86.0.845245370114.issue18818@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18818>
_______________________________________

From report at bugs.python.org  Fri Aug 23 09:48:45 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Aug 2013 07:48:45 +0000
Subject: [issue18816] "mmap.flush()" is always synchronous, hurting performance
In-Reply-To: <1377233708.52.0.141761715851.issue18816@psf.upfronthosting.co.za>
Message-ID: <1377244125.43.0.955442612148.issue18816@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

> I propose to add an optional keyword parameter with default value "SYNC" (compatibility) but that can be "ASYNC", "INVALIDATE" (can be "SYNC|INVALIDATE" and "ASYNC|INVALIDATE" too).

AFAICT it's mostly useless on a modern OS.
MS_INVALIDATE is a no-op on systems with merged VM-buffer cache, i.e.
it's not needed for mmap() to reflect write() and vice-versa.

So nothing's normally needed to "synchronize file and memory".

As for MS_ASYNC, it actually doesn't do anything at all on recent OS,
e.g. it's a no-op on Linux since a couple years, since modified pages
will be written back as part of the normal writeback process.

The only thing a user might actually need for an mmap object is to
make sure data is actually committed to disk, and MS_SYNC covers this.

See e.g. this post by Andrew Morton:
http://thread.gmane.org/gmane.linux.kernel/1312660

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18816>
_______________________________________

From report at bugs.python.org  Fri Aug 23 09:56:10 2013
From: report at bugs.python.org (Nuutti Kotivuori)
Date: Fri, 23 Aug 2013 07:56:10 +0000
Subject: [issue18819] tarfile fills devmajor and devminor fields even for
 non-devices
Message-ID: <1377244570.17.0.881759543234.issue18819@psf.upfronthosting.co.za>


New submission from Nuutti Kotivuori:

when tarfile generates a tar, it uses TarInfo objects which are packed to the binary format. This packing uses "itn" format for filling the "devmajor" and "devminor" fields of the tar file entry, with a default value of zero. The field length is 8 characters, and the formatting will format the values as octal strings, followed by a NUL byte, eg. '0000000\x00'.

However, other common tar tools do not exhibit this behavior, instead leaving the field filled with NUL bytes in case the earlier type field does not indicate a device type. Explicitly, the value generated by other tools is then '\x00\x00\x00\x00\x00\x00\x00\x00'.

This causes no interoperability issues (that I am aware of), but makes it hard to attempt to replicate the tar files generated by other tools exactly.

I am attaching a simple diff fixing this, but there are probably better ways to fix this.

----------
components: Library (Lib)
files: tarfile.py.diff
keywords: patch
messages: 195949
nosy: Nuutti.Kotivuori
priority: normal
severity: normal
status: open
title: tarfile fills devmajor and devminor fields even for non-devices
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31434/tarfile.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18819>
_______________________________________

From report at bugs.python.org  Fri Aug 23 10:01:17 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 08:01:17 +0000
Subject: [issue18818] Empty PYTHONIOENCODING is not the same as nonexistent
In-Reply-To: <1377243883.86.0.845245370114.issue18818@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYKgfTvpFb5Z_zi1bNmbs1kv_9JucJN4NarEy3y66ZVCg@mail.gmail.com>


STINNER Victor added the comment:

Patch looks good to me, but you have to update Doc/using/cmdline.rst,
at least to add a versionchanged section.

Tests would also be nice :-)

I really like the the "PYTHONIOENCODING=:surrogateescape" use case!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18818>
_______________________________________

From report at bugs.python.org  Fri Aug 23 10:04:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 08:04:34 +0000
Subject: [issue18818] Empty PYTHONIOENCODING is not the same as nonexistent
In-Reply-To: <1377240348.58.0.0824436318174.issue18818@psf.upfronthosting.co.za>
Message-ID: <1377245074.68.0.117070566636.issue18818@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Second variant of the patch also supports empty error handler as the default error handler (i.e. strict).

$ PYTHONIOENCODING=ascii: ./python
Python 3.4.0a1+ (default:5b5ef012cd4e+, Aug 23 2013, 10:18:51) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print('\xbd')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character '\xbd' in position 0: ordinal not in range(128)

Without it different error is raised:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
LookupError: unknown error handler name ''

----------
Added file: http://bugs.python.org/file31435/empty_pythonioencoding_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18818>
_______________________________________

From report at bugs.python.org  Fri Aug 23 10:20:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 08:20:58 +0000
Subject: [issue18817] Got resource warning when running Lib/aifc.py
In-Reply-To: <1377234795.91.0.783821607183.issue18817@psf.upfronthosting.co.za>
Message-ID: <1377246058.42.0.845553852437.issue18817@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18817>
_______________________________________

From report at bugs.python.org  Fri Aug 23 10:22:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 08:22:12 +0000
Subject: [issue18807] Allow venv to create copies,
 even when symlinks are supported
In-Reply-To: <1377176626.74.0.056181108419.issue18807@psf.upfronthosting.co.za>
Message-ID: <1377246132.03.0.918485965415.issue18807@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18807>
_______________________________________

From report at bugs.python.org  Fri Aug 23 10:25:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 08:25:05 +0000
Subject: [issue15175] pydoc -k zip throws segmentation fault
In-Reply-To: <1340581488.74.0.233169752541.issue15175@psf.upfronthosting.co.za>
Message-ID: <1377246305.65.0.697476969952.issue15175@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yeah, pydoc will walk and import all installed Python modules, which may trigger various kinds of issues with buggy third-party stuff.

Note that in 2.x, extension modules compiled with different fundamental options (such as debug/non-debug) aren't differentiated, which may the be cause of the present issue.

----------
nosy: +pitrou
resolution:  -> rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15175>
_______________________________________

From report at bugs.python.org  Fri Aug 23 10:58:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 08:58:05 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>
Message-ID: <1377248285.75.0.217163587778.issue18623@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Will also be useful for issue #18808 :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18623>
_______________________________________

From report at bugs.python.org  Fri Aug 23 11:07:05 2013
From: report at bugs.python.org (Drekin)
Date: Fri, 23 Aug 2013 09:07:05 +0000
Subject: [issue13758] compile() should not encode 'filename' (at least on
 Windows)
In-Reply-To: <1326253604.11.0.305060780894.issue13758@psf.upfronthosting.co.za>
Message-ID: <1377248825.37.0.745006246108.issue13758@psf.upfronthosting.co.za>


Drekin added the comment:

Hello. Will this be fixed? It's really annoying that you cannot pass valid unicode filename to compile(). I'm using a workaround: I just pass "<placeholder>" and then ?update? the resulting code object recursively to set the correct co_filename. Afterwards the code object can be executed and produces correct tracebacks. (I'm using Windows.)

Fixing this will probably fix also http://bugs.python.org/issue17588 . It doesn't bother just me. See e.g. http://stackoverflow.com/questions/8798591/unicodeencodeerror-when-using-the-compile-function .

Thank you. Drekin

----------
nosy: +Drekin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13758>
_______________________________________

From report at bugs.python.org  Fri Aug 23 11:08:16 2013
From: report at bugs.python.org (Drekin)
Date: Fri, 23 Aug 2013 09:08:16 +0000
Subject: [issue17588] runpy cannot run Unicode path on Windows
In-Reply-To: <1364753330.76.0.973974217823.issue17588@psf.upfronthosting.co.za>
Message-ID: <1377248896.95.0.0439831569813.issue17588@psf.upfronthosting.co.za>


Drekin added the comment:

There is over year old closely related issue: http://bugs.python.org/issue13758 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17588>
_______________________________________

From report at bugs.python.org  Fri Aug 23 11:10:00 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 23 Aug 2013 09:10:00 +0000
Subject: [issue18818] Empty PYTHONIOENCODING is not the same as nonexistent
In-Reply-To: <1377240348.58.0.0824436318174.issue18818@psf.upfronthosting.co.za>
Message-ID: <1377249000.22.0.897878625308.issue18818@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18818>
_______________________________________

From report at bugs.python.org  Fri Aug 23 11:13:45 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 23 Aug 2013 09:13:45 +0000
Subject: [issue16392] import crashes on circular imports in ext modules
In-Reply-To: <1351946554.54.0.101006341814.issue16392@psf.upfronthosting.co.za>
Message-ID: <1377249225.67.0.218782416145.issue16392@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16392>
_______________________________________

From report at bugs.python.org  Fri Aug 23 11:15:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 09:15:05 +0000
Subject: [issue18811] add ssl-based generator to random module
In-Reply-To: <1377191040.61.0.301981053683.issue18811@psf.upfronthosting.co.za>
Message-ID: <1377249305.3.0.394670607995.issue18811@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Seriously, why are we obsessed with performance when talking about a security feature? Did anyone *actually* complain about urandom() being too slow (ok, someone complained about it eating file descriptors... :-))?

The question is whether OpenSSL's random generator produces better randomness than the system one: apparently it's not the case under Linux, how about other systems?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18811>
_______________________________________

From report at bugs.python.org  Fri Aug 23 12:30:30 2013
From: report at bugs.python.org (July Tikhonov)
Date: Fri, 23 Aug 2013 10:30:30 +0000
Subject: [issue18820] json.dump() ignores its 'default' option when
 serializing dictionary keys
Message-ID: <1377253830.03.0.463497944995.issue18820@psf.upfronthosting.co.za>


New submission from July Tikhonov:

According to documentation of json.dump(), concerning its 'default' option:

default(obj) is a function that should return a serializable version of obj or raise TypeError. The default simply raises TypeError.

But this function is actually never applied to serialized dictionary keys:

>>> def default(obj):
...  if isinstance(obj, bytes):
...   return obj.decode('ascii')
...  raise ValueError
... 
>>> json.dumps(b'asdf')
Traceback (most recent call last):
...
TypeError: b'asdf' is not JSON serializable
>>> json.dumps(b'asdf', default=default)
'"asdf"'
>>> json.dumps({b'asdf' : 1}, default=default)
Traceback (most recent call last):
...
TypeError: keys must be a string
>>> json.dumps({1 : b'asdf'}, default=default)
'{"1": "asdf"}'

(bytes are used purely for the purpose of example)
Such behavior should be either documented or corrected.
Patch correcting python implementation of json attached.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: json-default-dict-keys.diff
keywords: patch
messages: 195957
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: json.dump() ignores its 'default' option when serializing dictionary keys
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31436/json-default-dict-keys.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18820>
_______________________________________

From report at bugs.python.org  Fri Aug 23 12:58:37 2013
From: report at bugs.python.org (July Tikhonov)
Date: Fri, 23 Aug 2013 10:58:37 +0000
Subject: [issue18820] json.dump() ignores its 'default' option when
 serializing dictionary keys
In-Reply-To: <1377253830.03.0.463497944995.issue18820@psf.upfronthosting.co.za>
Message-ID: <1377255517.71.0.983663189845.issue18820@psf.upfronthosting.co.za>


July Tikhonov added the comment:

Oops, my patch disables 'skipkeys' argument of dump. Another version attached.

----------
Added file: http://bugs.python.org/file31437/json-default-dict-keys.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18820>
_______________________________________

From report at bugs.python.org  Fri Aug 23 12:59:26 2013
From: report at bugs.python.org (July Tikhonov)
Date: Fri, 23 Aug 2013 10:59:26 +0000
Subject: [issue18820] json.dump() ignores its 'default' option when
 serializing dictionary keys
In-Reply-To: <1377253830.03.0.463497944995.issue18820@psf.upfronthosting.co.za>
Message-ID: <1377255566.86.0.382620982733.issue18820@psf.upfronthosting.co.za>


Changes by July Tikhonov <july.tikh at gmail.com>:


Removed file: http://bugs.python.org/file31436/json-default-dict-keys.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18820>
_______________________________________

From report at bugs.python.org  Fri Aug 23 13:00:34 2013
From: report at bugs.python.org (Radu Voicilas)
Date: Fri, 23 Aug 2013 11:00:34 +0000
Subject: [issue18652] Add itertools.first_true (return first true item in
 iterable)
In-Reply-To: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>
Message-ID: <1377255634.84.0.668704189444.issue18652@psf.upfronthosting.co.za>


Changes by Radu Voicilas <radu.voicilas at gmail.com>:


----------
nosy: +raduv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18652>
_______________________________________

From report at bugs.python.org  Fri Aug 23 13:02:55 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Aug 2013 11:02:55 +0000
Subject: [issue18814] Add tools for "cleaning" surrogate escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1377255775.3.0.898468795258.issue18814@psf.upfronthosting.co.za>


R. David Murray added the comment:

The email package needs has_escaped_bytes.  Currently it tries to encode to ascii to find out if there are any, which we proved by microbenchmark is the fastest way to do it as things stand.

What does replace do?  Replace it with the unknown character code point?  Email also needs that.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Fri Aug 23 13:20:52 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 23 Aug 2013 11:20:52 +0000
Subject: [issue18807] Allow venv to create copies,
 even when symlinks are supported
In-Reply-To: <1377176626.74.0.056181108419.issue18807@psf.upfronthosting.co.za>
Message-ID: <1377256852.79.0.334483664701.issue18807@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vinay.sajip
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18807>
_______________________________________

From report at bugs.python.org  Fri Aug 23 13:55:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 11:55:16 +0000
Subject: [issue18814] Add tools for "cleaning" surrogate escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1377258916.29.0.903757661508.issue18814@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

These functions are trivial.

    def has_escaped_bytes(s):
        try:
            s.encode()
            return False
        except UnicodeEncodeError:
            return True

    def replace_escaped_bytes(s):
        return s.encode('utf-8', 'replace').decode()

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Fri Aug 23 14:11:24 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 23 Aug 2013 12:11:24 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1377259884.58.0.712747137631.issue18772@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I just applied the dict version of dummy to sets in http://hg.python.org/cpython/rev/f0202c3daa7a
and it unexpectedly broke test_gdb again:

FAIL: test_sets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of sets
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/test_gdb.py", line 319, in test_sets
    self.assertEqual(gdb_repr, "{'b'}")
AssertionError: "{<<dummy key> type at remote 0x103b35c0>, 'b'}" != "{'b'}"
- {<<dummy key> type at remote 0x103b35c0>, 'b'}
+ {'b'}



Antoine, can you see what the issue is?  Why does this show as the dummy key type instead of being recognized as the object returned by _PySet_Dummy?   I'm not sure why this works for dicts, but not for sets.

----------
assignee: rhettinger -> pitrou
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Fri Aug 23 14:19:54 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Fri, 23 Aug 2013 12:19:54 +0000
Subject: [issue18821] Add .lastitem attribute to takewhile instances
Message-ID: <1377260394.63.0.429867593592.issue18821@psf.upfronthosting.co.za>


New submission from Oscar Benjamin:

I've often wanted to be able to query a takewhile object to discover the item that failed the predicate but the item is currently discarded.

A usage example:

def sum(items):
    it = iter(items)
    ints = takewhile(Integral.__instancecheck__, it)
    subtotal = sum(ints)
    if not hasattr(ints.lastitem):
        return subtotal
    floats = takewhile(float.__instancecheck__, it)
    subtotalf = fsum(floats)
    if not hasattr(floats.lastitem):
        return subtotal + subtotalf
    # Deal with more types
    ...


Loosely what I'm thinking is this but perhaps with different attribute names:


class takewhile(pred, iterable):
    def __init__(self):
        self.pred = pred
        self.iterable = iterable
        self.failed = False
    def __iter__(self):
        for item in self.iterable:
            if self.pred(item):
                yield item
            else:
                self.failed = True
                self.lastitem = item
                return

----------
components: Library (Lib)
messages: 195962
nosy: oscarbenjamin
priority: normal
severity: normal
status: open
title: Add .lastitem attribute to takewhile instances
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18821>
_______________________________________

From report at bugs.python.org  Fri Aug 23 14:22:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 12:22:38 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1377260558.45.0.388261438235.issue18772@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Checking for dummies in dicts in python-gdb.py is implicit (see PyDictObjectPtr.iteritems()): entries whose value is NULL are not printed.

Set entries do not have values, so instead pySetObjectPtr.write_repr() uses a hack with the repr() of the key to check for dummies. Instead I think we should re-use the approach in my patch: publish the dummy object as a (private) C API so that python-gdb.py can simply compare the key pointer by equality.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Fri Aug 23 14:30:24 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Aug 2013 12:30:24 +0000
Subject: [issue18812] PyImport_Import redundant calls to find module
In-Reply-To: <1377198011.48.0.462132559828.issue18812@psf.upfronthosting.co.za>
Message-ID: <1377261024.67.0.114049345833.issue18812@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Because that is how it has always been: http://hg.python.org/cpython/file/b9b521efeba3/Python/import.c#l3164 . It could be changed but someone out there is relying on those semantics and it's a minor thing to leave in so I don't want to mess with it.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18812>
_______________________________________

From report at bugs.python.org  Fri Aug 23 14:51:01 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 23 Aug 2013 12:51:01 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1377262261.58.0.584228513698.issue18772@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Attaching a patch, but I don't have a way to test it.

----------
Added file: http://bugs.python.org/file31438/fix_dummy.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Fri Aug 23 14:52:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 12:52:26 +0000
Subject: [issue18713] Clearly document the use of PYTHONIOENCODING to set
 surrogateescape
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1377262346.43.0.646810991672.issue18713@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

With new subject this issue looks as a duplicate of (or tightly related to) issue12832.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18713>
_______________________________________

From report at bugs.python.org  Fri Aug 23 15:31:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 13:31:13 +0000
Subject: [issue5876] __repr__ returning unicode doesn't work when called
 implicitly
In-Reply-To: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za>
Message-ID: <1377264673.35.0.367417638823.issue5876@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In Python 3 ascii() uses the backslashreplace error handler.

>>> class T:
...     def __repr__(self):
...         return '\u20ac\udcff'
... 
>>> print(ascii(T()))
\u20ac\udcff

I think using the backslashreplace error handler in repr() in Python 2.7 is good solution. Here is a patch.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage: test needed -> patch review
Added file: http://bugs.python.org/file31439/unicode_repr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5876>
_______________________________________

From report at bugs.python.org  Fri Aug 23 15:36:02 2013
From: report at bugs.python.org (Rob Bairos)
Date: Fri, 23 Aug 2013 13:36:02 +0000
Subject: [issue18812] PyImport_Import redundant calls to find module
In-Reply-To: <1377198011.48.0.462132559828.issue18812@psf.upfronthosting.co.za>
Message-ID: <1377264962.09.0.415787361141.issue18812@psf.upfronthosting.co.za>


Rob Bairos added the comment:

However, if it fails __import()__  it doesn't get to the sys.modules[] call anyways.

The only case affected by this are:

  PASS the __import()__ call, 
  then FAIL the sys.modules[] lookup afterwards.

Why will that effect anything currently out there?

As it stands now, it suppresses development of some types of dynamic hierarchies of modules such as we've implemented, that don't register themselves in sys.modules[]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18812>
_______________________________________

From report at bugs.python.org  Fri Aug 23 15:42:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 13:42:02 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1377265322.44.0.781843151304.issue18772@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Checking repr() perpetuates the original hack so, why it may work, I think it's better if we take the opportunity to solve it cleanly.
I'll try to take a look tonight (I suppose you're under Windows?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Fri Aug 23 15:43:43 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 13:43:43 +0000
Subject: [issue5876] __repr__ returning unicode doesn't work when called
 implicitly
In-Reply-To: <1377264673.35.0.367417638823.issue5876@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ+NQN6zrDKJ-r28nVRxnYL2_yMCZD4EOwi6j7C9SkUWA@mail.gmail.com>


STINNER Victor added the comment:

This change is going to break backward compatibility. I don't think
that it can be done in Python 2.7.x, and there is no Python 2.8 (PEP
404).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5876>
_______________________________________

From report at bugs.python.org  Fri Aug 23 15:53:06 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 23 Aug 2013 13:53:06 +0000
Subject: [issue18816] "mmap.flush()" is always synchronous, hurting performance
In-Reply-To: <1377233708.52.0.141761715851.issue18816@psf.upfronthosting.co.za>
Message-ID: <1377265986.52.0.577159900734.issue18816@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Depending of a concrete OS implementation is not good. Linux is not the only OS out there, and I have very old machines in production yet:

"""
# uname -a
Linux colquide.XXXX.es 2.4.37 #4 Fri Dec 12 01:10:45 CET 2008 i686 unknown
"""

I have been hit by the VM/file cache split in the past. Portability is important.

Anyway, the Python "mmap" manual says that "mmap.flush()" is needed to be sure that you are not going to "lose" changes you made in the mmap. On "modern" OSs it is not actually needed, as you say, and the performance hit is important enough for me to investigate and write this enhancement proposal :).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18816>
_______________________________________

From report at bugs.python.org  Fri Aug 23 16:14:18 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 23 Aug 2013 14:14:18 +0000
Subject: [issue17883] Fix buildbot testing of Tkinter
In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za>
Message-ID: <1377267258.81.0.863733622635.issue17883@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Ping!

The buildbots still seem to be failing, are my proposed fixes acceptable?  Both patches still apply cleanly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17883>
_______________________________________

From report at bugs.python.org  Fri Aug 23 16:20:30 2013
From: report at bugs.python.org (Drekin)
Date: Fri, 23 Aug 2013 14:20:30 +0000
Subject: [issue17702] os.environ converts key type from string to bytes in
 KeyError exception
In-Reply-To: <1365726971.44.0.005141093776.issue17702@psf.upfronthosting.co.za>
Message-ID: <1377267630.83.0.227523362114.issue17702@psf.upfronthosting.co.za>


Drekin added the comment:

This patch introduces a bit ugly traceback. Shouldn't there be ?raise from None? or ?raise from previous_exc? instead of simple raise?

----------
nosy: +Drekin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17702>
_______________________________________

From report at bugs.python.org  Fri Aug 23 16:28:20 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 23 Aug 2013 14:28:20 +0000
Subject: [issue18811] add ssl-based generator to random module
In-Reply-To: <1377249305.3.0.394670607995.issue18811@psf.upfronthosting.co.za>
Message-ID: <559ecb7e-b0ba-46ef-ab77-8cdd8ef508fb@email.android.com>


Christian Heimes added the comment:

I don't get it either. urandom is perfectly fine. I showed that urandom is just a bit slower than SSL_rand().

How about we generalize SystemRandom so  users can implement a custom RNG class wby providing a method rng(amount) -> bytes?

Antoine Pitrou <report at bugs.python.org> schrieb:
>
>Antoine Pitrou added the comment:
>
>Seriously, why are we obsessed with performance when talking about a
>security feature? Did anyone *actually* complain about urandom() being
>too slow (ok, someone complained about it eating file descriptors...
>:-))?
>
>The question is whether OpenSSL's random generator produces better
>randomness than the system one: apparently it's not the case under
>Linux, how about other systems?
>
>----------
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue18811>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18811>
_______________________________________

From report at bugs.python.org  Fri Aug 23 16:34:55 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Aug 2013 14:34:55 +0000
Subject: [issue18811] add ssl-based generator to random module
In-Reply-To: <1377191040.61.0.301981053683.issue18811@psf.upfronthosting.co.za>
Message-ID: <1377268495.68.0.0309563777888.issue18811@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

> How about we generalize SystemRandom so  users can implement
> a custom RNG class wby providing a method rng(amount) -> bytes?

The random module already makes it easy:
"""
Class Random can also be subclassed if you want to use a different basic generator of your own devising: in that case, override the random(), seed(), getstate(), and setstate() methods. Optionally, a new generator can supply a getrandbits() method ? this allows randrange() to produce selections over an arbitrarily large range.
"""

> I showed that urandom is just a bit slower than SSL_rand().

"Just a bit" is relative, I read from 2 to 3 times slower, on Linux.

> I don't get it either. urandom is perfectly fine.

Alright, closing then.

----------
resolution:  -> rejected
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18811>
_______________________________________

From report at bugs.python.org  Fri Aug 23 16:36:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 14:36:16 +0000
Subject: [issue18811] add ssl-based generator to random module
In-Reply-To: <559ecb7e-b0ba-46ef-ab77-8cdd8ef508fb@email.android.com>
Message-ID: <1833650286.7806201.1377268569854.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> How about we generalize SystemRandom so  users can implement a custom
> RNG class wby providing a method rng(amount) -> bytes?

We may make it easier to implement custom Random implementations with
user-defined random generators, but they needn't be *SystemRandom*
subclasses ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18811>
_______________________________________

From report at bugs.python.org  Fri Aug 23 16:40:28 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 23 Aug 2013 14:40:28 +0000
Subject: [issue18326] Mention 'keyword only' for list.sort, improve  glossary.
In-Reply-To: <1372511136.61.0.278425078947.issue18326@psf.upfronthosting.co.za>
Message-ID: <1377268828.19.0.593036145121.issue18326@psf.upfronthosting.co.za>


Zachary Ware added the comment:

How about a combination of the two?  It's still short, but gets the point across without assuming the reader knows exactly what 'keyword-only argument' or requiring further reading, while introducing the term and providing the link for deeper understanding.

(Here's the relevant change in this patch, the rest is the same:)

+      :meth:`sort` accepts two arguments that must be passed by keyword
+      (:ref:`keyword-only arguments <keyword-only_parameter>`):

----------
Added file: http://bugs.python.org/file31440/issue18326.v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18326>
_______________________________________

From report at bugs.python.org  Fri Aug 23 16:56:07 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Aug 2013 14:56:07 +0000
Subject: [issue18812] PyImport_Import redundant calls to find module
In-Reply-To: <1377198011.48.0.462132559828.issue18812@psf.upfronthosting.co.za>
Message-ID: <1377269767.55.0.795949724261.issue18812@psf.upfronthosting.co.za>


Brett Cannon added the comment:

If I were to change this code in any way it would be to stop passing in a dummy value for fromlist, not stop pulling from sys.modules. The official idiom for directly calling __import__() is::

  __import__(module_name)
  return sys.modules[module_name]

It just so happens PyImport_Import() is old enough to be using both the old idiom of a bogus fromlist item *and* been updated at some point to use the new idiom.

I would also strongly discourage you from replacing __import__. More and more code is using importlib and various importers to do things and so it might have unforeseen consequences. importlib.import_module() also relies on importlib.__import__, not builtins.__import__ so as more code switches to that function for dynamic importing it will lead to more imports not using an overridden __import__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18812>
_______________________________________

From report at bugs.python.org  Fri Aug 23 17:08:46 2013
From: report at bugs.python.org (Freek Dijkstra)
Date: Fri, 23 Aug 2013 15:08:46 +0000
Subject: [issue17400] ipaddress.is_private needs to take into account of
 rfc6598
In-Reply-To: <1363052217.02.0.113831391012.issue17400@psf.upfronthosting.co.za>
Message-ID: <1377270526.42.0.427038514045.issue17400@psf.upfronthosting.co.za>


Freek Dijkstra added the comment:

Peter, first of all, thanks for your library. I didn't mention that before, but should have.


I'm in favour of a pragmatic approach. I've only come across NATing for RFC 1918 and RFC 6598 addresses. While it can technically be done for other addresses, and is allowed by RFC 3022 section 5.1, I have never seen that in practice.

is_natted() (or perhaps: is_nattable()?) could be used by a SIP client to decide if it should include a VIA header or not, without need to do a resource-expensive NAT check at all times.

To be clear: I'm not a great fan of is_natted() myself, but I fear that keeping is_private() the way it is, people will use it as if it meant is_natted() and will end up with unintended errors in their code.


is_forward and is_global -if deemed useful- should just follow the columns at http://www.iana.org/assignments/iana-ipv4-special-registry and http://www.iana.org/assignments/iana-ipv6-special-registry. Perhaps functions like is_valid_source(), is_valid_destination() and is_reserved() may be included too.

The meaning of these columns is explained in [http://tools.ietf.org/html/rfc6890#section-2.2.1 RFC 6890]. I interpret forwardable as "should be forwarded by a router" and global as "may be seen on the Internet / should be forwarded beyond administrative domain boundaries". For example, private IP addresses or benchmarking IP addresses may be routed just fine, as long as they're never seen on the global Internet.

PS: There is a typo in the documentation. is_unspecified mentions RFC 5375, but that should be RFC 5735, which in turn is obsoleted by RFC 6890. I'll see if I can make a patch, but that will be after my holiday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17400>
_______________________________________

From report at bugs.python.org  Fri Aug 23 17:12:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 15:12:35 +0000
Subject: [issue17702] os.environ converts key type from string to bytes in
 KeyError exception
In-Reply-To: <1365726971.44.0.005141093776.issue17702@psf.upfronthosting.co.za>
Message-ID: <1377270755.93.0.20764058069.issue17702@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"This patch introduces a bit ugly traceback. Shouldn't there be ?raise from None? or ?raise from previous_exc? instead of simple raise?"

Oh, I see.

>>> os.environb[b'10']
Traceback (most recent call last):
  File "/home/vstinner/prog/python/default/Lib/os.py", line 648, in __getitem__
    value = self._data[self.encodekey(key)]
KeyError: b'10'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/vstinner/prog/python/default/Lib/os.py", line 651, in __getitem__
    raise KeyError(key)
KeyError: b'10'

Attached patch adds "from None".

----------
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file31441/os_environb_raise_from_none.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17702>
_______________________________________

From report at bugs.python.org  Fri Aug 23 17:12:52 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 15:12:52 +0000
Subject: [issue17400] ipaddress.is_private needs to take into account of
 rfc6598
In-Reply-To: <1363052217.02.0.113831391012.issue17400@psf.upfronthosting.co.za>
Message-ID: <1377270772.77.0.630443316442.issue17400@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17400>
_______________________________________

From report at bugs.python.org  Fri Aug 23 17:15:46 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 23 Aug 2013 15:15:46 +0000
Subject: [issue17326] Windows build docs still referring to VS 2008 in 3.3
In-Reply-To: <1362142705.89.0.367756520949.issue17326@psf.upfronthosting.co.za>
Message-ID: <1377270946.31.0.665693398458.issue17326@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17326>
_______________________________________

From report at bugs.python.org  Fri Aug 23 17:32:10 2013
From: report at bugs.python.org (Drekin)
Date: Fri, 23 Aug 2013 15:32:10 +0000
Subject: [issue17702] os.environ converts key type from string to bytes in
 KeyError exception
In-Reply-To: <1365726971.44.0.005141093776.issue17702@psf.upfronthosting.co.za>
Message-ID: <1377271930.3.0.801962660392.issue17702@psf.upfronthosting.co.za>


Drekin added the comment:

It's also in __delitem__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17702>
_______________________________________

From report at bugs.python.org  Fri Aug 23 17:37:04 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 15:37:04 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1377272224.6.0.264429284518.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file31413/775890a666bf.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Fri Aug 23 17:52:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Aug 2013 15:52:53 +0000
Subject: [issue18755] imp read functions do not try to re-open files that have
 been closed from previous reads
In-Reply-To: <1376663695.08.0.173153451138.issue18755@psf.upfronthosting.co.za>
Message-ID: <3cM6ZX4FcVz7LsH@mail.python.org>


Roundup Robot added the comment:

New changeset ddd610cb65ef by Brett Cannon in branch '3.3':
Issue #18755: Allow imp.load_*() loaders to have get_data() called
http://hg.python.org/cpython/rev/ddd610cb65ef

New changeset b107f7a8730d by Brett Cannon in branch '3.3':
NEW entry for issue #18755
http://hg.python.org/cpython/rev/b107f7a8730d

New changeset 7d30ecf5c916 by Brett Cannon in branch 'default':
merge for issue #18755
http://hg.python.org/cpython/rev/7d30ecf5c916

New changeset 174bfa137472 by Brett Cannon in branch 'default':
merge for issue #18755
http://hg.python.org/cpython/rev/174bfa137472

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18755>
_______________________________________

From report at bugs.python.org  Fri Aug 23 17:56:08 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Aug 2013 15:56:08 +0000
Subject: [issue13758] compile() should not encode 'filename' (at least on
 Windows)
In-Reply-To: <1326253604.11.0.305060780894.issue13758@psf.upfronthosting.co.za>
Message-ID: <1377273368.68.0.775209741146.issue13758@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Victor, do you have any opinion on this unicode filename issue?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13758>
_______________________________________

From report at bugs.python.org  Fri Aug 23 17:56:37 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Aug 2013 15:56:37 +0000
Subject: [issue18755] imp read functions do not try to re-open files that have
 been closed from previous reads
In-Reply-To: <1376663695.08.0.173153451138.issue18755@psf.upfronthosting.co.za>
Message-ID: <1377273397.56.0.0518306187616.issue18755@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18755>
_______________________________________

From report at bugs.python.org  Fri Aug 23 18:15:45 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 23 Aug 2013 16:15:45 +0000
Subject: [issue18821] Add .lastitem attribute to takewhile instances
In-Reply-To: <1377260394.63.0.429867593592.issue18821@psf.upfronthosting.co.za>
Message-ID: <1377274545.27.0.251531288355.issue18821@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18821>
_______________________________________

From report at bugs.python.org  Fri Aug 23 18:23:34 2013
From: report at bugs.python.org (Valerie Lambert)
Date: Fri, 23 Aug 2013 16:23:34 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>
Message-ID: <1377275014.44.0.372930035151.issue18623@psf.upfronthosting.co.za>


Valerie Lambert added the comment:

Of course, here is the patch without the '--git' option.

----------
Added file: http://bugs.python.org/file31442/issue-18623_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18623>
_______________________________________

From report at bugs.python.org  Fri Aug 23 18:41:32 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 23 Aug 2013 16:41:32 +0000
Subject: [issue18767] csv documentation does not note default quote constant
In-Reply-To: <1376706253.43.0.482794872786.issue18767@psf.upfronthosting.co.za>
Message-ID: <1377276092.3.0.520550092438.issue18767@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18767>
_______________________________________

From report at bugs.python.org  Fri Aug 23 18:42:34 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 23 Aug 2013 16:42:34 +0000
Subject: [issue18769] argparse remove subparser
In-Reply-To: <1376757040.66.0.700111900917.issue18769@psf.upfronthosting.co.za>
Message-ID: <1377276154.24.0.0736241333898.issue18769@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18769>
_______________________________________

From report at bugs.python.org  Fri Aug 23 18:45:43 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 23 Aug 2013 16:45:43 +0000
Subject: [issue18783] No more refer to Python "long"
In-Reply-To: <1376933723.97.0.818285065385.issue18783@psf.upfronthosting.co.za>
Message-ID: <1377276343.96.0.678877295335.issue18783@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18783>
_______________________________________

From report at bugs.python.org  Fri Aug 23 18:54:10 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 23 Aug 2013 16:54:10 +0000
Subject: [issue18804] pythorun.c: is_valid_fd() should not duplicate the file
 descriptor
In-Reply-To: <1377126467.82.0.012503473328.issue18804@psf.upfronthosting.co.za>
Message-ID: <1377276850.08.0.240794466924.issue18804@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18804>
_______________________________________

From report at bugs.python.org  Fri Aug 23 18:56:15 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 23 Aug 2013 16:56:15 +0000
Subject: [issue18760] Fix internal doc references for the xml package
In-Reply-To: <1376681899.06.0.47911099673.issue18760@psf.upfronthosting.co.za>
Message-ID: <1377276975.19.0.00138746965952.issue18760@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18760>
_______________________________________

From report at bugs.python.org  Fri Aug 23 19:15:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 17:15:44 +0000
Subject: [issue5876] __repr__ returning unicode doesn't work when called
 implicitly
In-Reply-To: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za>
Message-ID: <1377278144.2.0.0962785313145.issue5876@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

How it can break backward compatibility? Currently repr() just raises UnicodeEncodeError.

UnicodeEncodeError: 'ascii' codec can't encode character u'\u20ac' in position 0: ordinal not in range(128)

With patch it always returns 8-bit string. As far as repr() usually used for debugging the second alternative looks more helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5876>
_______________________________________

From report at bugs.python.org  Fri Aug 23 19:22:54 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 17:22:54 +0000
Subject: [issue5876] __repr__ returning unicode doesn't work when called
 implicitly
In-Reply-To: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za>
Message-ID: <1377278574.82.0.556193863806.issue5876@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> How it can break backward compatibility? Currently repr() just raises UnicodeEncodeError.

It depends on sys.getdefaultencoding() which can be modified in the site module (or in a PYTHONSTARTUP script) using sys.setdefaultencoding(). It should not possible to change the default encoding, and it was fixed in Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5876>
_______________________________________

From report at bugs.python.org  Fri Aug 23 19:24:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Aug 2013 17:24:48 +0000
Subject: [issue17702] os.environ converts key type from string to bytes in
 KeyError exception
In-Reply-To: <1365726971.44.0.005141093776.issue17702@psf.upfronthosting.co.za>
Message-ID: <3cM8cc1XByz7Lkh@mail.python.org>


Roundup Robot added the comment:

New changeset 26c049dc1a4a by Victor Stinner in branch '3.3':
Close #17702: On error, os.environb now removes suppress the except context
http://hg.python.org/cpython/rev/26c049dc1a4a

New changeset 01f33959ddf6 by Victor Stinner in branch 'default':
(Merge 3.3) Close #17702: On error, os.environb now removes suppress the except
http://hg.python.org/cpython/rev/01f33959ddf6

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17702>
_______________________________________

From report at bugs.python.org  Fri Aug 23 19:27:48 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 17:27:48 +0000
Subject: [issue17702] os.environ converts key type from string to bytes in
 KeyError exception
In-Reply-To: <1365726971.44.0.005141093776.issue17702@psf.upfronthosting.co.za>
Message-ID: <1377278868.81.0.153827011212.issue17702@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> This patch introduces a bit ugly traceback.

It is now fixed, thanks for the report!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17702>
_______________________________________

From report at bugs.python.org  Fri Aug 23 19:30:39 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Aug 2013 17:30:39 +0000
Subject: [issue18586] Allow running benchmarks for Python 3 from same directory
In-Reply-To: <1375112281.72.0.724142875294.issue18586@psf.upfronthosting.co.za>
Message-ID: <3cM8lM0ncnz7LjX@mail.python.org>


Roundup Robot added the comment:

New changeset b868d0a9c5d7 by Brett Cannon in branch 'default':
Issue #18586: Remove the need for make_perf3.sh
http://hg.python.org/benchmarks/rev/b868d0a9c5d7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18586>
_______________________________________

From report at bugs.python.org  Fri Aug 23 19:34:08 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Aug 2013 17:34:08 +0000
Subject: [issue18586] Allow running benchmarks for Python 3 from same directory
In-Reply-To: <1375112281.72.0.724142875294.issue18586@psf.upfronthosting.co.za>
Message-ID: <1377279248.65.0.406379386992.issue18586@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18586>
_______________________________________

From report at bugs.python.org  Fri Aug 23 19:38:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Aug 2013 17:38:48 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <3cM8wl4NNZz7Ljw@mail.python.org>


Roundup Robot added the comment:

New changeset 79007c4244d6 by Barry Warsaw in branch '2.6':
- Issue #18709: Fix CVE-2013-4238. The SSL module now handles NULL bytes
http://hg.python.org/cpython/rev/79007c4244d6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Fri Aug 23 19:42:50 2013
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 23 Aug 2013 17:42:50 +0000
Subject: [issue5876] __repr__ returning unicode doesn't work when called
 implicitly
In-Reply-To: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za>
Message-ID: <1377279770.94.0.064615298015.issue5876@psf.upfronthosting.co.za>


Armin Rigo added the comment:

@Serhiy: it would certainly break a program that tries to call the repr() and catches the UnicodeEncodeError to do something else, like encode the data differently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5876>
_______________________________________

From report at bugs.python.org  Fri Aug 23 19:46:27 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Aug 2013 17:46:27 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1376691835.07.0.666456900735.issue18763@psf.upfronthosting.co.za>
Message-ID: <1377279987.28.0.18588065705.issue18763@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Here's a patch with a more robust test: the previous test worked, but assume that only stdin, stdout and stderr FDs would be open in the child process. This might not hold anymore in a near future (/dev/urandom persistent FD).
The new test is much more robust.

----------
stage: patch review -> commit review
Added file: http://bugs.python.org/file31443/subprocess_close-default-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Fri Aug 23 19:57:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 17:57:32 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1376691835.07.0.666456900735.issue18763@psf.upfronthosting.co.za>
Message-ID: <1377280652.46.0.477643198579.issue18763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I don't understand why os.dup2() is more reliable than os.pipe() for a unit test?

Is subprocess_close-default-1.diff portable? test_os uses hasattr(os, "dup2"). In Modules/posixmodule.c, it looks like the function is always defined!?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Fri Aug 23 20:11:46 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 23 Aug 2013 18:11:46 +0000
Subject: [issue17213] ctypes loads wrong version of C runtime,
 leading to error message box from system
In-Reply-To: <1360992800.86.0.617349310494.issue17213@psf.upfronthosting.co.za>
Message-ID: <1377281506.85.0.175768112676.issue17213@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17213>
_______________________________________

From report at bugs.python.org  Fri Aug 23 20:15:07 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 23 Aug 2013 18:15:07 +0000
Subject: [issue5876] __repr__ returning unicode doesn't work when called
 implicitly
In-Reply-To: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za>
Message-ID: <1377281707.71.0.469052204658.issue5876@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

.__repr__() is not really allowed to return Unicode objects in Python 2.x. If you do this, you're on your own. The CPython internals try to convert any non-str object to a str object, but this is only done to assure that PyObject_Repr() always returns a str object.

I'd suggest closing this as won't fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5876>
_______________________________________

From report at bugs.python.org  Fri Aug 23 20:28:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 18:28:43 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1377282523.54.0.818838841709.issue18772@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Attached patch solves the issue and removes the repr()-based hack in the gdb plugin.

----------
Added file: http://bugs.python.org/file31444/gdb_sets_repr2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Fri Aug 23 20:29:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 18:29:59 +0000
Subject: [issue18822] poor proxyval() coverage in test_gdb
Message-ID: <1377282599.12.0.212974297013.issue18822@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The proxyval() of many built-in types doesn't seem covered by test_gdb, as write_repr() is specialized for most of them.

(check: add "1/0" to one of those proxyval() implementations and watch test_gdb succeed)

----------
components: Tests
messages: 195998
nosy: dmalcolm, pitrou
priority: normal
severity: normal
status: open
title: poor proxyval() coverage in test_gdb
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18822>
_______________________________________

From report at bugs.python.org  Fri Aug 23 20:35:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 18:35:11 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377282911.62.0.863649607485.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch for 3.3/3.4.

----------
keywords: +patch
stage: needs patch -> patch review
versions:  -Python 2.7
Added file: http://bugs.python.org/file31445/subinterp_threads.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Fri Aug 23 20:48:54 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Aug 2013 18:48:54 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1377280652.46.0.477643198579.issue18763@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0x+uNot8jE6uNU8djX70rs=L0pQX0Q6NWN6cZCcrjagw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> I don't understand why os.dup2() is more reliable than os.pipe() for a unit
> test?

I use dup2() because it allows me to specify a target FD, so the
parent can know precisely which FD was opened by the preexec hook, and
check it's closed in the child process. With pipe(), the FDs returned
are arbitrary, so the parent can't check them explicitly, and has to
check that no FD > 2 is open in the child, which is fragile.

> Is subprocess_close-default-1.diff portable? test_os uses hasattr(os,
> "dup2"). In Modules/posixmodule.c, it looks like the function is always
> defined!?

Maybe it's not available on Windows, but it's definitely available on Unix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Fri Aug 23 20:54:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 18:54:32 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1376691835.07.0.666456900735.issue18763@psf.upfronthosting.co.za>
Message-ID: <1377284072.25.0.977546042307.issue18763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"the parent can know precisely which FD was opened by
the preexec hook, and check it's closed in the child process."

Oh ok, I see:

+        self.assertNotIn(fd, remaining_fds)

You might also add a check:

        self.assertLessEqual(remaining_fds, {0, 1, 2})

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Fri Aug 23 20:57:37 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 18:57:37 +0000
Subject: [issue11619] On Windows,
 don't encode filenames in the import machinery
In-Reply-To: <1300665531.85.0.426527059221.issue11619@psf.upfronthosting.co.za>
Message-ID: <1377284257.0.0.413203328059.issue11619@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reopen the issue because some users are now requesting this feature.

I updated  parser_unicode.patch to the last Python version. The new patch has just a minor nit: test_symtable does crash :-D

I will investigate the crash later.

----------
resolution: wont fix -> 
status: closed -> open
Added file: http://bugs.python.org/file31446/parser_unicode-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11619>
_______________________________________

From report at bugs.python.org  Fri Aug 23 20:57:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 18:57:45 +0000
Subject: [issue5876] __repr__ returning unicode doesn't work when called
 implicitly
In-Reply-To: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za>
Message-ID: <1377284265.09.0.999756791224.issue5876@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I'd suggest closing this as won't fix.

Agreed, it's time to upgrade to Python 3!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5876>
_______________________________________

From report at bugs.python.org  Fri Aug 23 20:58:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 18:58:45 +0000
Subject: [issue18776] atexit error display behavior changed in python 3
In-Reply-To: <1376867279.76.0.423082412526.issue18776@psf.upfronthosting.co.za>
Message-ID: <1377284325.79.0.443386793338.issue18776@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18776>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:00:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Aug 2013 19:00:15 +0000
Subject: [issue18760] Fix internal doc references for the xml package
In-Reply-To: <1376681899.06.0.47911099673.issue18760@psf.upfronthosting.co.za>
Message-ID: <1377284415.18.0.855559154071.issue18760@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Serhiy, you forgot to attach the patch.

----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18760>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:01:42 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Aug 2013 19:01:42 +0000
Subject: [issue18774] There is still last bit of GNU Pth code in signalmodule.c
In-Reply-To: <1376801880.96.0.197365143686.issue18774@psf.upfronthosting.co.za>
Message-ID: <1377284502.69.0.794751356946.issue18774@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
Removed message: http://bugs.python.org/msg195643

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18774>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:02:03 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 19:02:03 +0000
Subject: [issue13758] compile() should not encode 'filename' (at least on
 Windows)
In-Reply-To: <1326253604.11.0.305060780894.issue13758@psf.upfronthosting.co.za>
Message-ID: <1377284523.74.0.339608368388.issue13758@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Victor, do you have any opinion on this unicode filename issue?

I closed the issue #11619 in january 2013 before there was no user requesting the feature. I just reopened the issue because users now ask for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13758>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:08:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 19:08:10 +0000
Subject: [issue17618] base85 encoding
In-Reply-To: <1364909015.82.0.0760723886219.issue17618@psf.upfronthosting.co.za>
Message-ID: <1377284890.3.0.926981049225.issue17618@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Serhiy, Martin, is one of you still working on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17618>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:11:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 19:11:14 +0000
Subject: [issue18818] Empty PYTHONIOENCODING is not the same as nonexistent
In-Reply-To: <1377240348.58.0.0824436318174.issue18818@psf.upfronthosting.co.za>
Message-ID: <1377285074.14.0.765937341415.issue18818@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch with tests and documentation. For the documentation I hope on your help.

----------
Added file: http://bugs.python.org/file31447/empty_pythonioencoding_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18818>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:12:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 19:12:23 +0000
Subject: [issue5876] __repr__ returning unicode doesn't work when called
 implicitly
In-Reply-To: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za>
Message-ID: <1377285143.64.0.650622578265.issue5876@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> It depends on sys.getdefaultencoding() which can be modified in the site module (or in a PYTHONSTARTUP script) using sys.setdefaultencoding().

Of course. Every successful without patch repr() will left same with patch. However the patch allows you to see objects which were not repr-able before. repr() itself is used in the formatting of error messages, so it is desirable extend its aplicability as far as possible.

> @Serhiy: it would certainly break a program that tries to call the repr() and catches the UnicodeEncodeError to do something else, like encode the data differently.

Why it would break? You want encode the data differently.only due non-working repr(), however with proposed patch this will be just not needed.

> .__repr__() is not really allowed to return Unicode objects in Python 2.x. If you do this, you're on your own.

PyObject_Repr() contains a code which converts unicode to str and raise an exception if __repr__() result is not str or unicode. Unicode __repr__() is expected even if it is not recommended.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5876>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:14:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 19:14:04 +0000
Subject: [issue18817] Got resource warning when running Lib/aifc.py
In-Reply-To: <1377234795.91.0.783821607183.issue18817@psf.upfronthosting.co.za>
Message-ID: <1377285244.54.0.569877047002.issue18817@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18817>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:14:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 19:14:28 +0000
Subject: [issue18817] Got resource warning when running Lib/aifc.py
In-Reply-To: <1377234795.91.0.783821607183.issue18817@psf.upfronthosting.co.za>
Message-ID: <1377285268.05.0.974945662424.issue18817@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18817>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:15:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Aug 2013 19:15:57 +0000
Subject: [issue18394] cgi.FieldStorage triggers ResourceWarning sometimes
In-Reply-To: <1373190601.25.0.575768158618.issue18394@psf.upfronthosting.co.za>
Message-ID: <3cMC4r5CFrz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset c0e9ba7b26d5 by Brett Cannon in branch 'default':
Issue #18394: Explicitly close the file object cgi.FieldStorage
http://hg.python.org/cpython/rev/c0e9ba7b26d5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18394>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:17:25 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Aug 2013 19:17:25 +0000
Subject: [issue18394] cgi.FieldStorage triggers ResourceWarning sometimes
In-Reply-To: <1373190601.25.0.575768158618.issue18394@psf.upfronthosting.co.za>
Message-ID: <1377285445.33.0.0387696651449.issue18394@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I managed to write a similar patch to Vajrasky independently, so at least I know the approach is reasonable. =)

I'm not backporting since it really isn't that critical; I fixed it just to turn off the ResourceWarning while running the test suite.

----------
nosy: +brett.cannon
resolution:  -> fixed
status: open -> closed
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18394>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:18:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 19:18:06 +0000
Subject: [issue18760] Fix internal doc references for the xml package
In-Reply-To: <1376681899.06.0.47911099673.issue18760@psf.upfronthosting.co.za>
Message-ID: <1377285486.8.0.0149682398272.issue18760@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry. Can't believe I done it again.

----------
keywords: +patch
Added file: http://bugs.python.org/file31448/refs.xml.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18760>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:20:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 19:20:34 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
 directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1377285634.71.0.626849563073.issue7732@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Seems fixed now.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:21:51 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Aug 2013 19:21:51 +0000
Subject: [issue18757] Fix internal references for concurrent modules
In-Reply-To: <1376675015.24.0.101209198038.issue18757@psf.upfronthosting.co.za>
Message-ID: <1377285711.93.0.844123234667.issue18757@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

LGTM.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18757>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:22:34 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Aug 2013 19:22:34 +0000
Subject: [issue18795] pstats - allow stats sorting by cumulative time per call
 and total time per call
In-Reply-To: <1377042491.98.0.765142916486.issue18795@psf.upfronthosting.co.za>
Message-ID: <1377285754.72.0.0244125276731.issue18795@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +georg.brandl
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18795>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:22:50 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 23 Aug 2013 19:22:50 +0000
Subject: [issue5876] __repr__ returning unicode doesn't work when called
 implicitly
In-Reply-To: <1377285143.64.0.650622578265.issue5876@psf.upfronthosting.co.za>
Message-ID: <5217B67F.8090806@egenix.com>


Marc-Andre Lemburg added the comment:

Serhiy Storchaka wrote:
>> .__repr__() is not really allowed to return Unicode objects in Python 2.x. If you do this, you're on your own.
> 
> PyObject_Repr() contains a code which converts unicode to str and raise an exception if __repr__() result is not str or unicode. Unicode __repr__() is expected even if it is not recommended.

True, but the code is not intended to support non-ASCII Unicode,
otherwise we would have taken care to introduce support for this
much earlier in the 2.x series.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5876>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:41:58 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Aug 2013 19:41:58 +0000
Subject: [issue18796] Wrong documentation of show_code function from dis module
In-Reply-To: <1377053819.02.0.986969704551.issue18796@psf.upfronthosting.co.za>
Message-ID: <3cMCfs3YRBz7Ll9@mail.python.org>


Roundup Robot added the comment:

New changeset 64678369c4d0 by Ezio Melotti in branch 'default':
#18796: improve documentation of the file argument of dis.show_code.  Initial patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/64678369c4d0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18796>
_______________________________________

From report at bugs.python.org  Fri Aug 23 21:43:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Aug 2013 19:43:18 +0000
Subject: [issue18796] Wrong documentation of show_code function from dis module
In-Reply-To: <1377053819.02.0.986969704551.issue18796@psf.upfronthosting.co.za>
Message-ID: <1377286998.65.0.431946492194.issue18796@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18796>
_______________________________________

From report at bugs.python.org  Fri Aug 23 22:04:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 20:04:28 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1377288268.92.0.821626506357.issue18756@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, you're gonna laugh, the simplified patch has a complication (not theoretical, it would trip test_cmd_line). Attaching patch.

----------
Added file: http://bugs.python.org/file31449/persistent_urandom_fd4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Aug 23 22:06:18 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 23 Aug 2013 20:06:18 +0000
Subject: [issue18810] Stop doing stat calls in importlib.machinery.FileFinder
 to see if something is a file or folder
In-Reply-To: <1377182986.55.0.892405433608.issue18810@psf.upfronthosting.co.za>
Message-ID: <1377288378.13.0.248361186166.issue18810@psf.upfronthosting.co.za>


Eric Snow added the comment:

Isn't this related somewhat to #7732?

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18810>
_______________________________________

From report at bugs.python.org  Fri Aug 23 22:09:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Aug 2013 20:09:53 +0000
Subject: [issue18798] Typo and unused variables in test fcntl
In-Reply-To: <1377080960.53.0.565624911125.issue18798@psf.upfronthosting.co.za>
Message-ID: <3cMDH465GHz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset d7bac470951b by Ezio Melotti in branch '2.7':
#18798: fix typo in test_fcntl.  Patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/d7bac470951b

New changeset 41c90b8f49d9 by Ezio Melotti in branch '3.3':
#18798: fix typo in test_fcntl.  Patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/41c90b8f49d9

New changeset 0f8f5fd6e712 by Ezio Melotti in branch 'default':
#18798: merge typo fix from 3.3 and also use two unused variables.
http://hg.python.org/cpython/rev/0f8f5fd6e712

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18798>
_______________________________________

From report at bugs.python.org  Fri Aug 23 22:10:23 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Aug 2013 20:10:23 +0000
Subject: [issue18798] Typo and unused variables in test fcntl
In-Reply-To: <1377080960.53.0.565624911125.issue18798@psf.upfronthosting.co.za>
Message-ID: <1377288623.45.0.468570488017.issue18798@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18798>
_______________________________________

From report at bugs.python.org  Fri Aug 23 22:12:53 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Aug 2013 20:12:53 +0000
Subject: [issue18799] Resurrect and fix test_404 in Lib/test/test_xmlrpc.py
In-Reply-To: <1377100643.52.0.970396135479.issue18799@psf.upfronthosting.co.za>
Message-ID: <1377288773.7.0.557286259245.issue18799@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

We can always try to apply the patch and see what happens -- if the test starts failing again we can revert it.

----------
nosy: +ezio.melotti
stage:  -> patch review
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18799>
_______________________________________

From report at bugs.python.org  Fri Aug 23 22:13:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Aug 2013 20:13:29 +0000
Subject: [issue18800] Document Fraction's numerator and denominator properties
In-Reply-To: <1377104746.66.0.571132107535.issue18800@psf.upfronthosting.co.za>
Message-ID: <1377288809.52.0.12188701588.issue18800@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18800>
_______________________________________

From report at bugs.python.org  Fri Aug 23 22:28:02 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Aug 2013 20:28:02 +0000
Subject: [issue18803] Fix more typos in .py files
In-Reply-To: <1377119764.79.0.128935070292.issue18803@psf.upfronthosting.co.za>
Message-ID: <1377289682.48.0.931750749286.issue18803@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18803>
_______________________________________

From report at bugs.python.org  Fri Aug 23 22:28:58 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Aug 2013 20:28:58 +0000
Subject: [issue18814] Add tools for "cleaning" surrogate escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1377289738.26.0.12334038774.issue18814@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Fri Aug 23 22:32:50 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Aug 2013 20:32:50 +0000
Subject: [issue18820] json.dump() ignores its 'default' option when
 serializing dictionary keys
In-Reply-To: <1377253830.03.0.463497944995.issue18820@psf.upfronthosting.co.za>
Message-ID: <1377289970.04.0.288016870567.issue18820@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Are there already tests that cover the changes in your patch?  If not, could you add them?

----------
nosy: +ezio.melotti, pitrou, rhettinger
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18820>
_______________________________________

From report at bugs.python.org  Fri Aug 23 22:33:13 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Aug 2013 20:33:13 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1377284072.25.0.977546042307.issue18763@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1bg3MiKSbczApwiO3hyf0TBs=93VWR4A1YEvZz2XrwCA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> You might also add a check:
>
>         self.assertLessEqual(remaining_fds, {0, 1, 2})

Well no, because the interpreter might have other FDs open than stdin,
stdout and stderr.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Fri Aug 23 22:41:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Aug 2013 20:41:20 +0000
Subject: [issue16123] IDLE - deprecate running without a subprocess
In-Reply-To: <1349302429.82.0.0807471180715.issue16123@psf.upfronthosting.co.za>
Message-ID: <1377290479.99.0.887190501706.issue16123@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Slight correction: While I do not believe I have seen *clipboard* contents pasted, after running a program from the editor that prints (to the shell), I *have* seen the last line reprinted when trying to enter something new as the prompt. This sometimes might look like pasting from the clipboard. I sometimes have to hit enter a couple of times and ignore the SyntaxError to get a clean prompt. I have no idea if this is exclusive to running in a subprocess; it should be fixed independently of this issue.

The idea of using pipes is being explored on Idle-sig.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16123>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:04:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Aug 2013 21:04:44 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <3cMFVM1jdwzMx4@mail.python.org>


Roundup Robot added the comment:

New changeset 815f328a6578 by Antoine Pitrou in branch 'default':
Issue #17741: use composition, rather than inheritance, for xml.etree.iterparse's result class.
http://hg.python.org/cpython/rev/815f328a6578

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:06:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 21:06:08 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377291968.21.0.549230136919.issue17741@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I've committed the inheritance removal patch. I personally don't think there's anything more to do, since the TreeEventBuilder proposal stumbled on some implementation issues.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:10:31 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 23 Aug 2013 21:10:31 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377292231.85.0.0681969698817.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I was asking for the current implementation to be removed until we have a working implementation that hurts neither the API nor the module design.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:11:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 21:11:31 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1377292231.85.0.0681969698817.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377292281.2520.5.camel@fsol>


Antoine Pitrou added the comment:

> I was asking for the current implementation to be removed until we
> have a working implementation that hurts neither the API nor the
> module design.

It would help if we could keep the discussion on rational terms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:18:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Aug 2013 21:18:47 +0000
Subject: [issue18408] Fixes crashes found by pyfailmalloc
In-Reply-To: <1373314243.02.0.649080681154.issue18408@psf.upfronthosting.co.za>
Message-ID: <3cMFpZ5tSRz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset 42aecc601a41 by Antoine Pitrou in branch 'default':
Back out 5bd9db528aed (issue #18408).  It caused unsolved buildbot failures.
http://hg.python.org/cpython/rev/42aecc601a41

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18408>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:19:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 21:19:33 +0000
Subject: [issue18408] Fixes crashes found by pyfailmalloc
In-Reply-To: <1373314243.02.0.649080681154.issue18408@psf.upfronthosting.co.za>
Message-ID: <1377292773.76.0.218485294753.issue18408@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Victor, I'll let you find out how to improve your debug checks, but in the meantime I've reverted the commit that randomly broke some Windows buildbots.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18408>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:20:17 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 23 Aug 2013 21:20:17 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377292817.74.0.726429806158.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I don't think I understand what you mean.

In any case, it's not to late to remove the implementation. There was only one alpha release so far that included it, so it can't really break any existing code that relies on it. The longer we wait, the more damage will be done. That's why I am asking for removal now.

I would prefer not to rush in a replacement. The current state shows where that brings us. So, I request the removal of the current code, then we can calmly come up with a good implementation of the feature in question. If that can't be done for 3.4, well, then we have at least avoided adding something that will need to be deprecated and replaced later on. If it can be done for 3.4, the better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:21:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 21:21:19 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1377292817.74.0.726429806158.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377292871.2520.6.camel@fsol>


Antoine Pitrou added the comment:

> In any case, it's not to late to remove the implementation.

As far as I can say, there's no reason to remove the implementation
except for your distaste of the method names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:23:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 21:23:59 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377293039.41.0.0781764705125.issue17741@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

To wrap things up:
- the feature is desireable
- the API is reasonable
- the implementation is functional and properly tested

Really, if you can't come up with an actual blocker, I'll ask you to leave this issue at rest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:28:31 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Aug 2013 21:28:31 +0000
Subject: [issue18783] No more refer to Python "long"
In-Reply-To: <1376933723.97.0.818285065385.issue18783@psf.upfronthosting.co.za>
Message-ID: <1377293311.18.0.0666261658977.issue18783@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

For msilib, 'int numbers' should just be 'ints' or 'integers'.
---
For PC/winreg.c '''\
PyDoc_STRVAR(PyHKEY_Detach_doc,
"key.Detach() -> int\n"
...
"On 64 bit windows, the result of this function is a long integer");'''

This last line should be deleted rather than modified, as its only point is to override the signature declaration of returning int.
---
I cannot vouch for this change:
-/* necessary to make sure types aren't coerced (e.g., int and long) */
+/* necessary to make sure types aren't coerced (e.g., float and complex) */
I presume you thought about it carefully in context.
---
The rest of the changes look grammatically correct. I cannot be sure about the executable code changes.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18783>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:28:39 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 23 Aug 2013 21:28:39 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377293319.3.0.297773094999.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Could we please keep the discussion on rational terms?

It's not just the method names. The problem is that you are duplicating an existing class (the XMLParser) for no good reason, instead of putting the feature where it belongs: *behind* the XMLParser. Even worse, you are duplicating the class and giving it a *different* API.

This goes completely against the design of the existing API and counters the reusability of the existing code.

I'm not questioning that the feature is desirable. I'm saying that the design is wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:37:12 2013
From: report at bugs.python.org (July Tikhonov)
Date: Fri, 23 Aug 2013 21:37:12 +0000
Subject: [issue18820] json.dump() ignores its 'default' option when
 serializing dictionary keys
In-Reply-To: <1377253830.03.0.463497944995.issue18820@psf.upfronthosting.co.za>
Message-ID: <1377293832.73.0.174419115773.issue18820@psf.upfronthosting.co.za>


July Tikhonov added the comment:

Proposed tests attached.

----------
Added file: http://bugs.python.org/file31450/json-default-tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18820>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:39:08 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Aug 2013 21:39:08 +0000
Subject: [issue18803] Fix more typos in .py files
In-Reply-To: <1377119764.79.0.128935070292.issue18803@psf.upfronthosting.co.za>
Message-ID: <1377293948.29.0.0552522337387.issue18803@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Incorrect fixes.
accidentaly -> accidentally
occurence -> occurrence

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18803>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:45:22 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Aug 2013 21:45:22 +0000
Subject: [issue18757] Fix internal references for concurrent modules
In-Reply-To: <1376675015.24.0.101209198038.issue18757@psf.upfronthosting.co.za>
Message-ID: <3cMGPF6fBDz7Ljs@mail.python.org>


Roundup Robot added the comment:

New changeset 6575074aae1c by Serhiy Storchaka in branch '3.3':
Issue #18757: Improved cross-references in the concurrent package.
http://hg.python.org/cpython/rev/6575074aae1c

New changeset 383d85249997 by Serhiy Storchaka in branch 'default':
Issue #18757: Improved cross-references in the concurrent package.
http://hg.python.org/cpython/rev/383d85249997

New changeset c24941251473 by Serhiy Storchaka in branch '2.7':
Issue #18757: Improved cross-references in the concurrent package.
http://hg.python.org/cpython/rev/c24941251473

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18757>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:49:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 21:49:02 +0000
Subject: [issue18757] Fix internal references for concurrent modules
In-Reply-To: <1376675015.24.0.101209198038.issue18757@psf.upfronthosting.co.za>
Message-ID: <1377294542.24.0.0326577156035.issue18757@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for the review Ezio.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18757>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:51:09 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 21:51:09 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <CAH_1eM1bg3MiKSbczApwiO3hyf0TBs=93VWR4A1YEvZz2XrwCA@mail.gmail.com>
Message-ID: <CAMpsgwZVZ015MtYzNB2dN-X2z--oVqOqdmrghxKmMB-_Hcb8_g@mail.gmail.com>


STINNER Victor added the comment:

Close_fds is not supposed to close them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:54:02 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 21:54:02 +0000
Subject: [issue18408] Fixes crashes found by pyfailmalloc
In-Reply-To: <1377292773.76.0.218485294753.issue18408@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbVZw5c99Zz-oXkzybxsiJ+3WaPCzpcFLdjs3fyfr8VvQ@mail.gmail.com>


STINNER Victor added the comment:

I didn't know that buildbots are failing. Do you have at least an example?
An error message, anything?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18408>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:55:13 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 21:55:13 +0000
Subject: [issue18408] Fixes crashes found by pyfailmalloc
In-Reply-To: <1373314243.02.0.649080681154.issue18408@psf.upfronthosting.co.za>
Message-ID: <1377294913.05.0.915732039245.issue18408@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

It's reported in issue18664 (you're nosied there :-)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18408>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:58:38 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Aug 2013 21:58:38 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <CAMpsgwZVZ015MtYzNB2dN-X2z--oVqOqdmrghxKmMB-_Hcb8_g@mail.gmail.com>
Message-ID: <CAH_1eM1DmHEwhzhJRtsr7zWGhQGAXgAWSiN-y9-mQrue3r1xeA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Close_fds is not supposed to close them?

Yes, but some new fds might be open in the child process, e.g. for /dev/urandom.
That's why it's better to check that this precise FD is closed. Of
course, if the /dev/urandom FD gets assigned the same FD as the one
provided by dup() in the parent, we're screwed, but that shouldn't
happen (since /dev/urandom is already open in the parent).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:58:49 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Aug 2013 21:58:49 +0000
Subject: [issue18810] Stop doing stat calls in importlib.machinery.FileFinder
 to see if something is a file or folder
In-Reply-To: <1377182986.55.0.892405433608.issue18810@psf.upfronthosting.co.za>
Message-ID: <1377295129.6.0.557696144384.issue18810@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I did a quick check and at least stripping out the two stat calls for a directory or module file (left in package __init__.py) didn't make a significant difference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18810>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:59:12 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Aug 2013 21:59:12 +0000
Subject: [issue18810] Stop doing stat calls in importlib.machinery.FileFinder
 to see if something is a file or folder
In-Reply-To: <1377182986.55.0.892405433608.issue18810@psf.upfronthosting.co.za>
Message-ID: <1377295152.68.0.37194617091.issue18810@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I don't think it's related to the test_imp bug, but since it was never fully diagnosed I couldn't tell you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18810>
_______________________________________

From report at bugs.python.org  Fri Aug 23 23:59:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 21:59:34 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1377293319.3.0.297773094999.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377295166.2520.32.camel@fsol>


Antoine Pitrou added the comment:

> The problem is that you are duplicating an existing class (the
> XMLParser) for no good reason

No. The logic was already in _IterParseIterator, just wrapped up
differently.

And the proof is that the original commit, while adding a feature,
*removed* code from xml.etree:

$ hg di -c f903cf864191 --stat Lib/xml/etree/
 Lib/xml/etree/ElementTree.py |  209
+++++++++++++++++++++++++++++---------------------------------
 1 files changed, 97 insertions(+), 112 deletions(-)

> This goes completely against the design of the existing API and
> counters the reusability of the existing code.

No it doesn't. It irritates you, for some reason, but your feelings are
not a valid reason to revert a useful feature. And this issue is not for
you to repeat the same stubborn line of argument again and again. I'm
extremely bored, and I won't care about your comments anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sat Aug 24 00:00:03 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 22:00:03 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377295203.49.0.640979446038.issue17741@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sat Aug 24 00:02:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 22:02:00 +0000
Subject: [issue18814] Add tools for "cleaning" surrogate escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1377295320.09.0.698517983989.issue18814@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Can you sum the use cases for these?
(don't want to read a blog post, sorry :-))

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Sat Aug 24 00:02:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 22:02:35 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1376691835.07.0.666456900735.issue18763@psf.upfronthosting.co.za>
Message-ID: <1377295355.11.0.322904557118.issue18763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Yes, but some new fds might be open in the child process, e.g. for /dev/urandom.

The issue #18756 is not implemented not, and I'm still opposed to change os.random() to use persistent FD :)

Ok, no problem for not checking others FD, it's not the purpose of the test anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Sat Aug 24 00:06:39 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 22:06:39 +0000
Subject: [issue18814] Add tools for "cleaning" surrogate escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1377295599.71.0.253344841521.issue18814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"The email package needs has_escaped_bytes.  Currently it tries to encode to ascii to find out if there are any, which we proved by microbenchmark is the fastest way to do it as things stand."

In which function you need to check this? What do you do if there are surrogate characters?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Sat Aug 24 00:17:50 2013
From: report at bugs.python.org (Zooko Wilcox-O'Hearn)
Date: Fri, 23 Aug 2013 22:17:50 +0000
Subject: [issue5720] ctime: I don't think that word means what you think it
 means.
In-Reply-To: <1239141469.77.0.706973197517.issue5720@psf.upfronthosting.co.za>
Message-ID: <1377296270.35.0.461207615109.issue5720@psf.upfronthosting.co.za>


Zooko Wilcox-O'Hearn added the comment:

Well, read the thread! http://mail.python.org/pipermail/python-dev/2009-June/090021.html

Basically just a couple of +1's, and a good suggestion to name it something clearer than "crtime". 


Please fix it!

----------
nosy: +Zooko.Wilcox-O'Hearn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5720>
_______________________________________

From report at bugs.python.org  Sat Aug 24 00:37:14 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Aug 2013 22:37:14 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <20130822163824.1f1dce55@anarchist>
Message-ID: <CAMpsgwaKx=KFt4tmHuvVK-Jyu=xuW67kj0YVJ3R70ZxYRSjQMQ@mail.gmail.com>


STINNER Victor added the comment:

Oh i forgot that i wrote a patch for openssl:
https://bitbucket.org/haypo/hasard/src/tip/patches/openssl_rand_fork.patch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Sat Aug 24 00:40:25 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 23 Aug 2013 22:40:25 +0000
Subject: [issue5720] ctime: I don't think that word means what you think it
 means.
In-Reply-To: <1239141469.77.0.706973197517.issue5720@psf.upfronthosting.co.za>
Message-ID: <1377297625.15.0.886360463327.issue5720@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I don't think we should hijack st_ctime. All the other members of the stat object correspond exactly to what you get back from the Unix stat() call. Let's not break that. How about just leaving st_ctime as it is and adding st_creationtime, which will have the nicer semantics?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5720>
_______________________________________

From report at bugs.python.org  Sat Aug 24 01:01:47 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 23 Aug 2013 23:01:47 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377298907.84.0.743703735234.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Given that it seems to be hard to come to a consensus in this ticket, I've asked for removal of the code on python-dev.

http://mail.python.org/pipermail/python-dev/2013-August/128095.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sat Aug 24 01:28:45 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Aug 2013 23:28:45 +0000
Subject: [issue18814] Add tools for "cleaning" surrogate escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1377300525.79.0.381495580574.issue18814@psf.upfronthosting.co.za>


R. David Murray added the comment:

The email package uses surrogateescape to store unknown bytes in unicode strings, just as with the handle-bad-data-from-os API surrogateescape was introduced for.  (For the same reason: the source data may have improperly encoded bytes that we must nevertheless preserve).  What action certain parts of the code takes differs depending on whether or not there are such encoded bytes in the string.  So the code needs to check and branch based on that.

The utility function is email.utils._has_surrogates.  You can grep the email source to see where it is used, if you like.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Sat Aug 24 01:35:04 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Aug 2013 23:35:04 +0000
Subject: [issue18823] Idle: use pipes instead of sockets to talk with user
 subprocess
Message-ID: <1377300904.13.0.124289838176.issue18823@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Idle once used os.spawnv to open the user subprocess and 2.7 still does. Sockets were then used to interact with the subprocess. Since rev71746, 2011-8-3, 3.2+ use subprocess.Popen but still use sockets. A rare but continual problem is failure to make the socket connection.

In #16123, Amaury Forgeot d'Arc suggested "pipes?" The idea resurfaced again in current Idle-sig thread "Idle does not open on mac" (because socket connection timed out). Guido, who designed the current 2.x system, chimed in with "I would recommend trying to use the subprocess module."

A current python-list thread indicates that there can be problems with
"Running a command line program and reading the result as it runs"
http://mail.python.org/pipermail/python-list/2013-August/654265.html

In particular, "for line in p:" gets lines delayed (buffered) while
Peter Otten discovered that "for line in iter(p.stdout.readline, ''):" gets them as they are produced.
http://mail.python.org/pipermail/python-list/2013-August/654330.html

We first need to experiment running a simple echo server with python(w).exe.  I have not succeeded yet on Windows.

----------
components: IDLE
messages: 196055
nosy: roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: Idle: use pipes instead of sockets to talk with user subprocess
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18823>
_______________________________________

From report at bugs.python.org  Sat Aug 24 01:35:24 2013
From: report at bugs.python.org (Zooko Wilcox-O'Hearn)
Date: Fri, 23 Aug 2013 23:35:24 +0000
Subject: [issue5720] ctime: I don't think that word means what you think it
 means.
In-Reply-To: <1239141469.77.0.706973197517.issue5720@psf.upfronthosting.co.za>
Message-ID: <1377300924.78.0.701784913111.issue5720@psf.upfronthosting.co.za>


Zooko Wilcox-O'Hearn added the comment:

Benjamin Peterson: what do you mean "hijack ctime"? I don't think I ? or anyone ? has proposed anything that fits that description. Please be more specific.  My proposal in http://bugs.python.org/issue5720#msg85750 does not break anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5720>
_______________________________________

From report at bugs.python.org  Sat Aug 24 01:37:42 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Aug 2013 23:37:42 +0000
Subject: [issue16123] IDLE - deprecate running without a subprocess
In-Reply-To: <1349302429.82.0.0807471180715.issue16123@psf.upfronthosting.co.za>
Message-ID: <1377301062.4.0.131231974028.issue16123@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I opened #18823 "Idle: use pipes instead of sockets to talk with user subprocess" I think this or a socket fix is needed before we remove -n.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16123>
_______________________________________

From report at bugs.python.org  Sat Aug 24 01:44:56 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 23 Aug 2013 23:44:56 +0000
Subject: [issue5720] ctime: I don't think that word means what you think it
 means.
In-Reply-To: <1239141469.77.0.706973197517.issue5720@psf.upfronthosting.co.za>
Message-ID: <1377301496.68.0.749652173152.issue5720@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Indeed, "hijacking" is a bit strong. I mean filling it with a value that is not in the underlying st_ctime field from stat() call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5720>
_______________________________________

From report at bugs.python.org  Sat Aug 24 01:48:31 2013
From: report at bugs.python.org (Zooko Wilcox-O'Hearn)
Date: Fri, 23 Aug 2013 23:48:31 +0000
Subject: [issue5720] ctime: I don't think that word means what you think it
 means.
In-Reply-To: <1239141469.77.0.706973197517.issue5720@psf.upfronthosting.co.za>
Message-ID: <1377301711.94.0.905825377843.issue5720@psf.upfronthosting.co.za>


Zooko Wilcox-O'Hearn added the comment:

Benjamin: I'm sorry, I still don't understand. Do you think my proposal would involve setting something named "ctime" to contain a value that didn't come from the underlying stat "ctime"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5720>
_______________________________________

From report at bugs.python.org  Sat Aug 24 01:52:03 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 23 Aug 2013 23:52:03 +0000
Subject: [issue5720] ctime: I don't think that word means what you think it
 means.
In-Reply-To: <1239141469.77.0.706973197517.issue5720@psf.upfronthosting.co.za>
Message-ID: <1377301923.97.0.278132034463.issue5720@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

You're quite right. I stupidly misread "crtime" as "ctime".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5720>
_______________________________________

From report at bugs.python.org  Sat Aug 24 01:55:49 2013
From: report at bugs.python.org (Zooko Wilcox-O'Hearn)
Date: Fri, 23 Aug 2013 23:55:49 +0000
Subject: [issue5720] ctime: I don't think that word means what you think it
 means.
In-Reply-To: <1239141469.77.0.706973197517.issue5720@psf.upfronthosting.co.za>
Message-ID: <1377302149.26.0.76469156927.issue5720@psf.upfronthosting.co.za>


Zooko Wilcox-O'Hearn added the comment:

Aha! Mystery solved. I wouldn't say that you were stupid ? I would say that "crtime" is way too close to "ctime", and I strongly agree with the suggestion (http://mail.python.org/pipermail/python-dev/2009-June/090026.html) on the mailing list by Greg Ewing that we name the new thing something more obvious.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5720>
_______________________________________

From report at bugs.python.org  Sat Aug 24 02:23:14 2013
From: report at bugs.python.org (Vitaly Murashev)
Date: Sat, 24 Aug 2013 00:23:14 +0000
Subject: [issue18307] Relative path in co_filename for zipped modules
In-Reply-To: <1372256829.94.0.0966099631525.issue18307@psf.upfronthosting.co.za>
Message-ID: <1377303794.68.0.976808437849.issue18307@psf.upfronthosting.co.za>


Vitaly Murashev added the comment:

unit-test attached.
There are 3 tests inside it: 2 failed, 1 succeeded.

According to this test results it becomes clear that specified issue is reproduced only with zip modules which contain precompiled bytecode inside (pyc-files)

----------
Added file: http://bugs.python.org/file31451/test_zipimport_co_filename.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18307>
_______________________________________

From report at bugs.python.org  Sat Aug 24 02:27:00 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Aug 2013 00:27:00 +0000
Subject: [issue18814] Add tools for "cleaning" surrogate escaped strings
In-Reply-To: <1377295320.09.0.698517983989.issue18814@psf.upfronthosting.co.za>
Message-ID: <CADiSq7cRxXz=+8=2Q2iKeJqMZtbs3UpvVUDJ9AwAKcmZ9c7eSA@mail.gmail.com>


Nick Coghlan added the comment:

The use case is to take data from a surrogate escaped interface and either
filter it out entirely or convert it to a valid Unicode string at the point
of *input*, before letting it make its way into the rest of the
application. For example, this approach permits the Python equivalent of
the Linux console behaviour when it attempts to display the improperly
encoded file name.

This approach is likely to be easier to implement in cross-platform code
than dropping down to the bytes interfaces on POSIX systems and using the
Unicode APIs on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Sat Aug 24 03:19:12 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 24 Aug 2013 01:19:12 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377307152.25.0.353024824341.issue18808@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Aug 24 03:43:07 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Aug 2013 01:43:07 +0000
Subject: [issue17883] Fix buildbot testing of Tkinter
In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za>
Message-ID: <1377308587.59.0.378002250995.issue17883@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: ezio.melotti -> terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17883>
_______________________________________

From report at bugs.python.org  Sat Aug 24 08:10:38 2013
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Aug 2013 06:10:38 +0000
Subject: [issue15125] argparse: positional arguments containing - in name not
 handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1377324638.93.0.696366639511.issue15125@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15125>
_______________________________________

From report at bugs.python.org  Sat Aug 24 08:15:12 2013
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Aug 2013 06:15:12 +0000
Subject: [issue17974] Migrate unittest to argparse
In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za>
Message-ID: <1377324912.22.0.679249506173.issue17974@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17974>
_______________________________________

From report at bugs.python.org  Sat Aug 24 08:26:19 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Aug 2013 06:26:19 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377325579.13.0.569670181638.issue17741@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Using tulip-inspired method names (when tulip hasn't landed) to duplicate existing data input functionality (feed() and close()) seems a rather dubious design decision to me.

Given how popular lxml.etree is as an alternative to the standard library's etree implementation, we shouldn't dismiss Stefan's design concerns lightly.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sat Aug 24 08:40:30 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 24 Aug 2013 06:40:30 +0000
Subject: [issue5876] __repr__ returning unicode doesn't work when called
 implicitly
In-Reply-To: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za>
Message-ID: <1377326430.3.0.0375116335269.issue5876@psf.upfronthosting.co.za>


Armin Rigo added the comment:

@Serhiy: it's a behavior change and as such not an option for a micro release.  For example, the following legal code would behave differently: it would compute s = '\\u1234' instead of s = 'UTF8:\xe1\x88\xb4'.

    try:
        s = repr(x)
    except UnicodeEncodeError:
        s = 'UTF8:' + x.value.encode('utf-8')

I think I agree that a working repr() is generally better, but in this case it should point to the programmer that they should rather have __repr__() return something sensible and avoid the trick above...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5876>
_______________________________________

From report at bugs.python.org  Sat Aug 24 09:05:05 2013
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Aug 2013 07:05:05 +0000
Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept
 any items if preceded by an option and another positional
In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za>
Message-ID: <1377327905.12.0.130613315757.issue15112@psf.upfronthosting.co.za>


Martin Panter added the comment:

I was surprised to discover that ?option straddling? doesn?t work this way with nargs="*". It seems to work fine with most other kinds of positional arguments I have tried, and I imagine that this was by design rather than accident. Many Gnu CLI programs also tend to support it as well (e.g. ?cp file1 file2 --verbose dir/?).

I assumed nargs=argparse.REMAINDER was intended to override the ?option straddling?. Otherwise, by just going off the documentation it sounds like nargs=argparse.REMAINDER is much the same as nargs="*".

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15112>
_______________________________________

From report at bugs.python.org  Sat Aug 24 09:16:06 2013
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Aug 2013 07:16:06 +0000
Subject: [issue14191] argparse doesn't allow optionals within positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1377328566.28.0.0925079648541.issue14191@psf.upfronthosting.co.za>


Martin Panter added the comment:

It sounds like this bug might cover Issue 15112, which is only concerned with options between different positional parameters.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14191>
_______________________________________

From report at bugs.python.org  Sat Aug 24 10:30:43 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Aug 2013 08:30:43 +0000
Subject: [issue17410] Generator-based HTMLParser
In-Reply-To: <1363198192.05.0.796177094664.issue17410@psf.upfronthosting.co.za>
Message-ID: <1377333043.38.0.210769880856.issue17410@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17410>
_______________________________________

From report at bugs.python.org  Sat Aug 24 10:37:01 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 24 Aug 2013 08:37:01 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <1375531895.31.0.501848123953.issue18643@psf.upfronthosting.co.za>
Message-ID: <1377333421.25.0.367492617158.issue18643@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Here's a patch.

Note that I'm still not sure whether it belong to the socket module or test.support.

----------
keywords: +needs review, patch
stage: needs patch -> patch review
versions: +Python 3.4
Added file: http://bugs.python.org/file31452/socketpair.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Sat Aug 24 11:29:24 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 24 Aug 2013 09:29:24 +0000
Subject: [issue18538] `python -m dis ` should use argparse
In-Reply-To: <1374623355.46.0.506955235816.issue18538@psf.upfronthosting.co.za>
Message-ID: <1377336564.06.0.516154903302.issue18538@psf.upfronthosting.co.za>


Michele Orr? added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18538>
_______________________________________

From report at bugs.python.org  Sat Aug 24 12:16:57 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 24 Aug 2013 10:16:57 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <1375531895.31.0.501848123953.issue18643@psf.upfronthosting.co.za>
Message-ID: <1377339417.89.0.829165756247.issue18643@psf.upfronthosting.co.za>


STINNER Victor added the comment:

On Linux, many tests of test_socket are failing with the pure Python implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Sat Aug 24 12:44:34 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 24 Aug 2013 10:44:34 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <1377339417.89.0.829165756247.issue18643@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1yDFYsYjay8KUbg6s0tbu7TLt2CmxgqhB017bYnEzc6A@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> On Linux, many tests of test_socket are failing with the pure Python
> implementation.

The only failing tests I see are due to the fact that the Python
implementation uses AF_INET instead of AF_UNIX, which is normal since
Windows doesn't have AF_UNIX.
Do you see other failures?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Sat Aug 24 13:16:56 2013
From: report at bugs.python.org (Sworddragon)
Date: Sat, 24 Aug 2013 11:16:56 +0000
Subject: [issue18824] Adding LogRecord attribute "traceback"
Message-ID: <1377343016.83.0.299071692967.issue18824@psf.upfronthosting.co.za>


New submission from Sworddragon:

On configuring a logger with logging.basicConfig() and using logging.exception() the traceback is always written implicitly to the end. This makes it not possible to create a formation that writes something beyond the traceback. For example it could be something like that: logging.basicConfig(filename = '/tmp/python.log', format = '%(asctime)s\n%(traceback)s\nSome_text_or_LogRecords_after_the_traceback', datefmt = '%Y-%m-%d %H:%M:%S')

----------
components: Library (Lib)
messages: 196072
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Adding LogRecord attribute "traceback"
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18824>
_______________________________________

From report at bugs.python.org  Sat Aug 24 13:33:10 2013
From: report at bugs.python.org (Sworddragon)
Date: Sat, 24 Aug 2013 11:33:10 +0000
Subject: [issue18825] Making msg optional on logging.exception() and similar
 variants
Message-ID: <1377343990.79.0.586156704832.issue18825@psf.upfronthosting.co.za>


New submission from Sworddragon:

For logging.exception() and similar variants the msg argument must be passed but on a formation the LogRecord "message" is not mandatory. In this case wouldn't it be better to make the msg argument optional? At default it could be None or ''.

----------
components: Library (Lib)
messages: 196073
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Making msg optional on logging.exception() and similar variants
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18825>
_______________________________________

From report at bugs.python.org  Sat Aug 24 13:50:30 2013
From: report at bugs.python.org (Francisco Freire)
Date: Sat, 24 Aug 2013 11:50:30 +0000
Subject: [issue14019] Unify tests for str.format and string.Formatter
In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za>
Message-ID: <1377345030.41.0.288860818461.issue14019@psf.upfronthosting.co.za>


Francisco Freire added the comment:

Thanks for the review. I corrected some issues in my code. Here is the new patch.

----------
Added file: http://bugs.python.org/file31453/mywork2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14019>
_______________________________________

From report at bugs.python.org  Sat Aug 24 14:04:15 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 24 Aug 2013 12:04:15 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <CAP7+vJKP=mkOhqS6VnbLf3bjRnM8RdAVYCbUDdkgKznM_rMyWQ@mail.gmail.com>
Message-ID: <CAH_1eM3-7x_i3vJtF8ZNf5ia0hCBBUU6MCq4W9r2h1UH8n+KeA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Alright, I've updated the patch to have a distinct selectors module,
and with Guido's comments.

Before I post it for final review, I have three more questions:
1) In the documentation, I don't know how to best refer to files
object registered: is "file descriptor" OK, or is it too low-level?
Otherwise I'd be tempted to use just "file", but then this doesn't
include sockets, pipes, etc. Or maybe "file object"/"file-like
object"?

2) currently, the select() method returns a list of
(<file>, <event>, <data>)

But the opaque "data" object is optional, which means that many user
might end up doing:

for file, event, data in selector.select():
    if event & READ_EVENT:
        file.recv(1024)
    # don't use data

i.e. have to unpack it for no reason.

Would it make sense to return (<key>, <event>) instead?
This way the user has all the interesting information, and can do:

for key, event in selector.select():
    if event & READ_EVENT:
        key.file.recv(1024)
        or
        os.read(key.fd, 1024)

3) Concerning get_info(): right now the signature is:
get_info(): fileobj -> (events, data)

Wouldn't it be better to just return the whole key instead, which
contains all the relevant information (events, data, fd and fileobj).
Then we should probably also rename the method to get_key()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Sat Aug 24 15:41:58 2013
From: report at bugs.python.org (Tamas K)
Date: Sat, 24 Aug 2013 13:41:58 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377351718.08.0.661774291179.issue18808@psf.upfronthosting.co.za>


Tamas K added the comment:

After a quick glance, I can't see how this patch would fix the problem. It still depends on threading's Thread.join, which is affected by the race condition in __bootstrap_inner.

We already did a Thread.join before calling Py_EndInterpreter and still got bitten by the race.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Aug 24 15:46:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Aug 2013 13:46:38 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377351998.56.0.643910081201.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Well, that's a good point. It does bring in line subinterpreters with the main interpreter when it comes to automatically joining non-daemon threads, but it doesn't solve the race condition you talked about. I forgot a bit too fast about it :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Aug 24 15:52:12 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 24 Aug 2013 13:52:12 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <CAH_1eM1yDFYsYjay8KUbg6s0tbu7TLt2CmxgqhB017bYnEzc6A@mail.gmail.com>
Message-ID: <CAMpsgwbemXcH0_ftQKKkr0Kk8y2Pc4GLMGx4HuHmgwmr_HjzhQ@mail.gmail.com>


STINNER Victor added the comment:

> Do you see other failures?

I applied your patch and I just replace the hasattr with:
hasattr(_socket, "Xsocketpair"). test_socket failures:

======================================================================
FAIL: test_sendall_interrupted (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_socket.py", line
1259, in test_sendall_interrupted
    self.check_sendall_interrupted(False)
  File "/home/haypo/prog/python/default/Lib/test/test_socket.py", line
1248, in check_sendall_interrupted
    c.sendall(b"x" * (1024**2))
AssertionError: ZeroDivisionError not raised

======================================================================
FAIL: test_sendall_interrupted_with_timeout
(test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_socket.py", line
1262, in test_sendall_interrupted_with_timeout
    self.check_sendall_interrupted(True)
  File "/home/haypo/prog/python/default/Lib/test/test_socket.py", line
1248, in check_sendall_interrupted
    c.sendall(b"x" * (1024**2))
AssertionError: ZeroDivisionError not raised

======================================================================
FAIL: testDefaults (test.test_socket.BasicSocketPairTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_socket.py", line
3640, in testDefaults
    self._check_defaults(self.serv)
  File "/home/haypo/prog/python/default/Lib/test/test_socket.py", line
3630, in _check_defaults
    self.assertEqual(sock.family, socket.AF_UNIX)
AssertionError: 2 != 1

======================================================================
FAIL: testDefaults (test.test_socket.BasicSocketPairTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_socket.py", line
261, in _tearDown
    raise exc
  File "/home/haypo/prog/python/default/Lib/test/test_socket.py", line
273, in clientRun
    test_func()
  File "/home/haypo/prog/python/default/Lib/test/test_socket.py", line
3637, in _testDefaults
    self._check_defaults(self.cli)
  File "/home/haypo/prog/python/default/Lib/test/test_socket.py", line
3630, in _check_defaults
    self.assertEqual(sock.family, socket.AF_UNIX)
AssertionError: 2 != 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Sat Aug 24 16:32:11 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Aug 2013 14:32:11 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377354731.69.0.649881886497.issue17741@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Reopening this as per discussion on python-dev. I haven't reverted anything at this point, as subsequent changes mean a simple "hg backout" is no longer sufficient.

----------
resolution: fixed -> 
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sat Aug 24 16:48:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Aug 2013 14:48:32 +0000
Subject: [issue18538] `python -m dis ` should use argparse
In-Reply-To: <1374623355.46.0.506955235816.issue18538@psf.upfronthosting.co.za>
Message-ID: <3cMj5q2B9xz7LlK@mail.python.org>


Roundup Robot added the comment:

New changeset 59f98b96607e by Nick Coghlan in branch 'default':
Close #18538: ``python -m dis`` now uses argparse.
http://hg.python.org/cpython/rev/59f98b96607e

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18538>
_______________________________________

From report at bugs.python.org  Sat Aug 24 17:03:15 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Aug 2013 15:03:15 +0000
Subject: [issue17400] ipaddress should make it easy to identify rfc6598
 addresses
In-Reply-To: <1363052217.02.0.113831391012.issue17400@psf.upfronthosting.co.za>
Message-ID: <1377356595.85.0.880570551558.issue17400@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Reopening this - rewording the issue title to cover the problem to be solved (i.e. accounting for RFC 6598 addresses) rather than a specific solution (which isn't appropriate, since the RFC *explicitly* states that shared addresses and private addresses aren't the same thing)

It seems to me that the simplest solution would be to use the terminology from RFC 6598 and add a new "is_shared" attribute to addresses.

----------
resolution: rejected -> 
status: closed -> open
title: ipaddress.is_private needs to take into account of rfc6598 -> ipaddress should make it easy to identify rfc6598 addresses

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17400>
_______________________________________

From report at bugs.python.org  Sat Aug 24 18:13:11 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Sat, 24 Aug 2013 16:13:11 +0000
Subject: [issue18803] Fix more typos in .py files
In-Reply-To: <1377119764.79.0.128935070292.issue18803@psf.upfronthosting.co.za>
Message-ID: <1377360791.94.0.0762654293764.issue18803@psf.upfronthosting.co.za>


F?vry Thibault added the comment:

Ezio : Yes, I was just following Reddy's advice from another bug report (issue 18466) 

Terry : Yes, looks like I was tired while doing that...

 Should be fixed in the updated patch

----------
Added file: http://bugs.python.org/file31454/more_typos.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18803>
_______________________________________

From report at bugs.python.org  Sat Aug 24 19:49:35 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 24 Aug 2013 17:49:35 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <3cGttX4hM0z7Ljp@mail.python.org>
Message-ID: <CAH_1eM2TZc4kbQKNhSVAB4o9sdZR+DJURmDArVrpj8YHr1KnLQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> New changeset fe949918616c by Antoine Pitrou in branch 'default':
> Issue #18756: Improve error reporting in os.urandom() when the failure is due to something else than /dev/urandom not existing.
> http://hg.python.org/cpython/rev/fe949918616c

Antoine, this changeset broke Tiger buildbots badly:
"""
======================================================================
ERROR: test_urandom_failure (test.test_os.URandomTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_os.py",
line 1033, in test_urandom_failure
ValueError: not allowed to raise maximum limit
"""

http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/6826/steps/test/logs/stdio

"""
1030 # We restore the old limit as soon as possible. If doing it
1031 # using addCleanup(), code running in between would fail
1032 # creating any file descriptor.
1033 resource.setrlimit(resource.RLIMIT_NOFILE, (soft_limit, hard_limit))
"""

The code trying to reset RLIMIT_NOFILE to its previous value fails,
and as a consequence, all subsequent FDs creation fail (since the soft
limit it 1)...

It looks like Tiger getrlimit() return a nonsensical value (maybe -1),
which means that you can't do setrlimit(getrlimit()), or yet another
OS X bug (TM).
See e.g. http://www.couchbase.com/issues/browse/MB-3064

I'd suggest two things:
- skip it on Tiger (using support.requires_mac_vers() decorator)
- run the test in a subprocess (using the test in your latest patch
would be fine), to be more robust against this

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Sat Aug 24 20:10:53 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 24 Aug 2013 18:10:53 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <CAH_1eM2TZc4kbQKNhSVAB4o9sdZR+DJURmDArVrpj8YHr1KnLQ@mail.gmail.com>
Message-ID: <CAH_1eM1XezuJB6SdtQpTUampmwtbM_dMa-3Y3XfMfWygAbHCPw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Or more precisely, just run the test in a subprocess. That should fix
the OS X failure if we don't restore the RLIMIT_NOFILE limits, and
will make the test more robust (but you can't reuse the new test,
since it won't work with lazy-opening).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Sat Aug 24 20:44:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Aug 2013 18:44:14 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377369854.58.0.654648727477.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch to remove the race condition. The patch is sufficiently delicate that I'd rather reserve this for 3.4, though.

----------
nosy: +neologix
Added file: http://bugs.python.org/file31455/threadstate_join.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Aug 24 20:54:58 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Aug 2013 18:54:58 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <3cMpZ94zdPz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset b9e62929460e by Antoine Pitrou in branch '3.3':
Issue #18756: make test_urandom_failure more robust by executing its code in a subprocess
http://hg.python.org/cpython/rev/b9e62929460e

New changeset 68ff013b194c by Antoine Pitrou in branch 'default':
Issue #18756: make test_urandom_failure more robust by executing its code in a subprocess
http://hg.python.org/cpython/rev/68ff013b194c

New changeset 869df611c138 by Antoine Pitrou in branch '2.7':
Issue #18756: make test_urandom_failure more robust by executing its code in a subprocess
http://hg.python.org/cpython/rev/869df611c138

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Sat Aug 24 20:55:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Aug 2013 18:55:54 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1377370554.13.0.751905753416.issue18756@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, the tiger should feel better now :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Sat Aug 24 21:03:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Aug 2013 19:03:35 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1377371015.62.0.859601562878.issue18772@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Since nobody seems to object to the patch, I'm commit it :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Sat Aug 24 21:07:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Aug 2013 19:07:16 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <3cMprN1b9Wz7Ljt@mail.python.org>


Roundup Robot added the comment:

New changeset 2f1bac39565a by Antoine Pitrou in branch 'default':
Issue #18772: fix the gdb plugin after the set implementation changes
http://hg.python.org/cpython/rev/2f1bac39565a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Sat Aug 24 21:08:22 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 19:08:22 +0000
Subject: [issue18826] reversed() requires a sequence - Could work on any
 iterator?
Message-ID: <1377371302.25.0.787358043575.issue18826@psf.upfronthosting.co.za>


New submission from Donald Stufft:

I noticed today that the builtin reversed() requires an explicit sequence and won't work with an iterator instead it throws a TypeError like:

>>> reversed(x for x in [1, 2, 3])
TypeError: argument to reversed() must be a sequence

It would be really great if reversed() worked on iterators too. Currently it requires an explicit list() before you can sent it back into reversed() which seems like it hurts readability.

For what it's worth I discovered this when trying to reverse the output of itertools.dropwhile.

----------
messages: 196090
nosy: dstufft
priority: normal
severity: normal
status: open
title: reversed() requires a sequence - Could work on any iterator?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18826>
_______________________________________

From report at bugs.python.org  Sat Aug 24 21:08:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Aug 2013 19:08:56 +0000
Subject: [issue18772] Fix gdb plugin for new sets dummy object
In-Reply-To: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>
Message-ID: <1377371336.95.0.593829808736.issue18772@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Well, it should be ok now (at least now the test passes here).

----------
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18772>
_______________________________________

From report at bugs.python.org  Sat Aug 24 21:13:30 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Aug 2013 19:13:30 +0000
Subject: [issue18826] reversed() requires a sequence - Could work on any
 iterator?
In-Reply-To: <1377371302.25.0.787358043575.issue18826@psf.upfronthosting.co.za>
Message-ID: <1377371610.61.0.587268713697.issue18826@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18826>
_______________________________________

From report at bugs.python.org  Sat Aug 24 21:27:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Aug 2013 19:27:10 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1377372430.02.0.869069765741.issue16853@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Alright, I've updated the patch to have a distinct selectors module,
> and with Guido's comments.

Didn't you forget to upload it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Sat Aug 24 21:29:51 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 19:29:51 +0000
Subject: [issue18826] reversed() requires a sequence - Could work on any
 iterator?
In-Reply-To: <1377371302.25.0.787358043575.issue18826@psf.upfronthosting.co.za>
Message-ID: <1377372591.19.0.563294988344.issue18826@psf.upfronthosting.co.za>


Donald Stufft added the comment:

As an additional note this works how I would expect it to work if you're using sorted() instead of reversed() which I think is a stronger point in the favor of making reversed() work this way as well.

>>> sorted(x for x in [1, 2, 3])
[1, 2, 3]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18826>
_______________________________________

From report at bugs.python.org  Sat Aug 24 21:32:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Aug 2013 19:32:47 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1377372767.34.0.814250082683.issue18756@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

So, to come back to the original topic, is everyone sold on the idea of caching the urandom fd lazily?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Sat Aug 24 21:34:22 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 19:34:22 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1377372862.4.0.0722403759915.issue18756@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Lazily opening urandom and holding it open sounds like a sane thing to do to me +1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Sat Aug 24 21:40:09 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 24 Aug 2013 19:40:09 +0000
Subject: [issue18746] test_threading.test_finalize_with_trace() fails on
 FreeBSD buildbot
In-Reply-To: <1376561660.51.0.498019291184.issue18746@psf.upfronthosting.co.za>
Message-ID: <1377373209.97.0.218177902068.issue18746@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It may be related to #18408 (changeset 5bd9db528aed) and #18664.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18746>
_______________________________________

From report at bugs.python.org  Sat Aug 24 21:40:24 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 24 Aug 2013 19:40:24 +0000
Subject: [issue18664] occasional test_threading failure
In-Reply-To: <1375741165.75.0.0273425053979.issue18664@psf.upfronthosting.co.za>
Message-ID: <1377373224.03.0.276926742069.issue18664@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also issue #18746.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18664>
_______________________________________

From report at bugs.python.org  Sat Aug 24 22:33:24 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 24 Aug 2013 20:33:24 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1377372430.02.0.869069765741.issue16853@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3jBxdF7EP9Jp+k0TZSR0SjvG_NmgeTfixA2rEWUSr55g@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Didn't you forget to upload it?

I wanted to have answer to my questions first :-):

> Before I post it for final review, I have three more questions:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Sat Aug 24 22:45:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Aug 2013 20:45:12 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <CAH_1eM3jBxdF7EP9Jp+k0TZSR0SjvG_NmgeTfixA2rEWUSr55g@mail.gmail.com>
Message-ID: <1377377102.2475.10.camel@fsol>


Antoine Pitrou added the comment:

> > Didn't you forget to upload it?
> 
> I wanted to have answer to my questions first :-):

Ah, indeed, sorry!

> 1) In the documentation, I don't know how to best refer to files
> object registered: is "file descriptor" OK, or is it too low-level?
> Otherwise I'd be tempted to use just "file", but then this doesn't
> include sockets, pipes, etc. Or maybe "file object"/"file-like
> object"?

"file object" and "file-like object" are the convention used in the
docs:
http://docs.python.org/dev/glossary.html#term-file-object

That said, if the APIs also accept file descriptors, it must be
mentioned.

> i.e. have to unpack it for no reason.

That doesn't seem much of a concern, does it?
Perhaps there can be two separate methods, select() and
select_with_data(), but that sounds a bit overkill.

> 3) Concerning get_info(): right now the signature is:
> get_info(): fileobj -> (events, data)
> 
> Wouldn't it be better to just return the whole key instead [...]

No opinion :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Sat Aug 24 23:37:57 2013
From: report at bugs.python.org (paul j3)
Date: Sat, 24 Aug 2013 21:37:57 +0000
Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept
 any items if preceded by an option and another positional
In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za>
Message-ID: <1377380277.75.0.145677733082.issue15112@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15112>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:05:21 2013
From: report at bugs.python.org (Alexander Schier)
Date: Sat, 24 Aug 2013 22:05:21 +0000
Subject: [issue18827] mistake in the timedelta.total_seconds docstring
Message-ID: <1377381921.16.0.995171026465.issue18827@psf.upfronthosting.co.za>


New submission from Alexander Schier:

> Return the total number of seconds contained in the duration. Equivalent to (td.microseconds + (td.seconds + td.days * 24 * 3600) * 10**6) / 10**6 computed with true division enabled.

Should be
> Return the total number of seconds contained in the duration. Equivalent to (td.microseconds / 10**6 + (td.seconds + td.days * 24 * 3600) * 10**6) computed with true division enabled.

At least i hope, the bug is only in the docs and not in the function ;).

----------
assignee: docs at python
components: Documentation
messages: 196100
nosy: allo, docs at python
priority: normal
severity: normal
status: open
title: mistake in the timedelta.total_seconds docstring
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18827>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:14:29 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 24 Aug 2013 22:14:29 +0000
Subject: [issue18827] mistake in the timedelta.total_seconds docstring
In-Reply-To: <1377381921.16.0.995171026465.issue18827@psf.upfronthosting.co.za>
Message-ID: <1377382469.42.0.295230732266.issue18827@psf.upfronthosting.co.za>


Tim Peters added the comment:

The docs look correct to me.  For example,

>>> from datetime import *
>>> td = datetime.now() - datetime(1,1,1)
>>> td
datetime.timedelta(735103, 61756, 484000)
>>> td.total_seconds()
63512960956.484
                                                                ^
What the docs say match that output:

>>> (td.microseconds + (td.seconds + td.days * 24 * 3600) * 10**6) / 1e6
63512960956.484

Your suggestion's output:

>>> (td.microseconds / 1e6 + (td.seconds + td.days * 24 * 3600) * 10**6)
6.3512960956e+16

You're multiplying the number seconds by a million - not a good idea ;-)

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18827>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:25:22 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 22:25:22 +0000
Subject: [issue18582] PBKDF2 support
In-Reply-To: <1375024279.36.0.0953079533445.issue18582@psf.upfronthosting.co.za>
Message-ID: <1377383122.03.0.69304772605.issue18582@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald.stufft at gmail.com>:


----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18582>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:25:38 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 22:25:38 +0000
Subject: [issue17134] Use Windows' certificate store for CA certs
In-Reply-To: <1360078143.8.0.938168290854.issue17134@psf.upfronthosting.co.za>
Message-ID: <1377383138.03.0.791976530275.issue17134@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald.stufft at gmail.com>:


----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17134>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:31:43 2013
From: report at bugs.python.org (Alexander Schier)
Date: Sat, 24 Aug 2013 22:31:43 +0000
Subject: [issue18827] mistake in the timedelta.total_seconds docstring
In-Reply-To: <1377381921.16.0.995171026465.issue18827@psf.upfronthosting.co.za>
Message-ID: <1377383503.0.0.362723496873.issue18827@psf.upfronthosting.co.za>


Alexander Schier added the comment:

Err, sorry my fault. Too late in the evening ;).

I saw the division by one million, but not the multiplation by one million before. Additionally i was confused, because i expected that seconds are added to each other in the parenthesis.

closing.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18827>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:35:48 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 22:35:48 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
 local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1377383748.34.0.0305514919903.issue17128@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald.stufft at gmail.com>:


----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17128>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:36:08 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 22:36:08 +0000
Subject: [issue9146] Segfault in hashlib in OpenSSL FIPS mode using
 non-FIPS-compliant hashes, if "ssl" imported before "hashlib"
In-Reply-To: <1278097810.42.0.823869291087.issue9146@psf.upfronthosting.co.za>
Message-ID: <1377383768.68.0.0685027391541.issue9146@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald.stufft at gmail.com>:


----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9146>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:37:35 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 22:37:35 +0000
Subject: [issue18233] SSLSocket.getpeercertchain()
In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za>
Message-ID: <1377383855.35.0.559082617142.issue18233@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald.stufft at gmail.com>:


----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18233>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:39:01 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 22:39:01 +0000
Subject: [issue14518] Add bcrypt $2a$ to crypt.py
In-Reply-To: <1333741347.69.0.597224923936.issue14518@psf.upfronthosting.co.za>
Message-ID: <1377383941.29.0.407494439274.issue14518@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald.stufft at gmail.com>:


----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14518>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:39:44 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 22:39:44 +0000
Subject: [issue18454] distutils crashes when uploading to PyPI having only the
 username (no pw) defined
In-Reply-To: <1373822688.67.0.938925989206.issue18454@psf.upfronthosting.co.za>
Message-ID: <1377383984.71.0.405410106872.issue18454@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald.stufft at gmail.com>:


----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18454>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:42:00 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 24 Aug 2013 22:42:00 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <CAMpsgwbemXcH0_ftQKKkr0Kk8y2Pc4GLMGx4HuHmgwmr_HjzhQ@mail.gmail.com>
Message-ID: <CAH_1eM1V8hMPbSCZMrJbiTUuB8WLHZ6hAkmLJRPwFJ-usdZTYw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

>     self.assertEqual(sock.family, socket.AF_UNIX)
> AssertionError: 2 != 1

This is normal.

======================================================================
> FAIL: test_sendall_interrupted (test.test_socket.GeneralModuleTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/home/haypo/prog/python/default/Lib/test/test_socket.py", line
> 1259, in test_sendall_interrupted
>     self.check_sendall_interrupted(False)
>   File "/home/haypo/prog/python/default/Lib/test/test_socket.py", line
> 1248, in check_sendall_interrupted
>     c.sendall(b"x" * (1024**2))
> AssertionError: ZeroDivisionError not raised

Not this one.
I can't reproduce it on my Linux box, could you post the result of:

$ strace -ttTf ./python -m test -v -m test_sendall_interrupted test_socket

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:42:36 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 22:42:36 +0000
Subject: [issue13655] Python SSL stack doesn't have a default CA Store
In-Reply-To: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za>
Message-ID: <1377384156.04.0.267305534112.issue13655@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald.stufft at gmail.com>:


----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13655>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:42:47 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 22:42:47 +0000
Subject: [issue8813] SSLContext doesn't support loading a CRL
In-Reply-To: <1274735830.03.0.714974872377.issue8813@psf.upfronthosting.co.za>
Message-ID: <1377384167.2.0.546611947023.issue8813@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald.stufft at gmail.com>:


----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8813>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:47:21 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 22:47:21 +0000
Subject: [issue16113] Add SHA-3 (Keccak) support
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <1377384441.71.0.854825041611.issue16113@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald at stufft.io>:


----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16113>
_______________________________________

From report at bugs.python.org  Sun Aug 25 00:51:47 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 22:51:47 +0000
Subject: [issue8106] SSL session management
In-Reply-To: <1268184052.67.0.269640299758.issue8106@psf.upfronthosting.co.za>
Message-ID: <1377384707.98.0.226838639042.issue8106@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald at stufft.io>:


----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8106>
_______________________________________

From report at bugs.python.org  Sun Aug 25 01:04:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Aug 2013 23:04:36 +0000
Subject: [issue18807] Allow venv to create copies,
 even when symlinks are supported
In-Reply-To: <1377176626.74.0.056181108419.issue18807@psf.upfronthosting.co.za>
Message-ID: <3cMw6C73kXz7Ljf@mail.python.org>


Roundup Robot added the comment:

New changeset ffb01a6c0960 by Vinay Sajip in branch 'default':
Closes #18807: pyvenv now takes a --copies argument allowing copies instead of symlinks even where symlinks are available and the default.
http://hg.python.org/cpython/rev/ffb01a6c0960

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18807>
_______________________________________

From report at bugs.python.org  Sun Aug 25 01:07:31 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 24 Aug 2013 23:07:31 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377385651.89.0.0793672497782.issue17741@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I like the idea of having .events() in a special target passed to a XMLParser, which already has feed() and close(). I read through Stefan's proposal and there are a couple of issues I wanted to raise:

1. Why have the "event builder" wrap a tree builder? Can't it just be a separate target?
2. Instead of the stock XMLParser recognizing the event builder via isinstance and giving it special treatment, would it not be better to still have a separate class that implements the XMLParser interface (it can derive from it or just use duck typing)?

Note that (2) brings us closer to Antoine's original design, albeit with different method names and somewhat different underlying implementation.

Also, Stefan, could you clearly explain the specific implementation issue you ran into with your partial patch. You mentioned an unrelated bug that can/should be solved before such an implementation can work. Can you provide more details?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Aug 25 02:02:50 2013
From: report at bugs.python.org (Julien Phalip)
Date: Sun, 25 Aug 2013 00:02:50 +0000
Subject: [issue16611] Cookie.py does not parse httponly or secure cookie flags
In-Reply-To: <1354654224.49.0.677339520856.issue16611@psf.upfronthosting.co.za>
Message-ID: <1377388970.12.0.196939528249.issue16611@psf.upfronthosting.co.za>


Julien Phalip added the comment:

Thanks for the review and new patch, David! Your approach makes sense and the patch looks good to me.

However, regarding backwards-compatibility, is that really a concern?

Currently the deserialization process systematically 1) Adds the 'httponly' and 'secure' dict keys to the cookie object and 2) Puts an empty string value for those keys, regardless of whether those flags are present or not in the loaded string. So currently nobody's code could possibly rely on any particular state or behavior in the cookie object to determine if those flags were originally present in the loaded string.

I guess I'm wondering what could possibly break in people's code if we now implemented a fully logical fix for this. What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16611>
_______________________________________

From report at bugs.python.org  Sun Aug 25 02:16:56 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 25 Aug 2013 00:16:56 +0000
Subject: [issue16611] Cookie.py does not parse httponly or secure cookie flags
In-Reply-To: <1354654224.49.0.677339520856.issue16611@psf.upfronthosting.co.za>
Message-ID: <1377389816.64.0.272756038987.issue16611@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think a fully logical fix could be implemented for 3.4 (after I commit this), because as you say it is *unlikely* that anyone is relying on the behaviors mentioned as "backward compatibility issues" in the added tests.  However, it is *possible* someone is dealing with a quirky situation where some other broken software is using these flags in key/value form, and depending on it.  Not likely, no (especially since the value would be lost on re-serialization), but since we *can* fix the issue without risking breaking such code, we should, for the maintenance release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16611>
_______________________________________

From report at bugs.python.org  Sun Aug 25 03:32:45 2013
From: report at bugs.python.org (Julien Phalip)
Date: Sun, 25 Aug 2013 01:32:45 +0000
Subject: [issue16611] Cookie.py does not parse httponly or secure cookie flags
In-Reply-To: <1354654224.49.0.677339520856.issue16611@psf.upfronthosting.co.za>
Message-ID: <1377394365.48.0.628320806048.issue16611@psf.upfronthosting.co.za>


Julien Phalip added the comment:

Thanks for the clarification, that makes perfect sense!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16611>
_______________________________________

From report at bugs.python.org  Sun Aug 25 03:53:05 2013
From: report at bugs.python.org (Madison May)
Date: Sun, 25 Aug 2013 01:53:05 +0000
Subject: [issue18826] reversed() requires a sequence - Could work on any
 iterator?
In-Reply-To: <1377371302.25.0.787358043575.issue18826@psf.upfronthosting.co.za>
Message-ID: <1377395585.27.0.432662007885.issue18826@psf.upfronthosting.co.za>


Madison May added the comment:

Reversed doesn't make sense for all iterables.

>>> a = set([1, 2, 3])
>>> a = iter(a) # No error
>>> a = reversed(a) # Not typically desirable 

The point is that not all iterables are necessarily ordered.  And a reversed function shouldn't operate on unordered types.

Here's the relevant section of the docs for reversed():

reversed(seq)
    Return a reverse iterator. seq must be an object which has a 
    __reversed__() method or supports the sequence protocol (the 
    __len__() method and the __getitem__() method with integer 
    arguments starting at 0).  

Your point about the sorted()'s behavior seems like a fair one, though. Perhaps it does make sense to support implicit conversion to lists for generator objects passed to reversed().

----------
nosy: +madison.may

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18826>
_______________________________________

From report at bugs.python.org  Sun Aug 25 04:01:08 2013
From: report at bugs.python.org (paul j3)
Date: Sun, 25 Aug 2013 02:01:08 +0000
Subject: [issue14191] argparse doesn't allow optionals within positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1377396068.92.0.880123129049.issue14191@psf.upfronthosting.co.za>


paul j3 added the comment:

Above in
http://bugs.python.org/issue14191#msg187051
I proposed a patch that is quite close to bethard's patch in http://bugs.python.org/issue15112#msg166173

Both modify the same place, doing the same (pop items off arg_counts).  The logic is a little different.  I'd have to look at them more carefully to see whether one is more robust.  Thanks for linking that issue.

The main issue here is different, allowing for complete intermixing of optionals and positionals.  Over at 15112 the issue is intermixing of optionals and 'whole' positionals.  My 187051 patch belongs over there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14191>
_______________________________________

From report at bugs.python.org  Sun Aug 25 04:02:22 2013
From: report at bugs.python.org (paul j3)
Date: Sun, 25 Aug 2013 02:02:22 +0000
Subject: [issue14191] argparse doesn't allow optionals within positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1377396142.3.0.10938522116.issue14191@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


Added file: http://bugs.python.org/file29880/mixed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14191>
_______________________________________

From report at bugs.python.org  Sun Aug 25 04:11:04 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 25 Aug 2013 02:11:04 +0000
Subject: [issue18489] IDLE Unit test for SearchEngine.py
In-Reply-To: <1374118219.91.0.797974191988.issue18489@psf.upfronthosting.co.za>
Message-ID: <1377396664.65.0.580578491424.issue18489@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Big changes: monkey-patched module so tests of functions not using Text are non-gui; split search tests from other class tests as part of this. Several other little changes.

The four lines still not covered are the bodies of
if ok: start = last
if wrapped and line > startline: break
if wrapped and line < startline: break
if i == j: j = j+1 
I will look at these when I review the search tests, but they are not commit blockers.

----------
Added file: http://bugs.python.org/file31456/18489-test_searchengine5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18489>
_______________________________________

From report at bugs.python.org  Sun Aug 25 04:11:58 2013
From: report at bugs.python.org (paul j3)
Date: Sun, 25 Aug 2013 02:11:58 +0000
Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept
 any items if preceded by an option and another positional
In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za>
Message-ID: <1377396718.05.0.0919602988642.issue15112@psf.upfronthosting.co.za>


paul j3 added the comment:

I originally posted this on http://bugs.python.org/issue14191, but I think it belongs here.  The patch I proposed is similar to berthard's, popping items off the end of 'args_counts'.  I intend to check whether the logic is equivalent.

----------------------------
copy from http://bugs.python.org/msg187051
----------------------------
This patch permits the mixing of optionals with positionals, with the caveat that a particular positional cannot be split up.

If:

    parser = ArgumentParser()
    parser.add_argument('-f','--foo')
    parser.add_argument('cmd')
    parser.add_argument('rest', nargs='*')

    '-f1 cmd 1 2 3', 
    'cmd -f1 1 2 3', 
    'cmd 1 2 3 -f1' 

all give {cmd='cmd', rest=['1','2','3'], foo='1'}.  

But 'cmd 1 -f1 2 3', does not recognize ['2','3'].

Previously 'cmd -f1 1 2 3' would return rest=[], and not recognize ['1','2','3'].  With this change the nargs='*' behaves more like nargs='+', surviving to parse the 2nd group of positional strings.

The trick is to modify arg_counts in consume_positionals(), removing matches that don't do anything (don't consume argument strings). 

    if 'O' in arg_strings_pattern[start_index:]:
        # if there is an optional after this, remove
        # 'empty' positionals from the current match
        while len(arg_counts)>1 and arg_counts[-1]==0:
            arg_counts = arg_counts[:-1]

This change passes all of the existing test_argparse.py tests.  It also passes the optparse tests that I added in http://bugs.python.org/issue9334#msg184987
I added 4 cases to illustrate this change.

----------
Added file: http://bugs.python.org/file31457/mixed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15112>
_______________________________________

From report at bugs.python.org  Sun Aug 25 04:13:03 2013
From: report at bugs.python.org (paul j3)
Date: Sun, 25 Aug 2013 02:13:03 +0000
Subject: [issue14191] argparse doesn't allow optionals within positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1377396783.23.0.104518464539.issue14191@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


Removed file: http://bugs.python.org/file29880/mixed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14191>
_______________________________________

From report at bugs.python.org  Sun Aug 25 08:08:31 2013
From: report at bugs.python.org (koobs)
Date: Sun, 25 Aug 2013 06:08:31 +0000
Subject: [issue11973] kevent does not accept KQ_NOTE_EXIT (and other (f)flags)
In-Reply-To: <1304274394.46.0.0260368215252.issue11973@psf.upfronthosting.co.za>
Message-ID: <1377410911.5.0.115840218343.issue11973@psf.upfronthosting.co.za>


Changes by koobs <koobs.freebsd at gmail.com>:


----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11973>
_______________________________________

From report at bugs.python.org  Sun Aug 25 10:21:21 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 25 Aug 2013 08:21:21 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1377418881.2.0.21192957398.issue18709@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

The test is failing on Tiger buildbots:

"""
======================================================================
FAIL: test_parse_cert_CVE_2013_4238 (test.test_ssl.BasicSocketTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_ssl.py", line 230, in test_parse_cert_CVE_2013_4238
    ('IP Address', '2001:DB8:0:0:0:0:0:1\n'))
AssertionError: Tuples differ: (('DNS', 'altnull.python.org\x... != (('DNS', 'altnull.python.org\x...

First differing element 4:
('IP Address', '<invalid>')
('IP Address', '2001:DB8:0:0:0:0:0:1\n')

  (('DNS', 'altnull.python.org\x00example.com'),
   ('email', 'null at python.org\x00user at example.org'),
   ('URI', 'http://null.python.org\x00http://example.org'),
   ('IP Address', '192.0.2.1'),
-  ('IP Address', '<invalid>'))
+  ('IP Address', '2001:DB8:0:0:0:0:0:1\n'))

----------------------------------------------------------------------
"""

http://buildbot.python.org/all/builders/x86 Tiger 3.x/builds/6829/steps/test/logs/stdio

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Sun Aug 25 10:40:06 2013
From: report at bugs.python.org (Drekin)
Date: Sun, 25 Aug 2013 08:40:06 +0000
Subject: [issue12869] PyOS_StdioReadline is printing the prompt on stderr
In-Reply-To: <1314801518.5.0.445361297153.issue12869@psf.upfronthosting.co.za>
Message-ID: <1377420006.48.0.685257207823.issue12869@psf.upfronthosting.co.za>


Drekin added the comment:

Related stackoverflow question: http://stackoverflow.com/questions/18419787/where-does-pythons-interactive-prompt-output-to .

----------
nosy: +Drekin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12869>
_______________________________________

From report at bugs.python.org  Sun Aug 25 11:01:03 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 25 Aug 2013 09:01:03 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377421263.96.0.726624725426.issue18808@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

The first patch looks good, as for the second one, it'll take some time :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Aug 25 11:04:27 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 25 Aug 2013 09:04:27 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1377421467.29.0.735431026071.issue18709@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald at stufft.io>:


----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Sun Aug 25 12:04:42 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 25 Aug 2013 10:04:42 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377425082.52.0.10173275478.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

"""
1. Why have the "event builder" wrap a tree builder? Can't it just be a separate target?
"""

You need a TreeBuilder in order to build the tree for the events.

If you want to use a different target than a TreeBuilder, you're free to do so. That's the idea of wrapping.


"""
2. Instead of the stock XMLParser recognizing the event builder via isinstance and giving it special treatment, would it not be better to still have a separate class that implements the XMLParser interface (it can derive from it or just use duck typing)?
"""

Why would you want to restrict it to an XMLParser? If there was an HTMLParser (which exists in lxml.etree), then how would you make the two interact?

The isinstance() check was only a quick way to get the API working without changing the implementation in the back too much. The actual functionality should (eventually) be moved into the target itself. Currently, it is implemented internally in the parser inside of the C module. That's the main problem with the current implementation that needs fixing. See issue #17902 (which is not a documentation issue but a real issue, BTW).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Aug 25 12:10:09 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 25 Aug 2013 10:10:09 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <CAH_1eM1V8hMPbSCZMrJbiTUuB8WLHZ6hAkmLJRPwFJ-usdZTYw@mail.gmail.com>
Message-ID: <CAH_1eM0FPuJ-SbePrUm9Kp9UKsO+xssghy97EbQWhO1UJ8TLAg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Alright, I think I know what's happening.

The Python implementation uses a TCP socket, whereas the native
implementation uses AF_UNIX socket.
The maximum size of data that can be written to a socket without
blocking is given by its send/receive buffers.
On Linux, the default buffer sizes are set by:
net.core.(r|w)mem_default

but for TCP sockets, its set by:
net.ipv4.tcp_(r|w)mem

So on your machine, you probably have tcp_(r|w)mem quite larger than
(r|w)mem, so the sendall test doesn't write enough data to the socket
to block.

The solution is simply to increase the amount of data written.
Could you try the attached patch?

If it works I'll commit it, because the test isn't really reliable
(i.e. it could fail on a machine with a large (r|w)mem_default).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Sun Aug 25 12:10:38 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 25 Aug 2013 10:10:38 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <1375531895.31.0.501848123953.issue18643@psf.upfronthosting.co.za>
Message-ID: <1377425438.03.0.82410246343.issue18643@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


Added file: http://bugs.python.org/file31458/sendall_write.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Sun Aug 25 12:58:29 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 25 Aug 2013 10:58:29 +0000
Subject: [issue18819] tarfile fills devmajor and devminor fields even for
 non-devices
In-Reply-To: <1377244570.17.0.881759543234.issue18819@psf.upfronthosting.co.za>
Message-ID: <1377428309.18.0.578269039538.issue18819@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +lars.gustaebel
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18819>
_______________________________________

From report at bugs.python.org  Sun Aug 25 13:02:02 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Sun, 25 Aug 2013 11:02:02 +0000
Subject: [issue17234] python-2.7.3-r3: crash in visit_decref()
In-Reply-To: <1361266544.85.0.580763984436.issue17234@psf.upfronthosting.co.za>
Message-ID: <1377428522.95.0.477812569935.issue17234@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Hi Ramchandra and Christian,
  I am using numpy, matplotlib, expat/cElementTree, doing a lot of os.Popen calls. But I think the problem is taht I have huge lists and when I do not need them I do del(_mylist) in the code ASAP. That probably causes a lot of churn.

  Here is one stacktrace I just got with the faulthandler installed. It does not show in the trace any 3rd-party module so can I conclude it is a core python bug? Just recompiling with "-ggdb" so eventually will have better stacktraces.




  Does this help? I don't have the gdb stacktrace as I recompiled the binary now again ... :(

Fatal Python error: /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:1009 object at 0x40c0a60 has negative ref count -1
Fatal Python error: Aborted

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17234>
_______________________________________

From report at bugs.python.org  Sun Aug 25 13:27:47 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 25 Aug 2013 11:27:47 +0000
Subject: [issue17234] python-2.7.3-r3: crash in visit_decref()
In-Reply-To: <1361266544.85.0.580763984436.issue17234@psf.upfronthosting.co.za>
Message-ID: <1377430067.84.0.643263527166.issue17234@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

> Here is one stacktrace I just got with the faulthandler installed. It does not show in the trace any 3rd-party module so can I conclude it is a core python bug? Just recompiling with "-ggdb" so eventually will have better stacktraces.

I'm a C noob but I think one can't conclude that it is a core python bug as the ref count could have been messed with, then sometime later the error may occur and GDB's stacktrace will show the latter.
Or in pseudo-code:

mess_with_ref_count() # In 3rd party code
non_3rd_party_code() #the error may occur here, after the refcount was messed with, and gdb will show this function in the stack trace

BTW, run ./configure with the --with-pydebug option, that makes Python perform extra checks on refcounts and other things [0]

^0 http://docs.python.org/devguide/setup.html#compiling-for-debugging

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17234>
_______________________________________

From report at bugs.python.org  Sun Aug 25 13:43:25 2013
From: report at bugs.python.org (Drekin)
Date: Sun, 25 Aug 2013 11:43:25 +0000
Subject: [issue18597] On Windows sys.stdin.readline() doesn't handle Ctrl-C
 properly
In-Reply-To: <1375175592.24.0.539816782076.issue18597@psf.upfronthosting.co.za>
Message-ID: <1377431005.7.0.162590773424.issue18597@psf.upfronthosting.co.za>


Drekin added the comment:

Why are there actually more codepaths which may raise this issue? My naive idea would be that input() is just thin wrapper around sys.stdout.write() (for prompt) and sys.stdin.readline() which leads to sys.stdin.buffer.raw.read* where is the place where some low level OS-dependent function to actually get input from user is called (unistd.read or GNU readline or whatever). And also there is the place where the waiting for KeyboardInterrupt on Windows should occur.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18597>
_______________________________________

From report at bugs.python.org  Sun Aug 25 14:15:06 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Aug 2013 12:15:06 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <3cNFfK2L04z7LlY@mail.python.org>


Roundup Robot added the comment:

New changeset 004743d210e4 by Christian Heimes in branch '3.3':
Issue #18709: Fix issue with IPv6 address in subjectAltName on Mac OS X Tiger
http://hg.python.org/cpython/rev/004743d210e4

New changeset 577e9402cadd by Christian Heimes in branch 'default':
Issue #18709: Fix issue with IPv6 address in subjectAltName on Mac OS X Tiger
http://hg.python.org/cpython/rev/577e9402cadd

New changeset 1cd24ea5abeb by Christian Heimes in branch '2.7':
Issue #18709: Fix issue with IPv6 address in subjectAltName on Mac OS X Tiger
http://hg.python.org/cpython/rev/1cd24ea5abeb

New changeset 50803d881a92 by Christian Heimes in branch '2.6':
Issue #18709: Fix issue with IPv6 address in subjectAltName on Mac OS X Tiger
http://hg.python.org/cpython/rev/50803d881a92

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Sun Aug 25 14:16:16 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 25 Aug 2013 12:16:16 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1377432976.6.0.823528255542.issue18709@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Tiger has OpenSSL 0.9.7 which doesn't support IPv6 addresses. I have added a workaround.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Sun Aug 25 14:20:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Aug 2013 12:20:15 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <3cNFmG6f1bz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 8b962e831ff0 by Christian Heimes in branch '3.3':
Issue #18747: Fix spelling errors in my commit message and comments,
http://hg.python.org/cpython/rev/8b962e831ff0

New changeset 7b1da249ab6d by Christian Heimes in branch 'default':
Issue #18747: Fix spelling errors in my commit message and comments,
http://hg.python.org/cpython/rev/7b1da249ab6d

New changeset 3f30c281eb1c by Christian Heimes in branch '2.7':
Issue #18747: Fix spelling errors in my commit message and comments,
http://hg.python.org/cpython/rev/3f30c281eb1c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Sun Aug 25 14:48:32 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 25 Aug 2013 12:48:32 +0000
Subject: [issue11973] kevent does not accept KQ_NOTE_EXIT (and other (f)flags)
In-Reply-To: <1304274394.46.0.0260368215252.issue11973@psf.upfronthosting.co.za>
Message-ID: <1377434912.09.0.181161309532.issue11973@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The patch looks good to me.

----------
nosy: +christian.heimes
versions: +Python 3.4 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11973>
_______________________________________

From report at bugs.python.org  Sun Aug 25 14:52:00 2013
From: report at bugs.python.org (Mher Movsisyan)
Date: Sun, 25 Aug 2013 12:52:00 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
Message-ID: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>


New submission from Mher Movsisyan:

>>> urljoin('redis://localhost:6379/0', '/1')
'/1'
>>> urljoin('http://localhost:6379/0', '/1')
'http://localhost:6379/1'

----------
messages: 196125
nosy: mher.movsisyan
priority: normal
severity: normal
status: open
title: urljoin behaves differently with custom and standard schemas
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________

From report at bugs.python.org  Sun Aug 25 14:56:23 2013
From: report at bugs.python.org (Thibault Kruse)
Date: Sun, 25 Aug 2013 12:56:23 +0000
Subject: [issue18829] csv produces confusing error message for unexpected
 string encoding
Message-ID: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>


New submission from Thibault Kruse:

To reproduce

$ python --version
Python 2.7.3
$ python -c 'from __future__ import unicode_literals; import csv; reader = csv.reader("foo", delimiter=",")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: "delimiter" must be an 1-character string

This is confusing because "," is like a 1-character (unicode) string, while csv requires a 1-character (byte) string. In python3, it's the inverse problem, using bytestring b','

$ python3 --version
Python 3.2.3
$ python3 -c 'import csv; reader = csv.reader("foo", delimiter=b",")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: "delimiter" must be an 1-character string


So I believe csv should state more clearly what went wrong here in each case, or what kind of string csv is willing to accept in the respective python version.

Whether the python3 refusal to use a bytestring is even reasonable I don't know.

This might or might not be related to the issue of multichar delimiters: http://bugs.python.org/issue15158  (just sayin)

----------
components: Library (Lib)
messages: 196126
nosy: Thibault.Kruse
priority: normal
severity: normal
status: open
title: csv produces confusing error message for unexpected string encoding
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Sun Aug 25 14:58:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Aug 2013 12:58:46 +0000
Subject: [issue11973] kevent does not accept KQ_NOTE_EXIT (and other (f)flags)
In-Reply-To: <1304274394.46.0.0260368215252.issue11973@psf.upfronthosting.co.za>
Message-ID: <3cNGcj1xcvz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset d5334d8907dc by Christian Heimes in branch '3.3':
Issue #11973: Fix a problem in kevent. The flags and fflags fields are now
http://hg.python.org/cpython/rev/d5334d8907dc

New changeset 8345fb616cbd by Christian Heimes in branch 'default':
Issue #11973: Fix a problem in kevent. The flags and fflags fields are now
http://hg.python.org/cpython/rev/8345fb616cbd

New changeset 8eac75276e5b by Christian Heimes in branch '2.7':
Issue #11973: Fix a problem in kevent. The flags and fflags fields are now
http://hg.python.org/cpython/rev/8eac75276e5b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11973>
_______________________________________

From report at bugs.python.org  Sun Aug 25 14:59:41 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 25 Aug 2013 12:59:41 +0000
Subject: [issue11973] kevent does not accept KQ_NOTE_EXIT (and other (f)flags)
In-Reply-To: <1304274394.46.0.0260368215252.issue11973@psf.upfronthosting.co.za>
Message-ID: <1377435581.56.0.706220779698.issue11973@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Does somebody want to write a test for the issue, too?

----------
resolution:  -> fixed
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11973>
_______________________________________

From report at bugs.python.org  Sun Aug 25 15:04:13 2013
From: report at bugs.python.org (=?utf-8?q?G=C3=B6kcen_Eraslan?=)
Date: Sun, 25 Aug 2013 13:04:13 +0000
Subject: [issue18323] 'GzipFile' object has no attribute 'extrastart'
In-Reply-To: <1372418817.06.0.791452748439.issue18323@psf.upfronthosting.co.za>
Message-ID: <1377435853.26.0.143117767875.issue18323@psf.upfronthosting.co.za>


Changes by G?kcen Eraslan <gokcen.eraslan at gmail.com>:


----------
nosy: +gkcn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18323>
_______________________________________

From report at bugs.python.org  Sun Aug 25 15:04:49 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 25 Aug 2013 13:04:49 +0000
Subject: [issue13397] Option for XMLRPC clients to automatically transform
 Fault exceptions into standard exceptions
In-Reply-To: <1321218030.66.0.0560016220773.issue13397@psf.upfronthosting.co.za>
Message-ID: <1377435889.5.0.0036815476845.issue13397@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Here's a basic patch. I have two issues with it: the flag name used for enabling the exceptions seems too verbose (use_python_exceptions, I'm opened to new suggestions) and I don't know if the fallback to Fault exception if the remote exception is not known is the best way.

----------
keywords: +patch
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file31459/xmlrpc_builtin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13397>
_______________________________________

From report at bugs.python.org  Sun Aug 25 15:16:21 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 25 Aug 2013 13:16:21 +0000
Subject: [issue13397] Option for XMLRPC clients to automatically transform
 Fault exceptions into standard exceptions
In-Reply-To: <1321218030.66.0.0560016220773.issue13397@psf.upfronthosting.co.za>
Message-ID: <1377436581.58.0.112914056153.issue13397@psf.upfronthosting.co.za>


Donald Stufft added the comment:

-1

This essentially gives the ability for an XMLRPC server to crash any python code that interfaces with them unless you catch _every_ single exception including ones like SystemExit, KeyboardInterupt, SyntaxError, StopIteration etc.

An XMLRPC server is not a trusted resources and providing this option is akin to providing an option to unpickle arbitrary data received over the wire as well.

----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13397>
_______________________________________

From report at bugs.python.org  Sun Aug 25 15:49:21 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 25 Aug 2013 13:49:21 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1377438561.14.0.857922902321.issue18829@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree that the 2.7 message is somewhat confusing, but I'm not sure it is worth changing at this point in 2.7's life cycle.  

For Python3, the message is correct and unambiguous: a bytes object is not a string.

However, in 3.3, we have a regression:

rdmurray at hey:~/python/p34>python3.3 -c 'import csv; reader = csv.reader("foo", delimiter=b",")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: delimiter must be set

So that needs to be tracked down and fixed.

----------
keywords: +3.3regression, easy
nosy: +r.david.murray
stage:  -> needs patch
title: csv produces confusing error message for unexpected string encoding -> csv produces confusing error message when passed a non-string delimiter
versions: +Python 3.3, Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Sun Aug 25 15:51:43 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 25 Aug 2013 13:51:43 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1377438703.77.0.0486448809958.issue18829@psf.upfronthosting.co.za>


R. David Murray added the comment:

I forgot to address the comment about accepting bytes in python3: the delimiter really is a unicode character.  In python3, non-ASCII delimiters are handled correctly.  So no, it isn't a byte anymore, it really is a string.  Terry's comment about 'char' in the other issue does not apply to Python3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Sun Aug 25 15:55:51 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 25 Aug 2013 13:55:51 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377438951.42.0.297954043001.issue17741@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Looking at this more, the Parser/Builder abstraction in ET leaks badly, especially when it comes to incremental parsing. This manifests in (at least) two ways:

1. The parser accepted by iterparse has to use the ET-provided TreeBuilder, because the C implementation of TreeBuilder has undocumented fields and hooks used directly by the parser.
2. Even though iterparse & IncrementalParser accept a "parser" argument, it cannot be just any parser. This parser (in addition to using the ET TreeBuilder) must implement an undocumented and obscure _setevents method; this makes the original intent of the abstraction - hooking up arbitrary parsers to the interface, hard to follow.

To *really* fix this, all these capabilities have to be exposed as APIs. TreeBuilder has to support an explicit API for collecting and reporting events. XMLParser has to call into this API and either not have _setevents at all or have something public and documented. Note also that event hookup in the parser makes sense in a way, because we don't want events to be fired when not needed (for performance). So we don't want any parser to hook up all events for firing, and only incremental tree builders to collect them. So things aren't quite *so* simple. In addition, since iterparse (an existing, stable API of the module) expects a parser argument, it won't be easy creating an IncrementalTreeBuilder, because how would we let people using custom parsers with iterparse not change any code and yet keep things working?

--

Since the above presents considerable changes in the internals, to get *really* right - we do have a problem for the upcoming release because I'm not sure if anyone has the time or will to do it. However, the feature is interesting and useful, and the code is cleaner than it used to be. So I propose the following compromise that can serve us for the 3.4 release:

IncrementalParser stays, but its methods will be renamed to feed & close, which is consistent with the current XML parsing APIs (including xml.sax.xmlreader.IncrementalParser). In a future release, we may decide to create a IncrementalTreeBuilder anyway but then IncrementalParser can be layered on top of it and offered as a convenience.

--

To conclude, I don't think that when looked at as exposing an implementation detail of iterparse, IncrementalParser is so horrible. iterparse is already its own kind of thing somewhat alien to ET, but it's very useful and important. IncrementalParser is just replacing iterparse's "parse whole source" behavior with incremental feeds followed by a close. This is similar to the APIs xml.sax.xmlreader is exposing, so there is a consistency here. Solving "all the implementation problems" would certainly be great, but unfortunately no one seems to have time for this at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Aug 25 16:21:33 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 25 Aug 2013 14:21:33 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377440493.14.0.227750516647.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I attached a patch that removes the IncrementalParser class and merges its functionality into the _IterParseIterator. It thus retains most of the refactoring without adding new functionality and/or APIs.

I did not take a look if anything else from later changes needs to be reverted, neither did I update the documentation. I guess the newly added doc sections can just be deleted.

One thing that is still dubious is the requirement for the _setevents() method on the parser instance. That was already a flaw before Antoine's change, although it only hit if the C parser was used. It now affects both the Python parser and the C parser. It's not a regression because code that relies on it not being used is broken when it is being used. However, we should be aware that we are promoting a quirk to a visible API here. I don't see it as a real problem, given that it's an internal API (and thus an implementation detail), that's why I left it in. It should eventually be replaced by a proper setup based on the parser target.

----------
Added file: http://bugs.python.org/file31460/remove_IncrementalParser.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Aug 25 16:35:54 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 25 Aug 2013 14:35:54 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377441354.41.0.238206000185.issue17741@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Thanks for the effort, Stefan, but I still think IncrementalParser is worth keeping. It provides functionality that doesn't currently exist in ET, and IMHO this functionality is both important and useful.

Renaming its methods to feed & close kills the API naming inconsistency vs. XMLParser and SAX's IncrementalParser. As for future directions, having it does not add additional constrains to those that already exist because of iterparse accepting a "custom" XMLParser creates compatibility problems already.

For the latter, I think I can also beef up the documentation a bit to be more explicit (such as requiring the XMLParser provided to iterparse to derive from ET.XMLParser; otherwise, it just won't have the required _setevents).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Aug 25 16:37:25 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 25 Aug 2013 14:37:25 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377441445.78.0.63427088858.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

"""
TreeBuilder has to support an explicit API for collecting and reporting events. XMLParser has to call into this API and either not have _setevents at all or have something public and documented. Note also that event hookup in the parser makes sense in a way, because we don't want events to be fired when not needed (for performance). So we don't want any parser to hook up all events for firing, and only incremental tree builders to collect them.
"""

That's why I wanted to introduce the wrapper class. The idea was to extend the supported methods on the target object by those needed for iterparse(), specifically start_ns() and end_ns(). That way, the event callback setup would be just natural.


"""
In addition, since iterparse (an existing, stable API of the module) expects a parser argument, it won't be easy creating an IncrementalTreeBuilder, because how would we let people using custom parsers with iterparse not change any code and yet keep things working?
"""

Yep, that's a problem in the original design.

One way to fix it would be to allow changing the parser target after the creation of the parser, but before it actually started parsing. That could be an entirely internal feature that would then allow injecting the wrapper between the parser and the target after the fact. 

Given that the current support for using different parsers in iterparse() is pretty much non-existant, requiring the applicable parsers to support this feature would not be a regression, IMHO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Aug 25 16:45:49 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 25 Aug 2013 14:45:49 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377441949.33.0.412562110107.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> I still think IncrementalParser is worth keeping.

If you want to keep it at all cost, I think we should at least hide it behind a function (as with iterparse()). If it's implemented as a class, chances are that people will start relying on internals by inheriting from it. And we already know that those internals should eventually be removed completely. Eventually, that function should become a two-liner or so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Aug 25 16:50:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Aug 2013 14:50:13 +0000
Subject: [issue18830] Remove duplicates from a result of getclasstree()
Message-ID: <1377442213.69.0.00603799982208.issue18830@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

inspect.getclasstree() produces duplicated entities when it's argument contains duplicated classes. This happened when a module contains class aliases. For example `pydoc zipfile` outputs three entities for BadZipFile (BadZipfile and error are aliases of BadZipFile):

CLASSES
    builtins.Exception(builtins.BaseException)
        BadZipFile
        BadZipFile
        BadZipFile
        LargeZipFile
    builtins.object
        ZipFile
            PyZipFile
        ZipInfo
    
The proposed patch removes duplicates from a result of getclasstree().

----------
components: Library (Lib)
files: getclasstree_no_dups.patch
keywords: patch
messages: 196138
nosy: eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Remove duplicates from a result of getclasstree()
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file31461/getclasstree_no_dups.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18830>
_______________________________________

From report at bugs.python.org  Sun Aug 25 16:52:31 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 25 Aug 2013 14:52:31 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1377441949.33.0.412562110107.issue17741@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda9F7aC91mgapM6ZuQ+w+QhRDhTcFS9xj81-KX52xq79gw@mail.gmail.com>


Eli Bendersky added the comment:

> Stefan Behnel added the comment:
>
> > I still think IncrementalParser is worth keeping.
>
> If you want to keep it at all cost, I think we should at least hide it
> behind a function (as with iterparse()). If it's implemented as a class,
> chances are that people will start relying on internals by inheriting from
> it. And we already know that those internals should eventually be removed
> completely. Eventually, that function should become a two-liner or so.
>

I'm not sure I see how this is different from any class exposed by the
stdlib. Users can inherit it, rely on internals and then we can never
change its implementation? Surely this isn't true. We don't make guarantees
w.r.t. implementation and internals, only interfaces. Yes, Python lets you
monkey-patch anything, but this doesn't mean we can't build stable APIs in
Python and change implementation in the future.

So the only thing we should focus on is the *external* API of this class.
With only feed/close/events exposed, it seems logical that these can be
maintained even when the implementation changes.

Besides, such an incremental parser is a natural match for a class because
it has state and several methods that collectively act on that state.
Redesigning it as a function would be awkward. That said, if you have a
specific suggestion in mind that would be as natural to use in user code,
feel free to offer it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Aug 25 17:10:09 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Aug 2013 15:10:09 +0000
Subject: [issue16611] Cookie.py does not parse httponly or secure cookie flags
In-Reply-To: <1354654224.49.0.677339520856.issue16611@psf.upfronthosting.co.za>
Message-ID: <3cNKXJ3jFRz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 0dbe45697efc by R David Murray in branch '3.3':
#16611: BaseCookie now parses 'secure' and 'httponly' flags.
http://hg.python.org/cpython/rev/0dbe45697efc

New changeset f81846c2b746 by R David Murray in branch 'default':
Merge #16611: BaseCookie now parses 'secure' and 'httponly' flags.
http://hg.python.org/cpython/rev/f81846c2b746

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16611>
_______________________________________

From report at bugs.python.org  Sun Aug 25 17:11:00 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 25 Aug 2013 15:11:00 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1377443460.87.0.356825274745.issue18829@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

This is the preliminary patch to fix the error message.

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file31462/fix_error_message_reader_csv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Sun Aug 25 17:15:13 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 25 Aug 2013 15:15:13 +0000
Subject: [issue16611] Cookie.py does not parse httponly or secure cookie flags
In-Reply-To: <1354654224.49.0.677339520856.issue16611@psf.upfronthosting.co.za>
Message-ID: <1377443713.24.0.500486228729.issue16611@psf.upfronthosting.co.za>


R. David Murray added the comment:

Fix committed.  Thanks, Julien.

If you want to propose a new patch the makes the behavior more consistent/useful with respect to what browsers and servers actually do, feel free to propose one.  I'm going to close this issue, though.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16611>
_______________________________________

From report at bugs.python.org  Sun Aug 25 17:16:07 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 25 Aug 2013 15:16:07 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377443767.04.0.103309700474.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Actually, let me revise my rpevious comment. I think we should fake the new interface for now by adding a TreeEventBuilder that requires having its own TreeBuilder internally, instead of wrapping an arbitrary target. That way, we can avoid having to clean up the existing dependency of the C parser on the C-level TreeBuilder implementation.

Once this cleanup gets done, we can add the support for wrapping user defined targets as a feature.

So, basically, I propose to take the route that my TreeEventBuilder patch went, just with a simplified implementation. I'll see if I can cut down the patch to those essentials.

Would you be ok with something that uses the isinstance() hack in the parser?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Aug 25 17:16:41 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 25 Aug 2013 15:16:41 +0000
Subject: [issue18831] importlib.import_module() bypasses builtins.__import__
Message-ID: <1377443801.78.0.926402532335.issue18831@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Not sure if anyone really cares about this (I don't, but I figured I should at least let it be known), but I realized that importlib.import_module() bypasses builtins.__import__ by calling directly into the innards of importlib (specifically _gcd_import() which skips all the extra setup that __import__ entails and which is unnecessary for programmatic imports).

The docs for importlib.import_module() clearly state it uses importlib.__import__, but I'm not sure if anyone would be surprised if they replaced builtins.__import__ and found that importlib.import_module() was doing an end-run around their custom import system, especially since we are promoting importlib.import_module() over calling builtins.__import__ directly.

----------
components: Library (Lib)
messages: 196144
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: importlib.import_module() bypasses builtins.__import__
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18831>
_______________________________________

From report at bugs.python.org  Sun Aug 25 17:18:45 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 25 Aug 2013 15:18:45 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1377443925.81.0.417612054652.issue18829@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

This is the second alternative of the patch to fix the error message using different approach. I am not sure which one is better.

----------
Added file: http://bugs.python.org/file31463/fix_error_message_reader_csv_alternative_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Sun Aug 25 17:23:37 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 25 Aug 2013 15:23:37 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377444217.48.0.203741260505.issue17741@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Stefan, I don't mind looking at a working patch; however, it's not clear to me how you intend to solve the iterparse-accepting-a-custom-XMLParser problem. As for faking the new API, I don't know if that's a good idea because we're not yet sure what that new API is. I agree with your earlier observation that we must begin by refactoring the internals (in the C implementation) and defining cleaner APIs for existing objects. Once we do that, we may have better ideas about the ideal API for incremental parsing / event building. But that's a large job.

Again, fully working patches will be considered. Lacking those, I'm inclined to go with the interim solution proposed in http://bugs.python.org/issue17741#msg196133

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Aug 25 17:28:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Aug 2013 15:28:06 +0000
Subject: [issue18323] 'GzipFile' object has no attribute 'extrastart'
In-Reply-To: <1372418817.06.0.791452748439.issue18323@psf.upfronthosting.co.za>
Message-ID: <1377444486.97.0.893389585275.issue18323@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

We can add in readline() the check that GzipFile is opened in read mode. However it will slowdown readline(). See alse issue18003.

Note that the original example is not correct. zlib.compress() doesn't produce legal Gzip file.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18323>
_______________________________________

From report at bugs.python.org  Sun Aug 25 17:33:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Aug 2013 15:33:23 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1377444803.1.0.940164343853.issue18829@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Sun Aug 25 17:35:35 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 25 Aug 2013 15:35:35 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377444935.16.0.829001277558.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> fully working patches will be considered

Let me remind you that it's not me who wants this feature so badly.


> As for faking the new API, I don't know if that's a good idea because we're not yet sure what that new API is.

If that's your concern, then I suggest not adding the feature at all, as long as we don't know if we can (or should) keep up the IncrementalParser facade with the revised implementation.

For example, can it accept a user defined parser instance as input or not? Can it accept a user defined parser target as input? Can it wrap it or would it maybe have to inherit from a TreeBuilder? Should it be a class or a helper function? I don't see how the interface you proposed leaves less questions open than what I am proposing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Aug 25 17:37:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Aug 2013 15:37:45 +0000
Subject: [issue18647] re.error: nothing to repeat
In-Reply-To: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>
Message-ID: <1377445065.74.0.00399244003507.issue18647@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18647>
_______________________________________

From report at bugs.python.org  Sun Aug 25 18:13:10 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 25 Aug 2013 16:13:10 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1377444935.16.0.829001277558.issue17741@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda9sbdMCR3sHu-wEf9JXdUexMGguni9ZUDWJQLkEFcTCRw@mail.gmail.com>


Eli Bendersky added the comment:

> > As for faking the new API, I don't know if that's a good idea because
> we're not yet sure what that new API is.
>
> If that's your concern, then I suggest not adding the feature at all, as
> long as we don't know if we can (or should) keep up the IncrementalParser
> facade with the revised implementation.
>
> For example, can it accept a user defined parser instance as input or not?
> Can it accept a user defined parser target as input? Can it wrap it or
> would it maybe have to inherit from a TreeBuilder? Should it be a class or
> a helper function? I don't see how the interface you proposed leaves less
> questions open than what I am proposing.
>

This is an existing API within ET:

  xml.etree.ElementTree.iterparse(source, events=None, parser=None)

The parser argument is limited: it can't use a custom TreeBuilder. It also
must provide _setevents, so either inherit from XMLParser or just provide
that method in another way [I'll try to improve the documentation to make
all of this explicit]. Whatever we say in this issue, iterparse is here to
stay.

  class xml.etree.ElementTree.IncrementalParser(events=None, parser=None)

Is the new class. Its interface combines iterparse and XMLParser - so it is
subject to the same constraints. It also serves as a basis of iterparse's
implementation.

If the internals are changed, the constrains we'll be subject to with
iterparse will be the same for IncrementalParse; no more. For example, the
solution can be substituting the target of the given parser to the "event
builder" target. Since we force the target to be TreeBuilder now, it should
not really break user code because that part isn't custom. But whatever the
solution is, it will be the same solution for both IncrementalParser and
iterparse.

Also, even if the new approach is implemented in the next release,
IncrementalParser can stay as a simple synonym to
XMLParser(target=EventBuilder(...)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Aug 25 18:18:25 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Aug 2013 16:18:25 +0000
Subject: [issue18817] Got resource warning when running Lib/aifc.py
In-Reply-To: <1377234795.91.0.783821607183.issue18817@psf.upfronthosting.co.za>
Message-ID: <3cNM344wWfz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset e3eec06aa12e by Serhiy Storchaka in branch '2.7':
Issue #18817: Fix a resource warning in Lib/aifc.py demo.
http://hg.python.org/cpython/rev/e3eec06aa12e

New changeset e0c33e0c0483 by Serhiy Storchaka in branch '3.3':
Issue #18817: Fix a resource warning in Lib/aifc.py demo.
http://hg.python.org/cpython/rev/e0c33e0c0483

New changeset 1da223c1b7ed by Serhiy Storchaka in branch 'default':
Issue #18817: Fix a resource warning in Lib/aifc.py demo.  Patch by
http://hg.python.org/cpython/rev/1da223c1b7ed

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18817>
_______________________________________

From report at bugs.python.org  Sun Aug 25 18:24:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Aug 2013 16:24:53 +0000
Subject: [issue18817] Got resource warning when running Lib/aifc.py
In-Reply-To: <1377234795.91.0.783821607183.issue18817@psf.upfronthosting.co.za>
Message-ID: <1377447893.67.0.458757214165.issue18817@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your patch Vajrasky.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18817>
_______________________________________

From report at bugs.python.org  Sun Aug 25 18:29:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Aug 2013 16:29:41 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1376691835.07.0.666456900735.issue18763@psf.upfronthosting.co.za>
Message-ID: <3cNMJ51m4Hz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset f2b023135b1b by Charles-Fran?ois Natali in branch '2.7':
Issue #18763: subprocess: The file descriptors are now closed after calling the
http://hg.python.org/cpython/rev/f2b023135b1b

New changeset 4c52d4bac03c by Charles-Fran?ois Natali in branch '3.3':
Issue #18763: subprocess: The file descriptors are now closed after calling the
http://hg.python.org/cpython/rev/4c52d4bac03c

New changeset 748a5d39e7ce by Charles-Fran?ois Natali in branch 'default':
Issue #18763: subprocess: The file descriptors are now closed after calling the
http://hg.python.org/cpython/rev/748a5d39e7ce

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Sun Aug 25 19:14:49 2013
From: report at bugs.python.org (Tal Weiss)
Date: Sun, 25 Aug 2013 17:14:49 +0000
Subject: [issue18685] Restore re performance to pre-PEP393 level
In-Reply-To: <1375967417.95.0.0303828296889.issue18685@psf.upfronthosting.co.za>
Message-ID: <1377450889.68.0.965226050794.issue18685@psf.upfronthosting.co.za>


Changes by Tal Weiss <tal at evature.com>:


----------
nosy: +Tal.Weiss

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18685>
_______________________________________

From report at bugs.python.org  Sun Aug 25 19:26:23 2013
From: report at bugs.python.org (Tal Weiss)
Date: Sun, 25 Aug 2013 17:26:23 +0000
Subject: [issue18832] New regex module degrades re performance
Message-ID: <1377451583.44.0.0818025300658.issue18832@psf.upfronthosting.co.za>


New submission from Tal Weiss:

All tests I ran comparing timing of the new regex module relative to the old re module showed significant slower performance.
I'm attaching test code with regular expressions from our production server.
Tested on Python 2.7, 64 bit Linux + 64 bit Windows 7.
regex #0 match success = 0.16530585289 seconds
re    #0 match success = 0.0977821350098 seconds
regex #0 match failure = 0.460994958878 seconds
re    #0 match failure = 0.249558925629 seconds
regex #1 match success = 0.0802597999573 seconds
re    #1 match success = 0.0348429679871 seconds
regex #1 match failure = 0.224385023117 seconds
re    #1 match failure = 0.104065895081 seconds
regex #2 match success = 0.0307199954987 seconds
re    #2 match success = 0.0200390815735 seconds
regex #2 match failure = 0.0253899097443 seconds
re    #2 match failure = 0.0161480903625 seconds

----------
components: Regular Expressions
files: play_regex.py
messages: 196153
nosy: Tal.Weiss, ezio.melotti, haypo, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: New regex module degrades re performance
type: performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31464/play_regex.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18832>
_______________________________________

From report at bugs.python.org  Sun Aug 25 19:48:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Aug 2013 17:48:36 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <3cNP374Zmmz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset becbb65074e1 by Antoine Pitrou in branch 'default':
Issue #18808: Non-daemon threads are now automatically joined when a sub-interpreter is shutdown (it would previously dump a fatal error).
http://hg.python.org/cpython/rev/becbb65074e1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Aug 25 19:50:11 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 25 Aug 2013 17:50:11 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377453011.5.0.0706242105167.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> Also, even if the new approach is implemented in the next release,
IncrementalParser can stay as a simple synonym to
XMLParser(target=EventBuilder(...)).

No it can't. According to your signature, it accepts a parser instance as input. So it can't just create a new one internally.


"""
This is an existing API within ET:

  xml.etree.ElementTree.iterparse(source, events=None, parser=None)

The parser argument is limited: it can't use a custom TreeBuilder. It also
must provide _setevents, so either inherit from XMLParser or just provide
that method in another way [I'll try to improve the documentation to make
all of this explicit]. Whatever we say in this issue, iterparse is here to
stay.
"""

I agree. However, I can't see why this should constrain us when adding a new API. Sure, the current implementation puts certain restrictions on the input. But I see that as an advantage, not as a constraint. It's currently broken in what it accepts as input, so we are free to change that aspect later on. And we can now try to get it right for the new API that we add.

Also, AFAICT, passing a parser into iterparse() is a very rare thing to do, if only because it doesn't really work, so the likelyhood of breaking code is very limited (I'm not saying we should, just thinking about the impact). Note that lxml.etree doesn't currently support this at all.


Just to throw some more ideas into the wild, what do you think about making this an inherent feature of the XMLParser class itself? That can be done now, without major changes to the underlying code. It could be enabled by a new keyword argument "collect_events=None" that you could pass into the constructor in order to define the set of events. The "events()" method would always be available, but would only yield events if there actually are any. Otherwise, it would just terminate and be done. So, unless you pass it a set of event names at init time, the parser wouldn't collect events and you wouldn't get any out of it. Sounds like a clean interface to me.

Collecting the events would work in the same way as it currently works, i.e. it would call the target's start() method, and whatever that returns will be added as value to the events as a tuple ("start", target_return_value). That means that it's up to the parser target to determine what the event iteration returns. Can be elements, can be None, can be something else.

As for backwards compatibility with iterparse(), I don't see a problem with officially documenting iterparse() as requiring an XMLParser if a parser is provided, and as reconfiguring that parser to its needs. It already does that anyway and it currently doesn't work for anything but an XMLParser.


Also, on a related note, we might (!) consider the addition of the _setevents() method a bug in CPython 3.3. It didn't exist in ElementTree before it was merged with cElementTree. Instead, the expected interface was (apparently) that the parser that is passed in has a "_parser" attribute that holds an Expat parser, and that iterparse() could reconfigure according for itself. Both are not public APIs and even differed between ET and cET, so I don't see any harm being done, but it would be good to have one way to do it. OTOH, if that way is _setevents(), then be it. The advantage would be that this interface is at least independent of Expat and could potentially be implemented by other types of parsers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Aug 25 19:50:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Aug 2013 17:50:26 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377453026.29.0.551627791271.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, I've committed the first patch.

----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Aug 25 20:05:00 2013
From: report at bugs.python.org (Alex Volkov)
Date: Sun, 25 Aug 2013 18:05:00 +0000
Subject: [issue18728] Increased test coverage for filecmp.py
In-Reply-To: <1376411694.99.0.620922615046.issue18728@psf.upfronthosting.co.za>
Message-ID: <1377453900.9.0.899218056568.issue18728@psf.upfronthosting.co.za>


Alex Volkov added the comment:

HI Vajrasky,

I fixed the typo in a comment and removed WIN32 constant definition from the code.

I looked at the existing tearDown method, on line 79, it calls shutil.rmtree on a directory above the files/directories I'm writing my test files, so the statements and the end of each function or combining these statements in a cleanup function is redundant, so I removed them.

Alex.

----------
Added file: http://bugs.python.org/file31465/test_filecmp_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18728>
_______________________________________

From report at bugs.python.org  Sun Aug 25 20:38:21 2013
From: report at bugs.python.org (Alex Volkov)
Date: Sun, 25 Aug 2013 18:38:21 +0000
Subject: [issue18833] Increased test coverage for telnetlib
Message-ID: <1377455901.74.0.558860424398.issue18833@psf.upfronthosting.co.za>


New submission from Alex Volkov:

This issue splits up an unrelated patch from issue 18731
http://bugs.python.org/issue18731

Added a test for telnetlib increasing test coverage.

Updated with the changes from code review of issue 18731
http://bugs.python.org/review/18731/patch/8923/33000

----------
components: Tests
files: test_telnetlib_getter.patch
keywords: patch
messages: 196158
nosy: Alex.Volkov
priority: normal
severity: normal
status: open
title: Increased test coverage for telnetlib
versions: Python 3.4
Added file: http://bugs.python.org/file31466/test_telnetlib_getter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18833>
_______________________________________

From report at bugs.python.org  Sun Aug 25 20:43:49 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 25 Aug 2013 18:43:49 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1376691835.07.0.666456900735.issue18763@psf.upfronthosting.co.za>
Message-ID: <1377456229.96.0.652217819271.issue18763@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Sun Aug 25 20:49:04 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 25 Aug 2013 18:49:04 +0000
Subject: [issue18832] New regex module degrades re performance
In-Reply-To: <1377451583.44.0.0818025300658.issue18832@psf.upfronthosting.co.za>
Message-ID: <1377456544.88.0.447251095165.issue18832@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

The 'regex' module is not part of the CPython distribution, so it's not covered by this tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18832>
_______________________________________

From report at bugs.python.org  Sun Aug 25 21:05:37 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 25 Aug 2013 19:05:37 +0000
Subject: [issue18832] New regex module degrades re performance
In-Reply-To: <1377451583.44.0.0818025300658.issue18832@psf.upfronthosting.co.za>
Message-ID: <1377457537.31.0.157999661932.issue18832@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18832>
_______________________________________

From report at bugs.python.org  Sun Aug 25 21:33:46 2013
From: report at bugs.python.org (Ryan Gonzalez)
Date: Sun, 25 Aug 2013 19:33:46 +0000
Subject: [issue18834] Add Clang to distutils to build C/C++ extensions
Message-ID: <1377459226.15.0.775642351727.issue18834@psf.upfronthosting.co.za>


New submission from Ryan Gonzalez:

A have created to patches(for ccompiler.py and cygwinccompiler.py) to add Clang as a compiler in distutils. The patches are here:

ccompiler.py: http://pastebin.com/yMGYys0P
cygwinccompiler.py: http://pastebin.com/a49qNP6n

I used the distutils version from Mercurial.

----------
assignee: eric.araujo
components: Distutils
messages: 196160
nosy: Ryan.Gonzalez, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Add Clang to distutils to build C/C++ extensions
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18834>
_______________________________________

From report at bugs.python.org  Sun Aug 25 22:41:44 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 25 Aug 2013 20:41:44 +0000
Subject: [issue17759] test_urllibnet.test_bad_address() fails on Ubuntu 13.04
In-Reply-To: <1366120788.32.0.41011359208.issue17759@psf.upfronthosting.co.za>
Message-ID: <1377463304.34.0.481154129122.issue17759@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Apparently this has been fixed upstream in glibc:
http://sourceware.org/bugzilla/show_bug.cgi?id=15339
There's also a related discussion at http://sourceware.org/bugzilla/show_bug.cgi?id=15726

Barry, can this be closed?

----------
nosy: +ezio.melotti
type:  -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17759>
_______________________________________

From report at bugs.python.org  Sun Aug 25 22:56:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 25 Aug 2013 20:56:00 +0000
Subject: [issue17759] test_urllibnet.test_bad_address() fails on Ubuntu 13.04
In-Reply-To: <1366120788.32.0.41011359208.issue17759@psf.upfronthosting.co.za>
Message-ID: <1377464160.59.0.935929193837.issue17759@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Works here on 13.04.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17759>
_______________________________________

From report at bugs.python.org  Sun Aug 25 23:15:53 2013
From: report at bugs.python.org (Yavor)
Date: Sun, 25 Aug 2013 21:15:53 +0000
Subject: [issue17759] test_urllibnet.test_bad_address() fails on Ubuntu 13.04
In-Reply-To: <1366120788.32.0.41011359208.issue17759@psf.upfronthosting.co.za>
Message-ID: <1377465353.93.0.506130875482.issue17759@psf.upfronthosting.co.za>


Yavor added the comment:

Within this note https://sourceware.org/glibc/wiki/NameResolver about getaddrinfo():
"In case there was a *negative* answer it's unclear what should be returned."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17759>
_______________________________________

From report at bugs.python.org  Sun Aug 25 23:17:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Aug 2013 21:17:51 +0000
Subject: [issue18833] Increased test coverage for telnetlib
In-Reply-To: <1377455901.74.0.558860424398.issue18833@psf.upfronthosting.co.za>
Message-ID: <3cNThZ5C0rz7LjY@mail.python.org>


Roundup Robot added the comment:

New changeset 6b33d786b46d by Ezio Melotti in branch '2.7':
#18833: add a test for test_telnetlib.  Patch by Alex Volkov.
http://hg.python.org/cpython/rev/6b33d786b46d

New changeset 1b42e483e520 by Ezio Melotti in branch '3.3':
#18833: add a test for test_telnetlib.  Patch by Alex Volkov.
http://hg.python.org/cpython/rev/1b42e483e520

New changeset a4ec11e0fb87 by Ezio Melotti in branch 'default':
#18833: merge with 3.3.
http://hg.python.org/cpython/rev/a4ec11e0fb87

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18833>
_______________________________________

From report at bugs.python.org  Sun Aug 25 23:19:31 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 25 Aug 2013 21:19:31 +0000
Subject: [issue18833] Increased test coverage for telnetlib
In-Reply-To: <1377455901.74.0.558860424398.issue18833@psf.upfronthosting.co.za>
Message-ID: <1377465571.74.0.618030919983.issue18833@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

Could you also sign the contributor agreement?
http://www.python.org/psf/contrib/contrib-form/

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18833>
_______________________________________

From report at bugs.python.org  Sun Aug 25 23:25:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 25 Aug 2013 21:25:29 +0000
Subject: [issue17759] test_urllibnet.test_bad_address() fails on Ubuntu 13.04
In-Reply-To: <1366120788.32.0.41011359208.issue17759@psf.upfronthosting.co.za>
Message-ID: <1377465929.07.0.458454910793.issue17759@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

FTR this got "fixed" (i.e. the timeout is ignored) in 3.3 (b17662fc41af) and default (6f8fef208958), but on 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17759>
_______________________________________

From report at bugs.python.org  Sun Aug 25 23:35:33 2013
From: report at bugs.python.org (Jeremy Kloth)
Date: Sun, 25 Aug 2013 21:35:33 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377466533.46.0.194997744811.issue17741@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Aug 25 23:54:43 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 25 Aug 2013 21:54:43 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1377467682.99.0.0293140168972.issue8713@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The new tests produce a few warnings:
$ ./python -m test -uall test_multiprocessing_spawn
[1/1] test_multiprocessing_spawn
Using start method 'spawn'
Warning -- threading._dangling was modified by test_multiprocessing_spawn
Warning -- multiprocessing.process._dangling was modified by test_multiprocessing_spawn

$ ./python -m test -uall -v -j2 test_multiprocessing_fork
OK (skipped=4)
Warning -- threading._dangling was modified by test_multiprocessing_fork
Warning -- multiprocessing.process._dangling was modified by test_multiprocessing_fork
1 test altered the execution environment:
    test_multiprocessing_fork

I've seen test_multiprocessing_forkserver giving warnings too, while running the whole test suite, but can't reproduce them while running it alone.  The warnings seems quite similar though, so a single fix might resolve the problem with all the tests.


The "Using start method '...'" should also be displayed only when the tests are run in verbose mode.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Mon Aug 26 00:10:21 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 25 Aug 2013 22:10:21 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377468621.32.0.788656696359.issue17741@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I actually have another idea. Since we all agree that passing a custom "parser" to iterparse is dubious, IncrementalParser does not have to do that at all. This will make it a much more future-proof API. So its signature can be:

  class xml.etree.ElementTree.IncrementalParser(events=None)

The only remaining question is how will iterparse then work based on IncrementalParser (since iterparse does accept a parser). iterparse can just set the parser on IncrementalParser after creating it - it's an internal contract that does not have to be exposed.

This will be better than the current approach in terms of future-proofing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 00:34:02 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Aug 2013 22:34:02 +0000
Subject: [issue18803] Fix more typos in .py files
In-Reply-To: <1377119764.79.0.128935070292.issue18803@psf.upfronthosting.co.za>
Message-ID: <3cNWNT4Gl6z7Ljh@mail.python.org>


Roundup Robot added the comment:

New changeset 33b156e118c0 by Ezio Melotti in branch '2.7':
#18803: fix more typos.  Patch by F?vry Thibault.
http://hg.python.org/cpython/rev/33b156e118c0

New changeset c57d99a8fc42 by Ezio Melotti in branch '3.3':
#18803: fix more typos.  Patch by F?vry Thibault.
http://hg.python.org/cpython/rev/c57d99a8fc42

New changeset 6b28bfff9204 by Ezio Melotti in branch 'default':
#18803: merge with 3.3.
http://hg.python.org/cpython/rev/6b28bfff9204

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18803>
_______________________________________

From report at bugs.python.org  Mon Aug 26 00:35:06 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 25 Aug 2013 22:35:06 +0000
Subject: [issue18803] Fix more typos in .py files
In-Reply-To: <1377119764.79.0.128935070292.issue18803@psf.upfronthosting.co.za>
Message-ID: <1377470106.04.0.570735144885.issue18803@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18803>
_______________________________________

From report at bugs.python.org  Mon Aug 26 04:06:22 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 26 Aug 2013 02:06:22 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1377482782.87.0.694934195964.issue18829@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

I realized there was a test that was similar with my test. I merged them into one test.

I think the alternative is better than the original patch so I updated the alternative patch only.

----------
Added file: http://bugs.python.org/file31467/fix_error_message_reader_csv_alternative_1_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Mon Aug 26 04:21:26 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Aug 2013 02:21:26 +0000
Subject: [issue13397] Option for XMLRPC clients to automatically transform
 Fault exceptions into standard exceptions
In-Reply-To: <1321218030.66.0.0560016220773.issue13397@psf.upfronthosting.co.za>
Message-ID: <1377483686.68.0.308890248505.issue13397@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Do you have a suggestion for white-listing or a fault-to-exception mapper?

The current API makes faults difficult to use in Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13397>
_______________________________________

From report at bugs.python.org  Mon Aug 26 04:32:37 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 26 Aug 2013 02:32:37 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1377484357.41.0.320654566955.issue18720@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Serhiy, patch 5 addresses your latest review. Thanks. As for _family_converter, let's see how common this really becomes. Based on one use-case I wouldn't add it to Enum itself. But if we see it gets repeated in many places, we can.

----------
Added file: http://bugs.python.org/file31468/socket-intenum-af.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Mon Aug 26 04:32:51 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Aug 2013 02:32:51 +0000
Subject: [issue18835] Add aligned memroy variants to the suite of PyMem
 functions/macros
Message-ID: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Currently, we have little to no control over the alignment of memory returned by the PyMem functions.   

I suggest variants such as PyMem_Alloc32(n) and PyMem_Alloc64(n) to return suitably aligned data blocks.

GNU C provides memalign() for this purpose:  http://www.delorie.com/gnu/docs/glibc/libc_31.html
and the Microsoft C compiler has _aligned_malloc() for the same purpose: http://msdn.microsoft.com/en-us/library/8z34s9c6%28VS.80%29.aspx

A principal use case would be PyObject pointers where we want to keep all or most of the data fields in the same cache line (i.e. the fields for list, tuple, dict, and set objects).

Deques would benefit from having the deque blocks aligned to 64byte boundaries and never crossing page boundaries.  Set entries would benefit from 32byte alignment.

----------
components: Interpreter Core
messages: 196174
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add aligned memroy variants to the suite of PyMem functions/macros
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Aug 26 04:35:49 2013
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 26 Aug 2013 02:35:49 +0000
Subject: [issue13397] Option for XMLRPC clients to automatically transform
 Fault exceptions into standard exceptions
In-Reply-To: <1321218030.66.0.0560016220773.issue13397@psf.upfronthosting.co.za>
Message-ID: <1377484549.14.0.671570782094.issue13397@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Well you could possibly whitelist some exceptions although I still think that's ultimately a bad idea because it means to prevent the remote server (or someone in the middle of the connection) from being able to crash your program with an arbitrary exception it means you'd need to catch _all_ the whitelisted exceptions.

You could possibly make exception subclasses that subclass the Fault exception _and_ whatever exception the remote server threw so you could get the advantages of both sides.

One flaw in this though is that the remote server doesn't need to be in Python, so trying to map errors from the remote server into python exceptions is only going to work *if* the remote server is in Python (and even then only if the exception is a built in one and not any other exception). Yanking the text out of the error message and trying to turn that into an exception is fundamentally wrong I believe. It's a bit like reading the response body of a HTTP request and doing simple string searching to raise arbitrary exceptions (In fact that's basically exactly what it is).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13397>
_______________________________________

From report at bugs.python.org  Mon Aug 26 04:38:03 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Aug 2013 02:38:03 +0000
Subject: [issue18835] Add aligned memroy variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1377484683.53.0.33160904829.issue18835@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I should also mention posix_memalign() for Unix/Linux systems.

On systems without a clean way to provide aligned memory, we can always fall back to regular malloc().   The API wouldn't guarantee alignment but would comply when possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Aug 26 05:33:57 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 26 Aug 2013 03:33:57 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377488037.22.0.942408722645.issue17741@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I had a chat with Nick about this, and a variation of the proposal in http://bugs.python.org/msg196133 seems acceptable to us both. To summarize, here's what goes into 3.4.

* The class will be named EventParser.
Rationale: The Incremental in IncrementalParser is ambiguous, because it's not clear which side is incremental - input or output. In addition, XMLParser is already "incremental" in the sense that it has a feed() method. EventParser is (although not a perfect name) clearer w.r.t what it does - produces events from the parsing. Another (milder) reason is to avoid confusing duplication with xml.sax.xmlreader.IncrementalParser, which is somewhat different. Yet another is that if we eventually figure out how to implement this in a parser target, a great name for that target would be EventBuilder, which is a logical building block for EventParser.

* It will *not* accept a "parser" argument in the constructor.
Rationale: the parser argument of iterparse is broken anyway. This will make it much easier to modify the implementation of EventParser in the future when the C internals are fixed w.r.t problems mentioned in this issue.

* iterparse's "parser" argument will be deprecated, and the documentation will be more detailed w.r.t to the limitations on its current "parser" argument (the limitations are there in the code, but they're not fully documented).

* EventParser's input-side methods will be named feed and close, to be more consistent with existing XML APIs (both XMLParser and xml.sax.xmlreader.IncrementalParser).

* EventParser's output-side method will be called "read_events".
Rationale: "read_" helps convey that the consumption of events is destructive. A possible future addition of a complementary, non-destructive API - "peek_events" will be considered.

* Documentation will be modified to clarify exactly how EventParser differs from XMLParser and iterparse.

Also, new issue(s) will be created to address fixing specific implementation problems.

----

Nick, feel free to add/correct if I misunderstood or forgot something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 05:39:36 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 26 Aug 2013 03:39:36 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1377488037.22.0.942408722645.issue17741@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dvwYCPF=0xuOrBEdUoSRBhQWRH+8rFazyLmhwYbcm=vA@mail.gmail.com>


Nick Coghlan added the comment:

Sounds good to me :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 06:52:06 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 26 Aug 2013 04:52:06 +0000
Subject: [issue17410] Generator-based HTMLParser
In-Reply-To: <1363198192.05.0.796177094664.issue17410@psf.upfronthosting.co.za>
Message-ID: <1377492726.63.0.697688266691.issue17410@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The event generation API for ElementTree being discussed in issue 17741 is potentially relevant here.

I think that style of API is preferable, as it doesn't alter how data is fed into the parser, just how it is extracted.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17410>
_______________________________________

From report at bugs.python.org  Mon Aug 26 07:40:44 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 26 Aug 2013 05:40:44 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377495644.65.0.193687256987.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Hmm, did you look at my last comment at all? It solves both the technical issues and the API issues very nicely and avoids any problems of potential future changes. Let me quickly explain why.

The feature in question depends on two existing parts of the API: the event generation of the parser, and the return values of the parser target (e.g. a tree builder). So there are really only three places where this feature makes sense, both technically and API-wise.

1) in the target
2) in the parser
3) between parser and target

Note how a separate class is ruled out right from the start by the fact that the feature lives somehwere between parser and target. It's an inherent part of the existing design already (and of the implementation, BTW), so I don't see how adding a separate thing to control it makes any sense.

1) is impossible because the target is user provided and we do not control it
2) works fine because the parser controls both the call to the target and its return value
3) would be nice (and was my original favourite) but is hard to do with the current implementation and requires further changes to the API of parser targets

So 2) is the choice that remains.


> It will *not* accept a "parser" argument in the constructor.

Yes, I had also arrived at that point yesterday. However, I then reconsidered why there has to be a separate class in the first place. Basically, if you can't allow users to control the parser because the feature is already part of the parser, then why expose it as something that appears to be independent? Adding it to the existing API is very clean and exposes the feature where users would look for it.


> EventParser's output-side method will be called "read_events".

Makes sense to me. I had also considered that problem but didn't come up with a good name yet. "read_events" reads better than plain "events".


> The class will be named EventParser.

Obviously because it's parsing Events, as opposed to the XMLParser, which parses XML, or the HTMLParser, which parses HTML, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 08:11:49 2013
From: report at bugs.python.org (Sworddragon)
Date: Mon, 26 Aug 2013 06:11:49 +0000
Subject: [issue18836] Potential race condition in exceptions
Message-ID: <1377497509.71.0.034362539056.issue18836@psf.upfronthosting.co.za>


New submission from Sworddragon:

On a try/except-block if an exception raises (for example KeyboardInterrupt) the except block could cause another exception and if this block tries to catch it too the nested except block could cause another exception again. This goes into an unlimited recursion.

In the attachments is an example of such a problem (race_condition_fast.py). But as it is called a "race condition" it is nearly impossible to reproduce it by a human. For this case I have adjusted the example (race_condition_slow.py). The third CTRL + C will cause a KeyboardInterrupt.

----------
components: Interpreter Core
files: race_condition_fast.py
messages: 196181
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Potential race condition in exceptions
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31469/race_condition_fast.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18836>
_______________________________________

From report at bugs.python.org  Mon Aug 26 08:12:37 2013
From: report at bugs.python.org (Sworddragon)
Date: Mon, 26 Aug 2013 06:12:37 +0000
Subject: [issue18836] Potential race condition in exceptions
In-Reply-To: <1377497509.71.0.034362539056.issue18836@psf.upfronthosting.co.za>
Message-ID: <1377497557.28.0.62516673748.issue18836@psf.upfronthosting.co.za>


Changes by Sworddragon <sworddragon2 at aol.com>:


Added file: http://bugs.python.org/file31470/race_condition_slow.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18836>
_______________________________________

From report at bugs.python.org  Mon Aug 26 08:19:44 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 26 Aug 2013 06:19:44 +0000
Subject: [issue18823] Idle: use pipes instead of sockets to talk with user
 subprocess
In-Reply-To: <1377300904.13.0.124289838176.issue18823@psf.upfronthosting.co.za>
Message-ID: <1377497984.54.0.541473216395.issue18823@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18823>
_______________________________________

From report at bugs.python.org  Mon Aug 26 08:29:06 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Aug 2013 06:29:06 +0000
Subject: [issue18836] Potential race condition in exceptions
In-Reply-To: <1377497509.71.0.034362539056.issue18836@psf.upfronthosting.co.za>
Message-ID: <1377498546.84.0.99094609164.issue18836@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> The third CTRL + C will cause a KeyboardInterrupt.

This is expected.  The first ctrl+c interrupts the first sleep and goes in the second try, executing the second sleep.  The second ctrl+c interrupts the second sleep and goes in the second except where it finds the third sleep.  Here a third ctrl+c will interrupt the sleep and since this line is not in a try block nothing will catch the KeyboardInterrupt.

Are you saying that if the user keeps hitting ctrl+c you would need an endless chain of nested try/except in order to catch them all?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18836>
_______________________________________

From report at bugs.python.org  Mon Aug 26 08:32:52 2013
From: report at bugs.python.org (Sworddragon)
Date: Mon, 26 Aug 2013 06:32:52 +0000
Subject: [issue18836] Potential race condition in exceptions
In-Reply-To: <1377497509.71.0.034362539056.issue18836@psf.upfronthosting.co.za>
Message-ID: <1377498772.4.0.358488764949.issue18836@psf.upfronthosting.co.za>


Sworddragon added the comment:

> Are you saying that if the user keeps hitting ctrl+c you would need an endless chain of nested try/except in order to catch them all?

Correct. For example if I want to show the user the message "Aborted" instead of a huge exception if he hits CTRL + C another KeyboardInterrupt could appear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18836>
_______________________________________

From report at bugs.python.org  Mon Aug 26 08:56:10 2013
From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=)
Date: Mon, 26 Aug 2013 06:56:10 +0000
Subject: [issue18837] multiprocessing.reduction is undocumented
Message-ID: <1377500170.46.0.281746133519.issue18837@psf.upfronthosting.co.za>


New submission from Tomi Pievil?inen:

In older versions (2.x, 3.2, 3.3) multiprocessing.reduction was only mentioned in a one example, with a one comment after it. In the 3.4dev documentation even this was dropped.

----------
assignee: docs at python
components: Documentation
messages: 196184
nosy: docs at python, tpievila
priority: normal
severity: normal
status: open
title: multiprocessing.reduction is undocumented
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18837>
_______________________________________

From report at bugs.python.org  Mon Aug 26 08:58:14 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Aug 2013 06:58:14 +0000
Subject: [issue18837] multiprocessing.reduction is undocumented
In-Reply-To: <1377500170.46.0.281746133519.issue18837@psf.upfronthosting.co.za>
Message-ID: <1377500294.87.0.0394037735045.issue18837@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +jnoller, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18837>
_______________________________________

From report at bugs.python.org  Mon Aug 26 09:47:16 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 26 Aug 2013 07:47:16 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377503236.57.0.722454117659.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

BTW, I also like how short and clean iterparse() becomes when you move this feature into the parser. It's basically just a convenience function that does read(), feed(), and yield-from. Plus the usual bit of bolerplate code, obviously.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 09:49:29 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 26 Aug 2013 07:49:29 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377503369.85.0.652017924157.issue17741@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Eli's summary left out an exchange between us that happened after he'd already written the summary - he pointed out the same problem with the EventParser name that you noticed: it's really an alternative XMLParser that exposes read_events(), rather than an event parser. So a completely different name like "EventScanner" or "EventStream" may be more appropriate. (I quite like EventStream, since it further suggests the destructive nature of read_events()).

As for why we think it's worth keeping this as a separate API, it's really about turning XMLParser's "push" API for events (where the events are pushed into the target object by the parser calling the appropriate methods), into an iterparse style pull API where the events can be retrieved via calls to read_events().

The back end implementation for the event streaming API *should* be a custom target object combined with a regular XMLParser object, but there are implementation issues currently preventing that.

We also discussed adding the event streaming interface directly to XMLParser, but I agreed with Eli that it's worth keeping that base API simple, especially since in the long run we want the new class to just be a convenience API for combining XMLParser and a custom target object, even if it can't be implemented that way right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 09:50:41 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 26 Aug 2013 07:50:41 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377503441.48.0.682794762275.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> iterparse's "parser" argument will be deprecated

No need to do that. Update the docs, yes, but otherwise keep the possibility to improve the implementation later on, without going through a deprecation + dedeprecation cycle. That would just confuse users IMHO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 09:58:05 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 26 Aug 2013 07:58:05 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377503885.42.0.391333871251.issue17741@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Since parsers don't support changing the target after creation, I think it makes sense to deprecate passing in a parser *instance*, and instead require passing in a callback that accepts the target to use and *returns* an appropriate parser object. The "parser can only use the default TreeBuilder as a target." line in the iterparse docs is a sign that this is a more appropriate API - if iterparse needs a particular kind of target, the API should be designed so iterparse *provides* that target instead of saying "please don't use a custom target type".

However, I don't think it makes sense to provide such a callback based API until it is actually possible to implement the streaming event API using a custom target object with XMLParser.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 10:31:45 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 26 Aug 2013 08:31:45 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377505905.69.0.867018738914.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I don't see adding one method to XMLParser as a design problem. In fact, it's even a good design on the technical side, because if ET ever gains an HTMLParser, then the implementation of this feature would be highly dependent on the underlying parser, i.e. it would be very different from the implementation in XMLParser. It might not even be supported at all. Moving the API into the parser gives us that choice quite naturally.

It also solves the naming issue. Why add another thing to the module that needs explanation (and even an explanation why it's there and how it's different from what else is there), when we can just add the feature to what's there and be done?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 10:36:01 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 26 Aug 2013 08:36:01 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377506161.2.0.58501990952.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> ... instead require passing in a callback that accepts the target ...

That could be the parser class then, for example, except that there may be other options to set as well. Plus, it would not actually allow iterparse to wrap a user provided target. So, in fact, that approach doesn't match with the design of introducing a target wrapper.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 10:40:18 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 26 Aug 2013 08:40:18 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377506418.55.0.280851288617.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> it's really about turning XMLParser's "push" API for events (where the events are pushed into the target object by the parser calling the appropriate methods), into an iterparse style pull API where the events can be retrieved via calls to read_events().

Sorry, but this is ignoring the fact that the target is an *inherent* part of this feature. In fact, the push API of XMLParser forms an integral part of the design. The events that are being collected are a mixture of what the XMLParser produces and what the target produces. You can't think this feature without these two parts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 11:05:07 2013
From: report at bugs.python.org (Drekin)
Date: Mon, 26 Aug 2013 09:05:07 +0000
Subject: [issue18838] The order of interactive prompt and traceback on Windows
Message-ID: <1377507907.91.0.430796932988.issue18838@psf.upfronthosting.co.za>


New submission from Drekin:

On Windows, Python 3.3.2, when I run Python as a subprocess via Popen("py -i somescript.py", stdin=PIPE, stdout=PIPE, stderr=PIPE).communicate() and somescript.py ends with exception, there is first interactive promt ">>>" in stderr output and then the traceback which is reversed to standard order when somescript.py is run interactively directly.

Corresponding StackOverflow question: http://stackoverflow.com/questions/18419724/position-of-prompt-in-stderr-after-systemexit .

----------
components: Windows
messages: 196192
nosy: Drekin
priority: normal
severity: normal
status: open
title: The order of interactive prompt and traceback on Windows
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18838>
_______________________________________

From report at bugs.python.org  Mon Aug 26 11:14:26 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 26 Aug 2013 09:14:26 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377508466.18.0.976045363519.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> in the long run we want the new class to just be a convenience API for combining XMLParser and a custom target object, even if it can't be implemented that way right now.

Just to be clear: I changed my opinion on this one and I no longer think that it is a good idea. The negative impact on what's there currently is just too large, specifically the user visible deprecation and the change to the target object API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 11:17:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Aug 2013 09:17:40 +0000
Subject: [issue13107] Text width in optparse.py can become negative
In-Reply-To: <1317812903.38.0.572106699519.issue13107@psf.upfronthosting.co.za>
Message-ID: <1377508660.62.0.375746058811.issue13107@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13107>
_______________________________________

From report at bugs.python.org  Mon Aug 26 12:23:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Aug 2013 10:23:02 +0000
Subject: [issue18835] Add aligned memroy variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1377512582.88.0.536014761292.issue18835@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Unless the memory allocator actually supports it, this means you lose a whole lot of memory for padding, though... Memory which will sit there unused at the end of another cacheline.

Note that the current small object allocator, if not disabled, *should* already return you aligned memory, by construction (each allocation size has dedicated pools from which memory blocks are carved).

----------
nosy: +haypo, pitrou, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Aug 26 12:51:32 2013
From: report at bugs.python.org (Marco Buttu)
Date: Mon, 26 Aug 2013 10:51:32 +0000
Subject: [issue18839] Wrong sentence in sys.exit.__doc__
Message-ID: <1377514292.79.0.0321965724475.issue18839@psf.upfronthosting.co.za>


New submission from Marco Buttu:

Python 3.3::

    >>> import sys
    >>> print(sys.exit.__doc__)
    exit([status])

    Exit the interpreter by raising SystemExit(status).
    If the status is omitted or None, it defaults to zero (i.e., success).
    If the status is numeric, it will be used as the system exit status.
    If it is another kind of object, it will be printed and the system
    exit status will be one (i.e., failure).

The sentence "If the status is numeric, it will be used as the system exit status."
is wrong::

    >>> sys.exit(3.33)
    3.33
    $ echo $?
    1


It should be "If the status is an *integer*, it will be used as the system exit status.",
as specified in the SystemExit `doc`.

.. doc: http://docs.python.org/3/library/exceptions.html#SystemExit

----------
assignee: docs at python
components: Documentation
messages: 196195
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Wrong sentence in sys.exit.__doc__
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18839>
_______________________________________

From report at bugs.python.org  Mon Aug 26 12:52:46 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Aug 2013 10:52:46 +0000
Subject: [issue18835] Add aligned memroy variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1377514366.21.0.00190556268388.issue18835@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The default allocator for PyObject is PyType_GenericAlloc(). If the type has the Py_TPFLAGS_HAVE_GC flag, PyType_GenericAlloc() calls _PyObject_GC_Malloc(). It is the case for the set type. _PyObject_GC_Malloc() adds an header of sizeof(PyGC_Head) (12 bytes on x86) before the PyObject data and then calls PyObject_MALLOC(). By default, Python uses pymalloc for PyObject_MALLOC() which uses an alignment of 8 bytes.

For set, I suppose that you are talking about the allocation of the "table", not of the set object itself. set_table_resize() uses PyMem_NEW() to allocate the table.

If we provide a PyMem_MallocAligned(alignment, size), table entries would be aligned, but not entries of the smalltable. Does it matter?

> I suggest variants such as PyMem_Alloc32(n) and PyMem_Alloc64(n) to return suitably aligned data blocks.

I would prefer a parameter rather than a new function per alignment! Which API does you propose exactly? On Linux, I see at least 3 functions:

int posix_memalign(void **memptr, size_t alignment, size_t size);
void *valloc(size_t size);
void *memalign(size_t boundary, size_t size);

Do you propose aligned variant for PyMem, PyMem_Raw and PyObject, or only PyMem?

"Unless the memory allocator actually supports it, this means you lose a whole lot of memory for padding, though... Memory which will sit there unused at the end of another cacheline."

What is the alignment of a cacheline? Can a line starts at any address?

Do you have an idea of performance benefit of memory alignment?

Adding yet another API to allocate memory has a cost.

Python 3.4 already implemented the PEP 445 which added many new functions. If we add new functions, they should conform the PEP 445 (need get/set allocator functions to support hooks to track the memory usage).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Aug 26 13:01:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Aug 2013 11:01:57 +0000
Subject: [issue18839] Wrong sentence in sys.exit.__doc__
In-Reply-To: <1377514292.79.0.0321965724475.issue18839@psf.upfronthosting.co.za>
Message-ID: <3cNqzS3yvtz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 187a678c6033 by Ezio Melotti in branch '2.7':
#18839: document that sys.exit() will not accept a non-integer numeric value as exit status.
http://hg.python.org/cpython/rev/187a678c6033

New changeset 694e50a79638 by Ezio Melotti in branch '3.3':
#18839: document that sys.exit() will not accept a non-integer numeric value as exit status.
http://hg.python.org/cpython/rev/694e50a79638

New changeset 6cb3ae431bef by Ezio Melotti in branch 'default':
#18839: merge with 3.3.
http://hg.python.org/cpython/rev/6cb3ae431bef

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18839>
_______________________________________

From report at bugs.python.org  Mon Aug 26 13:02:31 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Aug 2013 11:02:31 +0000
Subject: [issue18839] Wrong sentence in sys.exit.__doc__
In-Reply-To: <1377514292.79.0.0321965724475.issue18839@psf.upfronthosting.co.za>
Message-ID: <1377514951.34.0.312296005278.issue18839@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: behavior -> enhancement
versions: +Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18839>
_______________________________________

From report at bugs.python.org  Mon Aug 26 14:06:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Aug 2013 12:06:56 +0000
Subject: [issue18408] Fixes crashes found by pyfailmalloc
In-Reply-To: <1373314243.02.0.649080681154.issue18408@psf.upfronthosting.co.za>
Message-ID: <3cNsQR4pqyz7LpR@mail.python.org>


Roundup Robot added the comment:

New changeset 79ce25c70795 by Victor Stinner in branch 'default':
Issue #18408: _PyObject_Dump() now saves/restores the current exception
http://hg.python.org/cpython/rev/79ce25c70795

New changeset e63f19d0a651 by Victor Stinner in branch 'default':
Issue #18664, #18408: Rewrite PyErr_WriteUnraisable() to handle errors
http://hg.python.org/cpython/rev/e63f19d0a651

New changeset 8fb3a6f9b0a4 by Victor Stinner in branch 'default':
Restore changeset 5bd9db528aed (issue #18408)
http://hg.python.org/cpython/rev/8fb3a6f9b0a4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18408>
_______________________________________

From report at bugs.python.org  Mon Aug 26 14:06:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Aug 2013 12:06:57 +0000
Subject: [issue18664] occasional test_threading failure
In-Reply-To: <1375741165.75.0.0273425053979.issue18664@psf.upfronthosting.co.za>
Message-ID: <3cNsQS36zWz7Lpq@mail.python.org>


Roundup Robot added the comment:

New changeset e63f19d0a651 by Victor Stinner in branch 'default':
Issue #18664, #18408: Rewrite PyErr_WriteUnraisable() to handle errors
http://hg.python.org/cpython/rev/e63f19d0a651

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18664>
_______________________________________

From report at bugs.python.org  Mon Aug 26 14:10:49 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Aug 2013 12:10:49 +0000
Subject: [issue18834] Add Clang to distutils to build C/C++ extensions
In-Reply-To: <1377459226.15.0.775642351727.issue18834@psf.upfronthosting.co.za>
Message-ID: <1377519049.45.0.201034792774.issue18834@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Please upload the patches as files to the issue, that way our review tool can be used.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18834>
_______________________________________

From report at bugs.python.org  Mon Aug 26 14:18:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Aug 2013 12:18:46 +0000
Subject: [issue18835] Add aligned memroy variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377514366.21.0.00190556268388.issue18835@psf.upfronthosting.co.za>
Message-ID: <1642047011.13842298.1377519519801.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> What is the alignment of a cacheline? Can a line starts at any
> address?

If it could, Raymond wouldn't be asking for this feature ;-)
Cachelines are typically aligned at whatever their size is. So,
a 64-byte cacheline will be aligned at a 64 bytes boundary.
Perhaps some CPUs operate differently, but mainstream CPUs are
generally like that (for good reason: a cache is much simpler
to implement if there can't be some overlapping between cache
lines).

> Do you have an idea of performance benefit of memory alignment?
> 
> Adding yet another API to allocate memory has a cost.

Agreed. Aligned memory allocation is useful if your
*algorithms* benefit from alignment (e.g. some SIMD-optimized
code, or something relying on page tables). But aligning
every data structure on a cacheline boundary doesn't sound
like a very good idea: if it was, the system allocator
would do it for you, IMHO ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Aug 26 14:37:59 2013
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 26 Aug 2013 12:37:59 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
Message-ID: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>


New submission from Donald Stufft:

The Python tutorial tells, and even recommends, new users that they can use the pickle module to serialize arbitrary objects. However it does not provide any warning about the insecurity of unpickling arbtirary data. The text even goes so far as to mention sending pickled data over a network connection to other machines.

I believe this section should be replaced with using the json module instead of pickle. It is more standard and doesn't present the same security concerns with untrusted data as pickle does. However if it continues to recommend pickle to new users it should at least warn them of the dangers of using pickle.

The section in question is located at http://docs.python.org/3/tutorial/inputoutput.html#the-pickle-module

----------
assignee: docs at python
components: Documentation
messages: 196203
nosy: docs at python, dstufft
priority: normal
severity: normal
status: open
title: Tutorial recommends pickle module without any warning of insecurity

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Mon Aug 26 14:51:40 2013
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 26 Aug 2013 12:51:40 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1377521500.42.0.134653894567.issue18840@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

Advising the reader to be aware of the security warnings in the API documentation seems sufficient.

JSON isn't intended to support arbitrary data, and that's what this section is discussing.  Another section about data interchange with other applications (regardless of language), may be a reasonable addition, or a good candidate for a separate How-To document that can be referenced.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Mon Aug 26 14:57:25 2013
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 26 Aug 2013 12:57:25 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1377521845.76.0.485486519886.issue18840@psf.upfronthosting.co.za>


Donald Stufft added the comment:

The section to me just seems to be about how to handle more than just strings, it mentions numbers, lists, dictionaries, and class instances. Of those it mentions, only the class instances are not able to handled out of the box by JSON.

However like I said even if it remains pickle this particular area of the documentation should still warn users even though there's already a warning in the API documentation for pickle. As it is if a new user reads this and doesn't click through to the API documentation they've received recommendation from the Python documentation that they can send pickle strings over the network. This is dangerous behavior and the documentation shouldn't be advising new users to do dangerous things by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Mon Aug 26 14:59:38 2013
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 26 Aug 2013 12:59:38 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1377521978.91.0.716599581247.issue18840@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Further more the tutorial claims it's the standard way of persisting data which in my experience it's far from that due to the security concerns. I've seen very little actual use of pickle in the wild (and when it was used it was often used by people who didn't understand the security implications).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Mon Aug 26 16:04:54 2013
From: report at bugs.python.org (stakingrainbow2)
Date: Mon, 26 Aug 2013 14:04:54 +0000
Subject: [issue12641] NewInterface
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377525894.51.0.989839661639.issue12641@psf.upfronthosting.co.za>


stakingrainbow2 added the comment:

NewInterface

----------
nosy: +stakingrainbow2
title: Remove -mno-cygwin from distutils -> NewInterface
Added file: http://bugs.python.org/file31471/sa6.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Mon Aug 26 16:11:18 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Aug 2013 14:11:18 +0000
Subject: [issue11619] On Windows,
 don't encode filenames in the import machinery
In-Reply-To: <1300665531.85.0.426527059221.issue11619@psf.upfronthosting.co.za>
Message-ID: <1377526278.59.0.0453830690991.issue11619@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I updated  parser_unicode.patch to the last Python version. The new patch has just a minor nit: test_symtable does crash :-D

Fixed in new patch: parser_unicode-3.patch

----------
Added file: http://bugs.python.org/file31472/parser_unicode-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11619>
_______________________________________

From report at bugs.python.org  Mon Aug 26 16:16:22 2013
From: report at bugs.python.org (Martin Panter)
Date: Mon, 26 Aug 2013 14:16:22 +0000
Subject: [issue1944] Documentation for PyUnicode_AsString (et al.) missing.
In-Reply-To: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za>
Message-ID: <1377526582.4.0.350048836373.issue1944@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1944>
_______________________________________

From report at bugs.python.org  Mon Aug 26 16:31:13 2013
From: report at bugs.python.org (Ludwig Nussel)
Date: Mon, 26 Aug 2013 14:31:13 +0000
Subject: [issue13655] Python SSL stack doesn't have a default CA Store
In-Reply-To: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za>
Message-ID: <1377527473.01.0.148062314355.issue13655@psf.upfronthosting.co.za>


Changes by Ludwig Nussel <ludwig.nussel at suse.de>:


----------
nosy: +lnussel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13655>
_______________________________________

From report at bugs.python.org  Mon Aug 26 16:41:08 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Aug 2013 14:41:08 +0000
Subject: [issue11619] On Windows,
 don't encode filenames in the import machinery
In-Reply-To: <1300665531.85.0.426527059221.issue11619@psf.upfronthosting.co.za>
Message-ID: <1377528068.02.0.796977116226.issue11619@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file21759/parser_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11619>
_______________________________________

From report at bugs.python.org  Mon Aug 26 16:41:09 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Aug 2013 14:41:09 +0000
Subject: [issue11619] On Windows,
 don't encode filenames in the import machinery
In-Reply-To: <1300665531.85.0.426527059221.issue11619@psf.upfronthosting.co.za>
Message-ID: <1377528069.49.0.793497904703.issue11619@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file31446/parser_unicode-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11619>
_______________________________________

From report at bugs.python.org  Mon Aug 26 16:55:36 2013
From: report at bugs.python.org (PJ Eby)
Date: Mon, 26 Aug 2013 14:55:36 +0000
Subject: [issue12641] NewInterface
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377528936.76.0.73352982371.issue12641@psf.upfronthosting.co.za>


Changes by PJ Eby <pje at telecommunity.com>:


Removed file: http://bugs.python.org/file31471/sa6.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Mon Aug 26 16:56:35 2013
From: report at bugs.python.org (PJ Eby)
Date: Mon, 26 Aug 2013 14:56:35 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377528995.37.0.452110066688.issue12641@psf.upfronthosting.co.za>


Changes by PJ Eby <pje at telecommunity.com>:


----------
title: NewInterface -> Remove -mno-cygwin from distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Mon Aug 26 17:02:03 2013
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 26 Aug 2013 15:02:03 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1377529323.79.0.488028735319.issue18840@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

When I read "... that can take almost any Python object  ...", I don't think the recommendation is about just a few types.

The Zope and ZODB communities certainly use pickle extensively, we're aware of the security implications, and we send pickled data over the network all the time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Mon Aug 26 17:08:01 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 26 Aug 2013 15:08:01 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1377529681.12.0.801241568699.issue18606@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

I have changed the algorithm for statistics.sum to use long integer summation of numerator/denominator pairs.

This removes the concerns Mark raised about the float addition requiring correct rounding. Unless I've missed something, this now means that statistics.sum is now exact, including for floats and Decimals.

The cost is that stats.sum(ints) is a little slower, sum of Decimals is a lot slower (ouch!) but sum of floats is faster and of Fractions a lot faster. (Changes are relative to my original implementation.) In my testing, algorithmic complexity is O(N) on the number of items, at least up to 10 million items.

----------
Added file: http://bugs.python.org/file31473/statistics_newsum.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Aug 26 17:13:49 2013
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 26 Aug 2013 15:13:49 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1377530029.44.0.512094533134.issue18840@psf.upfronthosting.co.za>


Donald Stufft added the comment:

A description of the pickle module itself does not equate to the purpose of the section. Given that this is a tutorial and previous section taught how to read and write from files I would suggest that the purpose of the section was to give them the next step to persisting data which could be pickle or it could be JSON (or it could be another format all together). 

I don't see what Zope/ZODB's awareness of the security implications has to do with anything unless you're trying to state that the developers and users of ZODB are newcomers to Python whose knowledge of pickle stems from what they read in the tutorial. However I am glad that those communities are aware of the implications if they are using that module, but the point is the reader of the tutorial is *not* likely to be aware of them and should *not* be using pickle without being aware of them especially if they are sending that data over the network.

I'm really not sure what your problem is here. What is there to lose by annotating this section of the tutorial with a similar warning as exists in the pickle documentation that they should not unpickle data from an untrusted or unauthenticated sources? I can see how someone could state that the problem with switching to JSON is that it's harder to construct a serialization for arbitrary objects. That's not something I think it all that important to teach someone brand new to Python however I can understand if switching this section to using a "safe" serialization format doesn't sit well with people which is why I suggested at least adding a warning.

So what exactly is your problem with at a minimum adding a warning?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Mon Aug 26 17:26:48 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 26 Aug 2013 15:26:48 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1377530808.51.0.0126334852447.issue18829@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Apparently, other attributes of the csv dialect beside delimiter, such as escapechar and quotechar share the same problem.

>>> import _csv
>>> _csv.reader('foo', quotechar=b'"')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: quotechar must be set if quoting enabled
>>> _csv.reader('foo', escapechar=b'+')
<_csv.reader object at 0x7fa85d7847d0>Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: bad argument type for built-in operation

My patch already fixed the problem, only lacked the unit test. But since this ticket is about delimiter, I'll create the unit test for quotechar and escapechar in separate ticket after this ticket has been closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Mon Aug 26 17:38:40 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 26 Aug 2013 15:38:40 +0000
Subject: [issue18841] math.isfinite fails with Decimal sNAN
Message-ID: <1377531520.63.0.106544243675.issue18841@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

math.isfinite currently raises ValueError when given a Decimal sNAN (signalling NAN).

I've run into a situation where I'm calling isfinite() on a numeric value which may be a Decimal sNAN, and it would be nice if it returned False.

On the other hand, see the discussion on issue 15544, which possibly leads to the conclusion that raising ValueError is the right thing to do.

http://bugs.python.org/issue15544

Either way, behaviour should be documented.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 196213
nosy: docs at python, stevenjd
priority: normal
severity: normal
status: open
title: math.isfinite fails with Decimal sNAN
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18841>
_______________________________________

From report at bugs.python.org  Mon Aug 26 17:42:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Aug 2013 15:42:33 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1377531753.87.0.0579855193146.issue18840@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I would be ok with changing that part of the tutorial to use json. Since json is much better known outside of the Python programming circles, and since its output is human-readable, it's probably a better fit for the tutorial. pickle can be mentioned as a more powerful and more dangerous alternative.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Mon Aug 26 17:47:27 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Aug 2013 15:47:27 +0000
Subject: [issue18836] Potential race condition in exceptions
In-Reply-To: <1377497509.71.0.034362539056.issue18836@psf.upfronthosting.co.za>
Message-ID: <1377532047.28.0.248688658073.issue18836@psf.upfronthosting.co.za>


R. David Murray added the comment:

Then you catch KeyboardInterrupt and present your alternate text.  I'm not following what the problem is. In particular, once you've caught KeyboardInterrupt, a second ctl-C *should* cause a normal program break, otherwise you've locked the user into a infinite loop he can't get out of if your program logic is wrong.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18836>
_______________________________________

From report at bugs.python.org  Mon Aug 26 17:47:48 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 26 Aug 2013 15:47:48 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1377532068.84.0.165166816193.issue12641@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg196207

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Mon Aug 26 17:51:59 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Aug 2013 15:51:59 +0000
Subject: [issue18838] The order of interactive prompt and traceback on Windows
In-Reply-To: <1377507907.91.0.430796932988.issue18838@psf.upfronthosting.co.za>
Message-ID: <1377532319.13.0.131652526356.issue18838@psf.upfronthosting.co.za>


R. David Murray added the comment:

For anyone who wants to look in to this: according to the stack overflow question and comments, this is a behavior change between python2 and python3.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18838>
_______________________________________

From report at bugs.python.org  Mon Aug 26 17:52:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Aug 2013 15:52:11 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1377532331.57.0.772877249691.issue18840@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

By the way, there is one difference between json and pickle in this context: json will output a text serialization, pickle a binary one. If serializing to a binary file, users must do the (utf-8, most likely) encoding themselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Mon Aug 26 17:54:00 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 26 Aug 2013 15:54:00 +0000
Subject: [issue18830] Remove duplicates from a result of getclasstree()
In-Reply-To: <1377442213.69.0.00603799982208.issue18830@psf.upfronthosting.co.za>
Message-ID: <1377532440.41.0.379932383436.issue18830@psf.upfronthosting.co.za>


?ric Araujo added the comment:

+1

----------
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18830>
_______________________________________

From report at bugs.python.org  Mon Aug 26 17:59:17 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 26 Aug 2013 15:59:17 +0000
Subject: [issue18842] Add float.is_finite is_nan is_infinite to match Decimal
 methods
Message-ID: <1377532757.24.0.123652540945.issue18842@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

On issue 15544 Mark Dickinson suggested adding methods to float to match methods on Decimal, giving type-agnostic ways of testing real numbers that don't rely on converting to float. I don't see any sign that Mark raised a feature request, so I'm taking the liberty of doing so myself.

Note that the math.is* functions convert to float first, which means that they behave differently. Example: math.isnan(Decimal('sNAN')) raises ValueError, rather than returning True.

float.is_nan
float.is_infinity
float.is_finite

would mirror the spelling of Decimal methods, rather than the math module. As float doesn't support signalling NANs, there probably isn't any need to include is_snan and is_qnan.

For what it's worth, I have code that would use this. I currently write something like:

if isinstance(x, Decimal) and x.is_nan() or math.isnan(x): ...

in order to prevent triggering the ValueError on signalling NANs.

----------
messages: 196219
nosy: stevenjd
priority: normal
severity: normal
status: open
title: Add float.is_finite is_nan is_infinite to match Decimal methods
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18842>
_______________________________________

From report at bugs.python.org  Mon Aug 26 18:03:48 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 26 Aug 2013 16:03:48 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1377495644.65.0.193687256987.issue17741@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda-RGYYyxQBw=zCDGYT6pqQLhSoQq=oKAd=9dRpkRJtjmQ@mail.gmail.com>


Eli Bendersky added the comment:

On Sun, Aug 25, 2013 at 10:40 PM, Stefan Behnel <report at bugs.python.org>wrote:

>
> Stefan Behnel added the comment:
>
> Hmm, did you look at my last comment at all? It solves both the technical
> issues and the API issues very nicely and avoids any problems of potential
> future changes. Let me quickly explain why.
>
> The feature in question depends on two existing parts of the API: the
> event generation of the parser, and the return values of the parser target
> (e.g. a tree builder). So there are really only three places where this
> feature makes sense, both technically and API-wise.
>
> 1) in the target
> 2) in the parser
> 3) between parser and target
>
> Note how a separate class is ruled out right from the start by the fact
> that the feature lives somehwere between parser and target. It's an
> inherent part of the existing design already (and of the implementation,
> BTW), so I don't see how adding a separate thing to control it makes any
> sense.
>
> 1) is impossible because the target is user provided and we do not control
> it
> 2) works fine because the parser controls both the call to the target and
> its return value
> 3) would be nice (and was my original favourite) but is hard to do with
> the current implementation and requires further changes to the API of
> parser targets
>
> So 2) is the choice that remains.
>
>
I think folding it all into XMLParser is a bad idea. XMLParser is a fairly
simple API and I don't want to complicate it. But more importantly,
XMLParser knows nothing about Elements, at least in the direct API of
today. The one constructing Elements is the target. The "read_events"
method proposed for the new class (currently IncrementalParser.events)
already returns Elements, having used a TreeBuilder to build them.
XMLParser emits start/end/data calls into the target, but these only carry
tag names, attributes and chunks of data. The hierarchical element
construction is done by TreeBuilder.

What I actually think would be better for the long term is to add new
target invocations in XMLParser - start-ns and end-ns. So XMLParser would
just keep *parsing*, leaving the interpretation of the parsed data to the
target. Today's TreeBuilder is free to ignore these calls. A custom
"EventCollectingTreeBuilder" can collect an event list, having all the
information at its disposal. Thus, XMLParser would remain what it is today
(minus the _setevents hack) - a router for pyexpat events.

These discussions of the future API are interesting, but what's more
important today is to have an API for IncrementalParser (using this name
before a new one is agreed upon) that doesn't block future implementation
changes. And I believe the API proposed here fits the bill.

> > The class will be named EventParser.
>
> Obviously because it's parsing Events, as opposed to the XMLParser, which
> parses XML, or the HTMLParser, which parses HTML, right?
>

The name is not perfect, and proposals for a better one are welcome. FWIW,
since it already lives in the xml.etree namespace, "XML" does not
necessarily have to be part of the name. So, some alternatives:

* EventStreamer - proposed by Nick. I have to admit I don't feel good with
it, because I still want to be crystal clear it's a *parser* we're talking
about.
* EventBasedParser
* EventCollectingParser
* NonblockingParser
* ... other ideas?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 18:16:34 2013
From: report at bugs.python.org (Sworddragon)
Date: Mon, 26 Aug 2013 16:16:34 +0000
Subject: [issue18836] Potential race condition in exceptions
In-Reply-To: <1377497509.71.0.034362539056.issue18836@psf.upfronthosting.co.za>
Message-ID: <1377533794.27.0.0715271497926.issue18836@psf.upfronthosting.co.za>


Sworddragon added the comment:

The problem is simple: It is not possible to catch every exception in an application. Even if you try to print a message and exit on an exception it is always possible that the user will see a traceback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18836>
_______________________________________

From report at bugs.python.org  Mon Aug 26 18:28:32 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Mon, 26 Aug 2013 16:28:32 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
Message-ID: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>


New submission from Martin Mokrejs:

Hi,
  it happened to me that using faulthandler and python compiled with --with-pydebug and C*FLAGS=-ggdb I got this stacktrace (will attach longer version as a file):


(gdb) where
#0  0x00007f0e3af8aacb in raise () from /lib64/libpthread.so.0
#1  0x00007f0e3a0b05f6 in faulthandler_fatal_error (signum=6) at faulthandler.c:321
#2  <signal handler called>
#3  0x00007f0e3ac061f5 in raise () from /lib64/libc.so.6
#4  0x00007f0e3ac0766b in abort () from /lib64/libc.so.6
#5  0x00007f0e3b327828 in Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Python/pythonrun.c:1689
#6  0x00007f0e3b257dc8 in _PyObject_DebugCheckAddressApi (api=111 'o', p=0x449e6900) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/obmalloc.c:1591
#7  0x00007f0e3b257a6c in _PyObject_DebugFreeApi (api=111 'o', p=0x449e6900) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/obmalloc.c:1478
#8  0x00007f0e3b257913 in _PyObject_DebugFree (p=0x449e6900) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/obmalloc.c:1422
#9  0x00007f0e3b34319a in PyObject_GC_Del (op=0x449e6920) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/gcmodule.c:1561
#10 0x00007f0e3b275ef7 in tupledealloc (op=0x449e6920) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/tupleobject.c:235
#11 0x00007f0e3b255bac in _Py_Dealloc (op=(True,)) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/object.c:2262
#12 0x00007f0e3b246d77 in dict_dealloc (mp=0x449b5d80) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:1010
#13 0x00007f0e3b255bac in _Py_Dealloc (op=
    {'_label': <unknown at remote 0x449dd4b8>, '_facecolors_original': (<float at remote 0xb65dd38>, <float at remote 0x5034630>, <float at remote 0xb3c6af8>), '_transform': <unknown at remote 0x449e6b50>, 'figure': <Figure(_label='', _transform=None, figure=None, _axobservers=[], images=[], texts=[], _hold=True, artists=[], _agg_filter=None, patch=<Rectangle(_label='', _transform=<BboxTransformTo(_invalid=2, _inverted=<Affine2D(_invalid=0, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bc6ec0>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xbf7d060>, data={}) at remote 0x129fbdf8>) at remote 0xd5bb0300>, _boxout=<TransformedBbox(_invalid=2, _transform=<Affine2D(_invalid=2, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bad540>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xc166450>, data={741848704: <KeyedRef at remote 0x40290a80>, 405520480: <KeyedRef at remote 0x29e86b10>, 322803328: <KeyedRef at remote 0x29e86570>, 3585872752: <KeyedRef ...(truncated)) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/object.c:2262
#14 0x00007f0e3b27ad3d in subtype_dealloc (
    self=<PathCollection(_label=<unknown at remote 0x449dd4b8>, _facecolors_original=(<float at remote 0xb65dd38>, <float at remote 0x5034630>, <float at remote 0xb3c6af8>), _transform=<unknown at remote 0x449e6b50>, figure=<Figure(_label='', _transform=None, figure=None, _axobservers=[], images=[], texts=[], _hold=True, artists=[], _agg_filter=None, patch=<Rectangle(_label='', _transform=<BboxTransformTo(_invalid=2, _inverted=<Affine2D(_invalid=0, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bc6ec0>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xbf7d060>, data={}) at remote 0x129fbdf8>) at remote 0xd5bb0300>, _boxout=<TransformedBbox(_invalid=2, _transform=<Affine2D(_invalid=2, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bad540>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xc166450>, data={741848704: <KeyedRef at remote 0x40290a80>, 405520480: <KeyedRef at remote 0x29e86b10>, 322803328: <KeyedRef at remote 0x29e86570>, 3585872752: <KeyedR...(truncated)) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/typeobject.c:1015
#15 0x00007f0e3b255bac in _Py_Dealloc (
    op=<PathCollection(_label=<unknown at remote 0x449dd4b8>, _facecolors_original=(<float at remote 0xb65dd38>, <float at remote 0x5034630>, <float at remote 0xb3c6af8>), _transform=<unknown at remote 0x449e6b50>, figure=<Figure(_label='', _transform=None, figure=None, _axobservers=[], images=[], texts=[], _hold=True, artists=[], _agg_filter=None, patch=<Rectangle(_label='', _transform=<BboxTransformTo(_invalid=2, _inverted=<Affine2D(_invalid=0, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bc6ec0>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xbf7d060>, data={}) at remote 0x129fbdf8>) at remote 0xd5bb0300>, _boxout=<TransformedBbox(_invalid=2, _transform=<Affine2D(_invalid=2, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bad540>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xc166450>, data={741848704: <KeyedRef at remote 0x40290a80>, 405520480: <KeyedRef at remote 0x29e86b10>, 322803328: <KeyedRef at remote 0x29e86570>, 3585872752: <KeyedR...(truncated)) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/object.c:2262
#16 0x00007f0e3b230841 in list_dealloc (op=0x1d1740d8) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/listobject.c:309
#17 0x00007f0e3b255bac in _Py_Dealloc (
    op=[<PathCollection(_label='_collection0', _facecolors_original=(<float at remote 0x5034630>, <float at remote 0xc489d80>, <float at remote 0xc568ab8>), _transform=<IdentityTransform(_invalid=1, _inverted=None, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xbf7d840>, data={}) at remote 0x129fb510>) at remote 0x1201cd10>, figure=<Figure(_label='', _transform=None, figure=None, _axobservers=[], images=[], texts=[], _hold=True, artists=[], _agg_filter=None, patch=<Rectangle(_label='', _transform=<BboxTransformTo(_invalid=2, _inverted=<Affine2D(_invalid=0, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bc6ec0>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xbf7d060>, data={}) at remote 0x129fbdf8>) at remote 0xd5bb0300>, _boxout=<TransformedBbox(_invalid=2, _transform=<Affine2D(_invalid=2, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bad540>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xc166450>, data={741848...(truncated)) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/object.c:2262
#18 0x00007f0e3b245789 in insertdict_by_entry (mp=0x17e2a9c0, key='collections', hash=5674278088882554420, ep=0x103a7dc0, value=[]) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:519
#19 0x00007f0e3b245a5b in insertdict (mp=0x17e2a9c0, key='collections', hash=5674278088882554420, value=[]) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:556
#20 0x00007f0e3b246326 in dict_set_item_by_hash_or_entry (op=0x0, key='collections', hash=5674278088882554420, ep=0x0, value=[]) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:765
#21 0x00007f0e3b2464be in PyDict_SetItem (
    op={'transLimits': <BboxTransformFrom(_invalid=2, _boxin=<TransformedBbox(_invalid=2, _transform=<TransformWrapper(_invalid=0, transform_path_affine=<instancemethod at remote 0xbad73e0>, input_dims=2, transform_path=<instancemethod at remote 0x17f47d60>, transform=<instancemethod at remote 0xd511bee0>, transform_affine=<instancemethod at remote 0x1e0e0260>, inverted=<instancemethod at remote 0x17f47ce0>, _child=<BlendedAffine2D(_invalid=1, _y=<IdentityTransform(_invalid=1, _inverted=None, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0x10c92648>, data={315699008: <KeyedRef at remote 0xbd63a80>}) at remote 0x350f5df8>) at remote 0x2c360bc0>, _x=<IdentityTransform(_invalid=1, _inverted=None, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0x145ff990>, data={315699008: <KeyedRef at remote 0xbd63720>}) at remote 0xbfde2b8>) at remote 0x2c36c680>, _inverted=None, _mtx=None, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0x10c...(truncated), key='collections', value=[]) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:818

It was drawing a chart using matplotlib-1.2.1. Is this a python or matplotlib bug? I shortened the gdb stacktrace hoping you don't need the rest.

----------
files: bad_leading_pad_byte_14028_shortened.txt
messages: 196222
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file31474/bad_leading_pad_byte_14028_shortened.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Mon Aug 26 18:30:17 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Mon, 26 Aug 2013 16:30:17 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377534617.35.0.205861063872.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Should have included from the head of gdb output:

Program terminated with signal 6, Aborted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Mon Aug 26 18:45:16 2013
From: report at bugs.python.org (Joe Borg)
Date: Mon, 26 Aug 2013 16:45:16 +0000
Subject: [issue4705] python3.0 -u: unbuffered stdout
In-Reply-To: <1229780843.45.0.259077303406.issue4705@psf.upfronthosting.co.za>
Message-ID: <1377535516.79.0.998707757141.issue4705@psf.upfronthosting.co.za>


Joe Borg added the comment:

Can I confirm this is still in the trunk?  I have 3.3.2 and am suffering from the fact that `-u` isn't setting stdin to unbuffered.  I'm have to run a flush every command, which is awful.

----------
nosy: +Joe.Borg, georg.brandl
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4705>
_______________________________________

From report at bugs.python.org  Mon Aug 26 18:48:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Aug 2013 16:48:47 +0000
Subject: [issue18836] Potential race condition in exceptions
In-Reply-To: <1377497509.71.0.034362539056.issue18836@psf.upfronthosting.co.za>
Message-ID: <1377535727.18.0.731795562244.issue18836@psf.upfronthosting.co.za>


R. David Murray added the comment:

I wonder if you could achieve what you want (which I always hope programs I use never do[*]) by writing your own signal handler.

In any case, I don't believe there is a bug here.  This is working as designed.

[*] There are many times I have found myself leaning on ctl-C on autorepeat hoping that the ctl-c will happen at a point where the application isn't catching it, so that I can get the darn thing to abort.  I realize you are proposing to do this only to then do the abort...but what if there is a bug in your code?  I'd *much* rather see a traceback than have to fall back to 'kill'.  At least with the traceback I know the interpreter has had a chance to clean up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18836>
_______________________________________

From report at bugs.python.org  Mon Aug 26 19:04:15 2013
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 26 Aug 2013 17:04:15 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1377536655.86.0.616722167458.issue18840@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at gmail.com>:


----------
nosy:  -fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Mon Aug 26 19:09:22 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 26 Aug 2013 17:09:22 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377536962.73.0.658523521176.issue18843@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

This is a memory corruption.
Please look at the memory before the freed address (0x449e6900), maybe there is an indication of some buffer overflow?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Mon Aug 26 19:11:57 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Mon, 26 Aug 2013 17:11:57 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377537117.56.0.715515242014.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Would you please guide me what gdb commands I should issue for you? Thank you. BTW, I ran memtest86+ few days ago, although this is non-ECC memory I think HW is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Mon Aug 26 19:22:24 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Mon, 26 Aug 2013 17:22:24 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377537744.39.0.150728940059.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Grr, forgot to look into a file where I recorded STDERR.


Debug memory block at address p=0x449e6900: API 'o'
    80 bytes originally requested
    The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfb):
        at p-7: 0xfb
        at p-6: 0xfb
        at p-5: 0xfa *** OUCH
        at p-4: 0xfb
        at p-3: 0xfb
        at p-2: 0xfb
        at p-1: 0xfb
    Because memory is corrupted at the start, the count of bytes requested
       may be bogus, and checking the trailing pad bytes may segfault.
    The 8 pad bytes at tail=0x449e6950 are FORBIDDENBYTE, as expected.
    The block was made by call #8155854715 to debug malloc/realloc.
    Data at p: 00 00 00 00 00 00 00 00 ... 20 af 5b 3b 0e 7f 00 00
Fatal Python error: bad leading pad byte
Fatal Python error: Aborted

Current thread 0x00007f0e3b7ec700:
  File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 932 in cla
  File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 906 in clf
  File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 926 in clear
  File "blah.py", line 12513 in draw_hist2d_plot

In that function I call:
        del(_series)
        del(_ax1)
        _figure.clear() # 12513

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Mon Aug 26 19:23:45 2013
From: report at bugs.python.org (Alan Isaac)
Date: Mon, 26 Aug 2013 17:23:45 +0000
Subject: [issue18844] allow weights in random.choice
Message-ID: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>


New submission from Alan Isaac:

The need for weighted random choices is so common that it is addressed as a "common task" in the docs:
http://docs.python.org/dev/library/random.html

This enhancement request is to add an optional argument to random.choice, which must be a sequence of non-negative numbers (the weights) having the same length as the main argument.

----------
messages: 196229
nosy: aisaac
priority: normal
severity: normal
status: open
title: allow weights in random.choice
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Mon Aug 26 19:34:18 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 26 Aug 2013 17:34:18 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1377538458.61.0.378267212956.issue18828@psf.upfronthosting.co.za>


Madison May added the comment:

>From urllib.parse:

    uses_relative = ['ftp', 'http', 'gopher', 'nntp', 'imap',
                     'wais', 'file', 'https', 'shttp', 'mms',
                     'prospero', 'rtsp', 'rtspu', '', 'sftp',
                     'svn', 'svn+ssh']

>From urllib.parse.urljoin (scheme='redis' and url='/1' in your example): 
    
    if scheme != bscheme or scheme not in uses_relative:
        return _coerce_result(url)

Should the 'redis' scheme be added to uses_relative, perhaps?

----------
nosy: +madison.may

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________

From report at bugs.python.org  Mon Aug 26 19:42:29 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 26 Aug 2013 17:42:29 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377538949.24.0.213970372226.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> XMLParser knows nothing about Elements, at least in the direct API of today. The one constructing Elements is the target.

Absolutely. And I'm 100% for keeping that distinction exactly as it is.


> The "read_events" method proposed for the new class (currently IncrementalParser.events) already returns Elements, having used a TreeBuilder to build them.

More precisely, it only returns Elements *iff* the TreeBuilder builds them. If it does not, then it returns something else. By moving the desired functionality into the parser, we don't even need to change anything about the interface between the parser and the target object. We still can, though, if you want to extend the interface with start-ns and end-ns events (and I'm ok with that, but it's a different feature). We do not loose that option. But the cool thing is that we don't have to do this now, and that iterparse just keeps working as it is and can be fixed later. No deprecation needed.

So we can easily agree on the goals of keeping the interface of the XMLParser simple and not teaching it about Elements. But we still disagree about the conclusions. My conclusion is that the API is substantially simpler if we do *not* add an entire new class that just duplicates existing APIs, but keep the parser as the thing that generates parse events. Be they in the form of callbacks or in the form of event tuples (that have the same name as the callbacks, BTW). The cool feature is that you can use either of the two interfaces or even hook into one to control the other (once the C parser is fixed), without having to learn the distinction between an XMLParser and a WhateverNewParser that also just parses XML.


> I still want to be crystal clear it's a *parser* we're talking about

You have to decide what you want. IMHO, there is no use in putting a new parser next to the existing XMLParser if both are there for parsing XML. That is just unnecessarily confusing. If you want it to be a parser, use the XMLParser.


I guess there's no other way to convince you than by coding up my proposal. It seems to be hard to properly explain it without seeing it at work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 19:45:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Aug 2013 17:45:48 +0000
Subject: [issue18841] math.isfinite fails with Decimal sNAN
In-Reply-To: <1377531520.63.0.106544243675.issue18841@psf.upfronthosting.co.za>
Message-ID: <1377539148.16.0.519957985689.issue18841@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +facundobatista, mark.dickinson, rhettinger, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18841>
_______________________________________

From report at bugs.python.org  Mon Aug 26 19:46:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Aug 2013 17:46:29 +0000
Subject: [issue18842] Add float.is_finite is_nan is_infinite to match Decimal
 methods
In-Reply-To: <1377532757.24.0.123652540945.issue18842@psf.upfronthosting.co.za>
Message-ID: <1377539189.36.0.0306074738772.issue18842@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +facundobatista, mark.dickinson, rhettinger, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18842>
_______________________________________

From report at bugs.python.org  Mon Aug 26 19:47:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Aug 2013 17:47:20 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1377539240.82.0.822879327092.issue18844@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Library (Lib)
nosy: +mark.dickinson, rhettinger, serhiy.storchaka
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Mon Aug 26 19:50:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Aug 2013 17:50:10 +0000
Subject: [issue18830] Remove duplicates from a result of getclasstree()
In-Reply-To: <1377442213.69.0.00603799982208.issue18830@psf.upfronthosting.co.za>
Message-ID: <1377539410.53.0.91740596798.issue18830@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18830>
_______________________________________

From report at bugs.python.org  Mon Aug 26 20:04:15 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 26 Aug 2013 18:04:15 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377540255.36.0.728535437202.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

Python's debug-mode memory allocators add some "magic values" before and after each allocated chunk of memory, and check them when the chunk is freed to make sure nobody overwrote them.  In this case, someone did overwrite the byte at p-5, where p is the address of the block originally returned to the requesting program code.

It's also suspicious that it says this block was originally allocated by the 8,155,854,715th call to a debug allocation routine:  is it plausible that you (for example) allocated over 8 billion objects?  This "serial number" is also stored in bytes adjacent to (and after) the allocated block, so is also vulnerable to out-of-bounds stores by rogue code.

So we have out-of-bounds stores here both before and after the requested memory.  Sorry, but it's unlikely core Python is doing this - such errors are usually due to rogue extension modules.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Mon Aug 26 20:07:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Aug 2013 18:07:40 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377540460.67.0.355986134948.issue18843@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Mon Aug 26 20:49:17 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Mon, 26 Aug 2013 18:49:17 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377542957.32.0.70133892841.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Thank you for explanation what is going on. I called matplotlibs drawing function to include 49308 dots and corresponding legend items with their colors. That's all I can say. I am not a native English speaker so I don't know what 'rogue extension modules' means.

Do you think it is a matplotlib or numpy issue which were in the stacktrace? Or a memory module error?

I am running analyses which take weeks. Will python give me a clear warning/error when the object counter overflows?

So what should I do now? I am clue-less right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Mon Aug 26 20:55:35 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 26 Aug 2013 18:55:35 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1377543335.63.0.221831087368.issue18844@psf.upfronthosting.co.za>


Madison May added the comment:

+1. I've found myself in need of this feature often enough to wonder why it's not part of the stdlib.

----------
nosy: +madison.may

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Mon Aug 26 21:09:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Aug 2013 19:09:04 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1377544144.19.0.709862916994.issue18844@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Agreed with the feature request. The itertools dance won't be easy to understand, for many people.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Mon Aug 26 21:26:46 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 26 Aug 2013 19:26:46 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1377545206.78.0.448006975129.issue18828@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________

From report at bugs.python.org  Mon Aug 26 21:35:06 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 26 Aug 2013 19:35:06 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377545706.34.0.416759054466.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Here is a proof-of-concept patch that integrates the functionality of the IncrementalParser into the XMLParser. I ended up reusing most of Antoines implementation and test suite. In case he'll look back into this ticket at some point, I'll put a "thank you" here.

The patch certainly needs more cleanup, but it shows where things are going and passes all tests.

----------
Added file: http://bugs.python.org/file31475/integrate_IncrementalParser_into_XMLParser.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 21:36:41 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 26 Aug 2013 19:36:41 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377545801.76.0.911782601436.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

(I still wonder why I'm the one writing all the patches here when Eli is the one who actually wants this feature ...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 21:41:44 2013
From: report at bugs.python.org (Ryan Gonzalez)
Date: Mon, 26 Aug 2013 19:41:44 +0000
Subject: [issue18834] Add Clang to distutils to build C/C++ extensions
In-Reply-To: <1377459226.15.0.775642351727.issue18834@psf.upfronthosting.co.za>
Message-ID: <1377546104.9.0.0129074187358.issue18834@psf.upfronthosting.co.za>


Changes by Ryan Gonzalez <rymg19 at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31476/ccompiler.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18834>
_______________________________________

From report at bugs.python.org  Mon Aug 26 21:42:03 2013
From: report at bugs.python.org (Ryan Gonzalez)
Date: Mon, 26 Aug 2013 19:42:03 +0000
Subject: [issue18834] Add Clang to distutils to build C/C++ extensions
In-Reply-To: <1377459226.15.0.775642351727.issue18834@psf.upfronthosting.co.za>
Message-ID: <1377546123.31.0.236846640351.issue18834@psf.upfronthosting.co.za>


Changes by Ryan Gonzalez <rymg19 at gmail.com>:


Added file: http://bugs.python.org/file31477/cygwinccompiler.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18834>
_______________________________________

From report at bugs.python.org  Mon Aug 26 21:43:02 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 26 Aug 2013 19:43:02 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377546182.66.0.792446151798.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

BTW, maybe "read_events()" still isn't the ideal method name to put on a parser.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 21:47:06 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Mon, 26 Aug 2013 19:47:06 +0000
Subject: [issue18845] 2.7.5-r2: Fatal Python error: Segmentation fault
Message-ID: <1377546426.38.0.266867499434.issue18845@psf.upfronthosting.co.za>


New submission from Martin Mokrejs:

While running my app testsuite I have another one which crashed.

Fatal Python error: Segmentation fault

Current thread 0x00007fe8d3527700:
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 2370 in get_matrix
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 2203 in get_affine
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 2175 in transform_affine
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 1238 in transform
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 1030 in get_points
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 277 in __array__
  File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 110 in draw_path_collection
  File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 259 in draw
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54 in draw_wrapper
  File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 695 in draw
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54 in draw_wrapper
  File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 2086 in draw
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54 in draw_wrapper
  File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1006 in draw
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54 in draw_wrapper
  File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 440 in draw
  File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 492 in print_png
  File "/usr/lib64/python2.7/site-packages/matplotlib/backend_bases.py", line 2096 in print_figure
  File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1370 in savefig

  I wanted to draw 55620 dots in a scatter plot, each with a legend and its associated color. Actually only 100 color are used and multiple adjacent dots in the series have same color as necessary.


Is this a matplotlib or a python error?

----------
files: matplotlib_crash_1676__SRR091640_shortened.txt
messages: 196239
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: 2.7.5-r2: Fatal Python error: Segmentation fault
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file31478/matplotlib_crash_1676__SRR091640_shortened.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18845>
_______________________________________

From report at bugs.python.org  Mon Aug 26 21:49:17 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 26 Aug 2013 19:49:17 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <CAH_1eM3-7x_i3vJtF8ZNf5ia0hCBBUU6MCq4W9r2h1UH8n+KeA@mail.gmail.com>
Message-ID: <CAP7+vJJJFBg+=87Dh9mMHUzDSV7quHUZL51hwVZCM-F9VFQeJA@mail.gmail.com>


Guido van Rossum added the comment:

On Sat, Aug 24, 2013 at 5:04 AM, Charles-Fran?ois Natali
<report at bugs.python.org> wrote:
> Before I post it for final review, I have three more questions:
> 1) In the documentation, I don't know how to best refer to files
> object registered: is "file descriptor" OK, or is it too low-level?
> Otherwise I'd be tempted to use just "file", but then this doesn't
> include sockets, pipes, etc. Or maybe "file object"/"file-like
> object"?

What Antoine said.

And, moreover, it should be mentioned that on Windows it only accepts
socket FDs; and on UNIX it should probably qualify this in some way to
exclude disk FDs (which are always considered ready by select and
friends). I don't really know what the correct UNIX-flavor-neutral
terminology is for this case -- perhaps we have to enumerate the
possibilities? (I know of FIFOs, character special devices, and
sockets.)

> 2) currently, the select() method returns a list of
> (<file>, <event>, <data>)
>
> But the opaque "data" object is optional, which means that many user
> might end up doing:
>
> for file, event, data in selector.select():
>     if event & READ_EVENT:
>         file.recv(1024)
>     # don't use data
>
> i.e. have to unpack it for no reason.
>
> Would it make sense to return (<key>, <event>) instead?
> This way the user has all the interesting information, and can do:
>
> for key, event in selector.select():
>     if event & READ_EVENT:
>         key.file.recv(1024)
>         or
>         os.read(key.fd, 1024)

I like this -- return the key plus the specific event. You must
document SelectorKey, but that seems fine.

(Looks like Antoine read too fast and didn't realize you proposed to
return the key instead of the file and the data.)

> 3) Concerning get_info(): right now the signature is:
> get_info(): fileobj -> (events, data)
>
> Wouldn't it be better to just return the whole key instead, which
> contains all the relevant information (events, data, fd and fileobj).
> Then we should probably also rename the method to get_key()?

Yes, and yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Mon Aug 26 21:50:23 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 26 Aug 2013 19:50:23 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1377546623.5.0.353437843198.issue18720@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Looks good.  Go ahead and convert the rest of the socket constants.  Then we can consider other modules, e.g. select and os.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Mon Aug 26 21:55:46 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 26 Aug 2013 19:55:46 +0000
Subject: [issue18845] 2.7.5-r2: Fatal Python error: Segmentation fault
In-Reply-To: <1377546426.38.0.266867499434.issue18845@psf.upfronthosting.co.za>
Message-ID: <1377546946.51.0.35754786318.issue18845@psf.upfronthosting.co.za>


Tim Peters added the comment:

Impossible to know, but since everything in the traceback comes from matplotlib, the error is most likely in matplotlib.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18845>
_______________________________________

From report at bugs.python.org  Mon Aug 26 22:09:19 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 26 Aug 2013 20:09:19 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377547759.37.0.539601032578.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

Memory corruption can be difficult to track down.  Best thing you can do is strive to find a test case as small and fast as possible that shows the same kind of error.

By "rogue extension module" I just mean 3rd-party C code (like, for example, matplotlib).

I doubt it's a hardware problem.  That's possible, of course, but these kinds of errors are almost always the result of errors in C code.

The stacktrace probably isn't helpful.  All we know is that memory got corrupted _sometime_ between someone asking for a block of memory and releasing it.  The corruption may have happened a millisecond ago, or weeks ago (if the program ran that long) - there's no way to tell by the time the memory corruption is _detected_.

About "object counter overflows", I'm not sure what you're asking.  Python doesn't have an object counter.  The "serial number" in debug-mode allocators just counts the number of times a debug-mode malloc has been called.  If that overflows, it would do no harm.

Bottom line:  no matter what's to blame here, the smaller & faster a test program you can find, the more likely it is to get fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Mon Aug 26 22:19:55 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 26 Aug 2013 20:19:55 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1377545801.76.0.911782601436.issue17741@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda8-YReMe0pEh6YA1-C1-QP80zFrc=X6vOnD++LcsaYApw@mail.gmail.com>


Eli Bendersky added the comment:

>
> (I still wonder why I'm the one writing all the patches here when Eli is
> the one who actually wants this feature ...)
>

Well, obviously because you're the only real programmer around here and the
rest of us are just a bunch of hand-wavy morons.

Seriously, Stefan, lose the attitude. Your unpleasant approach to
conducting a conversation completely obscures your technical contributions
and capabilities. Antoine got fed up a while ago, and I'm also nearing that
point.

With that off my chest, I will look at this new patch, hopefully tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 22:33:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Aug 2013 20:33:50 +0000
Subject: [issue11619] On Windows,
 don't encode filenames in the import machinery
In-Reply-To: <1300665531.85.0.426527059221.issue11619@psf.upfronthosting.co.za>
Message-ID: <3cP4gL1MFPz7LkH@mail.python.org>


Roundup Robot added the comment:

New changeset df2fdd42b375 by Victor Stinner in branch 'default':
Close #11619: The parser and the import machinery do not encode Unicode
http://hg.python.org/cpython/rev/df2fdd42b375

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11619>
_______________________________________

From report at bugs.python.org  Mon Aug 26 22:38:34 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Aug 2013 20:38:34 +0000
Subject: [issue17588] runpy cannot run Unicode path on Windows
In-Reply-To: <1364753330.76.0.973974217823.issue17588@psf.upfronthosting.co.za>
Message-ID: <1377549514.53.0.887032841648.issue17588@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue has been fixed in issue #11619 by:

New changeset df2fdd42b375 by Victor Stinner in branch 'default':
Close #11619: The parser and the import machinery do not encode Unicode
http://hg.python.org/cpython/rev/df2fdd42b375

Thanks for the report!

(I don't plan to backport the fix to Python 3.3, it's a huge patch for a rare use case.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17588>
_______________________________________

From report at bugs.python.org  Mon Aug 26 22:39:04 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Aug 2013 20:39:04 +0000
Subject: [issue13758] compile() should not encode 'filename' (at least on
 Windows)
In-Reply-To: <1326253604.11.0.305060780894.issue13758@psf.upfronthosting.co.za>
Message-ID: <1377549544.86.0.292945213469.issue13758@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue has been fixed in issue #11619 by:

New changeset df2fdd42b375 by Victor Stinner in branch 'default':
Close #11619: The parser and the import machinery do not encode Unicode
http://hg.python.org/cpython/rev/df2fdd42b375

Thanks for the report!

(I don't plan to backport the fix to Python 3.3, it's a huge patch for a rare use case.)

----------
versions: +Python 3.4 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13758>
_______________________________________

From report at bugs.python.org  Mon Aug 26 22:39:17 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 26 Aug 2013 20:39:17 +0000
Subject: [issue17588] runpy cannot run Unicode path on Windows
In-Reply-To: <1364753330.76.0.973974217823.issue17588@psf.upfronthosting.co.za>
Message-ID: <1377549557.07.0.881647792409.issue17588@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17588>
_______________________________________

From report at bugs.python.org  Mon Aug 26 22:46:21 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 26 Aug 2013 20:46:21 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377549981.51.0.944939910754.issue17741@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 23:00:16 2013
From: report at bugs.python.org (Rob Bairos)
Date: Mon, 26 Aug 2013 21:00:16 +0000
Subject: [issue18812] PyImport_Import redundant calls to find module
In-Reply-To: <1377198011.48.0.462132559828.issue18812@psf.upfronthosting.co.za>
Message-ID: <1377550816.66.0.582916368436.issue18812@psf.upfronthosting.co.za>


Rob Bairos added the comment:

Okay, thanks for looking into it.
Cheers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18812>
_______________________________________

From report at bugs.python.org  Mon Aug 26 23:08:13 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 26 Aug 2013 21:08:13 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377551293.89.0.569927002294.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

By the way, if memory serves, compiling with --with-pydebug changes the memory layout of Python objects, so a Python compiled this way _cannot_ be used successfully with extension modules that were compiled without the same options.  Did you rebuild your extensions too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Mon Aug 26 23:31:01 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 26 Aug 2013 21:31:01 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377552661.75.0.33986109413.issue17741@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Stefan Behnel wrote:
> ... I still wonder why I'm the one writing all the patches ...

I imagine for the same reasons that I offered to write Enum:  I had definite ideas about how it should be, it is sometimes easier to explain with working code than with prose, and I wanted to contribute to Python.

I have to agree with Eli, though.  Wading through the accusations to get to the ideas is not helping your cause.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Aug 26 23:48:59 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Mon, 26 Aug 2013 21:48:59 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377553739.74.0.999262716969.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Yes, I have rebuilt all python modules but even gdb exited on startup due to python ABI change. I am using Gentoo Linux (https://bugs.gentoo.org/show_bug.cgi?id=482348) and unless python-updater forgot to include some package in the listing of those needed to be recompiled, I am sane. And becuase gdb could not even start up I *hope* those no recompiled yet would NOT work AT ALL.

Thanks for clarification, I thought that I might reach some internal number (the serial number as you say) in python and run out of some internal counters on objects. Actually, I hit these issues because I wondered why some of my application tests fail. Although all tests crunch a really lot of data they merely do the same in the end: draw charts using matplotlib which uses numpy. I have huge lists which I recently converted to generators (if possible) and now I even use imap(), izip(), ifilter() from itertools. One of the crashed tests has 153 levels in gdb stacktrace and few lines from the very top/outer already had the izip() objects. But the tests which crashed are not so huge like others, maybe take just 1/10 of the size of others, so I wonder why these failed.

I think some crashes are related to me deleting explictly a huge list in my code even before leaving a function. Or maybe returning such lists between child/parent functions?

Could valgring or something else help to find who is overwriting data of others? But I don't have experience with using it.

I think this _figure.clear() crash could be manifestation of python deleting a wrong object/pointer. Some ugly for loops over lists took ... don't know how much but in total even 26GB of RAM was reserved by the process (most of it also as residual memory requirement). With itertools() I got down 10x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Tue Aug 27 01:25:58 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 26 Aug 2013 23:25:58 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1377559558.88.0.191363572451.issue18844@psf.upfronthosting.co.za>


Madison May added the comment:

I realize its probably quite early to begin putting a patch together, but here's some preliminary code for anyone interested.  It builds off of the "common task" example in the docs and adds in validation for the weights list.

There are a few design decisions I'd like to hash out.  
In particular: 

  - Should negative weights cause a ValueError to be raised, or should they be converted to 0s?
  - Should passing a list full of zeros as the weights arg raise a ValueError or be treated as if no weights arg was passed?

----------
keywords: +patch
Added file: http://bugs.python.org/file31479/weighted_choice.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Tue Aug 27 01:33:08 2013
From: report at bugs.python.org (Valerie Lambert)
Date: Mon, 26 Aug 2013 23:33:08 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>
Message-ID: <1377559988.0.0.204757077917.issue18623@psf.upfronthosting.co.za>


Valerie Lambert added the comment:

I've added a new test that uses fork() and os.abort(), then asserts os.WCOREDUMP() is false. 
However, this test is currently failing. Is my test incorrect, or is this an issue with SuppressCoreFiles() itself?

If its a problem with the test I'm guessing it might have to do with how os.WCOREDUMP() decides whether a process has dumped its core or not. Is there another way we could go about this test?

----------
Added file: http://bugs.python.org/file31480/issue-18623_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18623>
_______________________________________

From report at bugs.python.org  Tue Aug 27 01:33:19 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 26 Aug 2013 23:33:19 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377559999.98.0.706192059542.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

Well, if you delete a giant list, and the list held the only references remaining to the objects the list contained, then the memory for those objects will be free'd, one object at a time.  A debug build would then detect the memory corruption in those objects.  But the corruption has nothing to do with deleting the list then - deleting the list would merely trigger the code that _detects_ the (pre-existing) corruption.

I can just urge you again to try to find a failing test as small and fast as possible.  You feel lost now precisely because you're wandering through a _mountain_ of code ;-)

If you want to play with the debug serial numbers, you can set a breakpoint in function bumpserialno() (in Python's Objects/obmalloc.c).  This is the entire function:

static void
bumpserialno(void)
{
    ++serialno;
}

The function exists so you _can_ easily set a breakpoint whenever `serialno` is increased (this function is the only place serialno is changed).

What I _expect_ you'll find is that serialno never gets anywhere near 8155854715.  If so, that just says again that the copy of serialno made when the corrupted object was created got corrupted (overwritten) by some bad C (or C++) code.  It can't tell us who overwrote it, or when.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Tue Aug 27 02:43:02 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 27 Aug 2013 00:43:02 +0000
Subject: [issue18845] 2.7.5-r2: Fatal Python error: Segmentation fault
In-Reply-To: <1377546426.38.0.266867499434.issue18845@psf.upfronthosting.co.za>
Message-ID: <1377564182.48.0.663550556773.issue18845@psf.upfronthosting.co.za>


Tim Peters added the comment:

Note that the same poster is also reporting memory corruption in issue 18843.  I suggest ignoring this one unless/until the earlier bug is resolved (memory corruption can easily cause a segfault - or any other kind of error).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18845>
_______________________________________

From report at bugs.python.org  Tue Aug 27 03:21:36 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 27 Aug 2013 01:21:36 +0000
Subject: [issue17902] Document that _elementtree C API cannot use custom
 TreeBuilder for iterparse or IncrementalParser
In-Reply-To: <1367614578.64.0.34953241054.issue17902@psf.upfronthosting.co.za>
Message-ID: <1377566496.87.0.3638890359.issue17902@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Aaron - could you describe your use case of passing a custom parser into iterparse? We're currently considering deprecating the feature of passing a parser into iterparse in a future release (this is being discussed in issue 17741).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17902>
_______________________________________

From report at bugs.python.org  Tue Aug 27 03:34:25 2013
From: report at bugs.python.org (SSmith)
Date: Tue, 27 Aug 2013 01:34:25 +0000
Subject: [issue18846] python.exe stdout stderr issues again
Message-ID: <1377567265.93.0.22027447734.issue18846@psf.upfronthosting.co.za>


New submission from SSmith:

python.exe sends its output to stderr instead of stdout.
Writing the following to the command line highlight the issue:
[ in]>python.exe --version 1> null   #redirects stdout to null
[out]>Python 2.7.5

[ in]>python.exe --version 2> null   #redirects stderr to null
[out]>

Python 3.3 has exactly the same issue.

Python 3.4alpha now, although it gives the correct output with the --version switch...:
[ in]>python --version 1> null
[out]>

[ in]>python --version 2> null
[out]>Python 3.4.0a1

...still invoking a simple pyton.exe  (switchless), prints its default output to stderr:
[ in]>python 1> null
[out]>Python 3.4.0a1 (v3.4.0a1:46535f65e7f3, Aug  3 2013, 22:59:31) [MSC v.1600 32 bit (Intel)] on win32
[out]>Type "help", "copyright", "credits" or "license" for more information.
[out]>>>


[ in]>python 2> null
[out]>>>

Some notes/refs:
Incomplete fix in 3.4a http://bugs.python.org/issue18338

----------
components: Interpreter Core
messages: 196257
nosy: SSmith
priority: normal
severity: normal
status: open
title: python.exe stdout stderr issues again
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18846>
_______________________________________

From report at bugs.python.org  Tue Aug 27 04:01:16 2013
From: report at bugs.python.org (Phil Webster)
Date: Tue, 27 Aug 2013 02:01:16 +0000
Subject: [issue18409] IDLE Improvements: Unit test for AutoComplete.py
In-Reply-To: <1373337231.6.0.320085332655.issue18409@psf.upfronthosting.co.za>
Message-ID: <1377568876.1.0.532375869316.issue18409@psf.upfronthosting.co.za>


Phil Webster added the comment:

I've attached my work so far in order to get feedback before I head too far in the wrong direction. I'm not sure if my addition of mock events and AutoCompleteWindow is the right way to go and I'm open to any guidance.

----------
keywords: +patch
Added file: http://bugs.python.org/file31481/18409test_autocomplete1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18409>
_______________________________________

From report at bugs.python.org  Tue Aug 27 04:11:20 2013
From: report at bugs.python.org (Aaron Oakley)
Date: Tue, 27 Aug 2013 02:11:20 +0000
Subject: [issue17902] Document that _elementtree C API cannot use custom
 TreeBuilder for iterparse or IncrementalParser
In-Reply-To: <1367614578.64.0.34953241054.issue17902@psf.upfronthosting.co.za>
Message-ID: <1377569480.34.0.0904623844155.issue17902@psf.upfronthosting.co.za>


Aaron Oakley added the comment:

>From memory, the use case at the time was using a custom TreeBuilder sub-class fed into a builtin XMLParser object. The code would construct a builder separately and keep a reference to it around. The builder would delegate calls to start(), data(), end(), and close() to super and save the completed tree when its close() was called.

    my_builder = CustomTreeBuilder()
    et_parser = ET.XMLParser(target=my_builder)

    for (evt, elem) in ET.iterparse("...", events, parser=et_parser):
        pass  # Do first processing

    tree = my_builder.root  # Saved tree

It was done like this initially so that some data (I can't recall exactly what) from the XML input could be processed first very conveniently using the parse events from iterparse while allowing the whole tree to be retrieved afterwards.

That said, the project later moved to using lxml for various features not contained in xml.etree.ElementTree, and I don't think the process I described is still being used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17902>
_______________________________________

From report at bugs.python.org  Tue Aug 27 04:57:46 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 27 Aug 2013 02:57:46 +0000
Subject: [issue18177] Incorect quote marks in code section-headers in PDF
 version of docs
In-Reply-To: <1370829780.84.0.0627044566719.issue18177@psf.upfronthosting.co.za>
Message-ID: <1377572266.41.0.416521350498.issue18177@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18177>
_______________________________________

From report at bugs.python.org  Tue Aug 27 05:15:40 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 27 Aug 2013 03:15:40 +0000
Subject: [issue18846] python.exe stdout stderr issues again
In-Reply-To: <1377567265.93.0.22027447734.issue18846@psf.upfronthosting.co.za>
Message-ID: <1377573340.38.0.290586126823.issue18846@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Will be fixed in Python 3.4 per #18338?

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed
versions:  -Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18846>
_______________________________________

From report at bugs.python.org  Tue Aug 27 05:41:41 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 27 Aug 2013 03:41:41 +0000
Subject: [issue17902] Document that _elementtree C API cannot use custom
 TreeBuilder for iterparse or IncrementalParser
In-Reply-To: <1377569480.34.0.0904623844155.issue17902@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda9A8JPzWGrpFr_YTFSxwmUtFQcSE8xvs_voftQdwou3_w@mail.gmail.com>


Eli Bendersky added the comment:

On Mon, Aug 26, 2013 at 7:11 PM, Aaron Oakley <report at bugs.python.org>wrote:

>
> Aaron Oakley added the comment:
>
> >From memory, the use case at the time was using a custom TreeBuilder
> sub-class fed into a builtin XMLParser object. The code would construct a
> builder separately and keep a reference to it around. The builder would
> delegate calls to start(), data(), end(), and close() to super and save the
> completed tree when its close() was called.
>
>     my_builder = CustomTreeBuilder()
>     et_parser = ET.XMLParser(target=my_builder)
>
>     for (evt, elem) in ET.iterparse("...", events, parser=et_parser):
>         pass  # Do first processing
>
>     tree = my_builder.root  # Saved tree
>
> It was done like this initially so that some data (I can't recall exactly
> what) from the XML input could be processed first very conveniently using
> the parse events from iterparse while allowing the whole tree to be
> retrieved afterwards.
>
> That said, the project later moved to using lxml for various features not
> contained in xml.etree.ElementTree, and I don't think the process I
> described is still being used.
>

Thanks for the information, Aaron; much appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17902>
_______________________________________

From report at bugs.python.org  Tue Aug 27 06:01:47 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 27 Aug 2013 04:01:47 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1377545706.34.0.416759054466.issue17741@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda_L_x+scUedofJnEwz0iQBOR3C4kNtcUbGE47XHxB8g2g@mail.gmail.com>


Eli Bendersky added the comment:

On Mon, Aug 26, 2013 at 12:35 PM, Stefan Behnel <report at bugs.python.org>wrote:

>
> Stefan Behnel added the comment:
>
> Here is a proof-of-concept patch that integrates the functionality of the
> IncrementalParser into the XMLParser. I ended up reusing most of Antoines
> implementation and test suite. In case he'll look back into this ticket at
> some point, I'll put a "thank you" here.
>
> The patch certainly needs more cleanup, but it shows where things are
> going and passes all tests.
>

OK, I looked at the patch. So I think I understood your verbal proposal
correctly earlier. And as I said then, I don't like it. I believe Nick has
summarized nicely why heaping everything into XMLParser is a bad idea, but
since you went the extra mile and made a patch, I will try to provide a
more expanded rationale.

Putting _setevents aside for the moment, XMLParser is a clean and simple
API. Its output is only "push" (by calling callbacks on the target). It
doesn't deal with Elements at all. It decomposes the input XML and produces
push events. That's it. It doesn't even have to interact with the target to
a larger extent than pushing callback calls to it.

You propose to add a completely different mode of operation to it,
controlled by a constructor flag. In "collect_events mode", XMLParser
undergoes a transformation. It becomes a pull API. It starts interacting
with the target more deeply by using it to produce elements for events.
Coupled with "weird" targets, its semantics become totally unclear.

So it's a single class that acts completely differently based on an
argument. This is very unpythonic. But things get worse. XMLParser is not
supposed to be an isolated entity. Users should be able to implement custom
parsers that provide its API. When the API is simple - feed/close and some
callbacks, replacing/ehnancing/faking it is easy. When the API is complex
-- two different modes of operation -- it's considerably more difficult.

That's the gist of it. Sticking to the current design of separation of
concerns between the parser and the target/treebuilder is IMO the better
way looking forward. In the mean-time, a helper class for asynchronous
parsing is useful and timely. By restricting its API, changing its
underlying implementation will be easy in the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Tue Aug 27 08:19:52 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 27 Aug 2013 06:19:52 +0000
Subject: [issue18763] subprocess: file descriptors should be closed after
 preexec_fn is called
In-Reply-To: <1376691835.07.0.666456900735.issue18763@psf.upfronthosting.co.za>
Message-ID: <1377584392.34.0.443968531751.issue18763@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Thanks!  Backported to subprocess32 in https://code.google.com/p/python-subprocess32/source/detail?r=4ba30d9c64296ea0d2959790ab22d0f1a2678064

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18763>
_______________________________________

From report at bugs.python.org  Tue Aug 27 08:24:52 2013
From: report at bugs.python.org (Bernie Keimel)
Date: Tue, 27 Aug 2013 06:24:52 +0000
Subject: [issue18847] Einladung in mein Netzwerk bei LinkedIn
Message-ID: <1817855663.697017.1377584689965.JavaMail.app@ela4-app4300.prod>


New submission from Bernie Keimel:

LinkedIn
------------

Ich m?chte Sie zu meinem beruflichen Netzwerk auf LinkedIn hinzuf?gen.

- Bernard Keimel

Bernard Keimel
Business bei privat
Berlin und Umgebung, Deutschland

Best?tigen Sie, dass Sie Bernard Keimel kennen:
https://www.linkedin.com/e/-3qcne3-hkuqctnf-28/isd/16078050493/NNc4mKPz/?hs=false&tok=2zVN7V8rC0lBU1

--
Sie erhalten Einladungen zum Netwerkbeitritt per E-Mail. Klicken Sie hier, wenn Sie kein Interesse daran haben:
http://www.linkedin.com/e/-3qcne3-hkuqctnf-28/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I5347669664_1/?hs=false&tok=3HVMvi7QC0lBU1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct., Mountain View, CA 94043, USA

----------
messages: 196264
nosy: Bernie.Keimel
priority: normal
severity: normal
status: open
title: Einladung in mein Netzwerk bei LinkedIn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18847>
_______________________________________

From report at bugs.python.org  Tue Aug 27 08:26:30 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 27 Aug 2013 06:26:30 +0000
Subject: [issue18847] Einladung in mein Netzwerk bei LinkedIn
Message-ID: <1377584790.73.0.662153911379.issue18847@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
Removed message: http://bugs.python.org/msg196264

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18847>
_______________________________________

From report at bugs.python.org  Tue Aug 27 08:26:42 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 27 Aug 2013 06:26:42 +0000
Subject: [issue18847] spam
Message-ID: <1377584802.96.0.731145650951.issue18847@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
title: Einladung in mein Netzwerk bei LinkedIn -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18847>
_______________________________________

From report at bugs.python.org  Tue Aug 27 08:48:24 2013
From: report at bugs.python.org (Sworddragon)
Date: Tue, 27 Aug 2013 06:48:24 +0000
Subject: [issue18836] Potential race condition in exceptions
In-Reply-To: <1377497509.71.0.034362539056.issue18836@psf.upfronthosting.co.za>
Message-ID: <1377586104.94.0.15768926653.issue18836@psf.upfronthosting.co.za>


Sworddragon added the comment:

> but what if there is a bug in your code?

Bugs in a python application can be fixed by the user while a specific behavior of the interpreter can't.

Maybe you are also thinking in the wrong direction. Nobody wants a solution that traps the user forever. Also KeyboardInterrupt is not the only problem that is affected by this race condition (but it is the best example to demonstrate it).


But I have made some thoughts about a potential solution (maybe it needs fine-tuning, depending on the python developing-policies or if I have overlooked something):

The idea contains overloading on a try/except-block. We will have the old (current) except block that acts as we know it and we will have a function-like except block "except(string_message, int_exitcode):". The function-like except block is a policy for any nested exception. Instead of triggering the nested exception it will print the first argument to stderr and exit with the second argument. While the interpreter is doing this as a built-in call it disables any potential exception-triggering in this time. This solution will eliminate the race condition without catching the user in an infinite recursion. What do you think of this idea?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18836>
_______________________________________

From report at bugs.python.org  Tue Aug 27 08:48:50 2013
From: report at bugs.python.org (py.user)
Date: Tue, 27 Aug 2013 06:48:50 +0000
Subject: [issue18848] In unittest.TestResult .startTestRun() and
 .stopTestRun() methods don't work
Message-ID: <1377586130.68.0.700857287739.issue18848@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/library/unittest.html#unittest.TestResult.startTestRun
http://docs.python.org/3/library/unittest.html#unittest.TestResult.stopTestRun



result.py:

#!/usr/bin/env python3

import unittest

class Test(unittest.TestCase):
    def test_1(self):
        print('test_1')

    def test_2(self):
        print('test_2')
        self.fail('msg')
    
class Result(unittest.TestResult):
    def startTestRun(self, test):
        print('starttestrun', test)

    def stopTestRun(self, test):
        print('stoptestrun', test)

    def startTest(self, test):
        print('starttest', test)

    def stopTest(self, test):
        print('stoptest', test)

result = Result()
suite = unittest.defaultTestLoader.loadTestsFromTestCase(Test)
suite.run(result)

print(result)



output:

[guest at localhost result]$ ./result.py 
starttest test_1 (__main__.Test)
test_1
stoptest test_1 (__main__.Test)
starttest test_2 (__main__.Test)
test_2
stoptest test_2 (__main__.Test)
<__main__.Result run=0 errors=0 failures=1>
[guest at localhost result]$



I tried also print messages to a file - same thing

----------
components: Library (Lib)
messages: 196266
nosy: py.user
priority: normal
severity: normal
status: open
title: In unittest.TestResult .startTestRun() and .stopTestRun() methods don't work
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18848>
_______________________________________

From report at bugs.python.org  Tue Aug 27 09:15:52 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 27 Aug 2013 07:15:52 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377587752.16.0.513918110729.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> Putting _setevents aside for the moment,

Agreed, obviously.


> XMLParser is a clean and simple API. Its output is only "push" (by calling callbacks on the target). It doesn't deal with Elements at all.

We already agreed on that, too. Keep things simple.


> It decomposes the input XML and produces push events. That's it. It doesn't even have to interact with the target to a larger extent than pushing callback calls to it.

It does, though. That's essentially how iterparse works. I.e. the API between parser and target that I'm using here is already there. And has been for years. And I think that the feature in question shows that this was a particularly good design. Thank you Fredrik!


> You propose to add a completely different mode of operation to it, controlled by a constructor flag. In "collect_events mode", XMLParser undergoes a transformation.

We clearly disagree here.


> Coupled with "weird" targets, its semantics become totally unclear.

Try to come up with a patch for your own proposal that avoids that. You will notice that you will be using the existing protocol, thus the target will continue to be able to do what it wants. If it's a weird target, then it's a weird target because the user said so. But it's the target's very own concern to do expected things (build a tree) or do weird things (whatever an example for this is).

Except when you disallow using user defined targets, but then, that's an arbitrary restriction that ignores what is there already.

As long as you want to keep up the existing separation of concern between parser and target (and we agreed on that being a good thing), and as long as you don't impose arbitrary (and arbitrarily complex) restrictions on user code, you will not be able to prevent the target from doing "weird" things that impact the events being collected by whatever interface you choose for this. And why should you?


> XMLParser is not supposed to be an isolated entity. Users should be able to implement custom parsers that provide its API. When the API is simple - feed/close and some callbacks, replacing/ehnancing/faking it is easy. When the API is complex -- two different modes of operation -- it's considerably more difficult.

That's only true when you use it for incremental event parsing. If you don't, that part of the API doesn't have to bother you. If you want to implement a custom parser that doesn't support event collection, then simply don't support the "collect_events" keyword argument and you're done. Implement read_events() by returning an empty iterator, if you like, that's up to you. If you want to write a target that prevents parsers from keeping tree fragments alive in memory, simply return None from your callback methods and you're done. If you want to write a target that changes the Elements that the parser collects, then you can do that. Yes, those are actually features. And you could already do most of this before.

Remember that it's the users using the parser and providing (or implementing) the target. We should let them.


I'm sorry if I sound offensive, but most of what I read as counter arguments in this ticket so far was either incomplete or (sometimes) even plain wrong. Some seemed pretty close to FUD, but maybe that's just me (and I'm guilty here too, I guess - sorry for that). Now, how could this discussion possibly give the me impression that everyone has the same level of understanding? Even your comment about "weird" targets, right above, after going through all of this discussion, makes me wonder if you really know how all of this works.

Please take a closer look at the original code before Antoine changed it. Play with the parser targets a bit. That will help you understand this issue better.


Also, if you want to come up with a patch that implements approach 3), i.e. a class between parser and target, then please do. I tried it (the incomplete and partially fake patch is attached to this ticket), and my take on it is that it's too complex and requires some rather non-trivial changes, including user visible ones. So, based on that experience, I decided that it would be better to keep things simple and integrate the feature more closely with what is there anyway. I think it might help if you went through the same experience.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Tue Aug 27 10:14:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Aug 2013 08:14:48 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
 locals and globals when they are not wanted
Message-ID: <1377591288.43.0.0475663387964.issue1565525@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Tue Aug 27 10:27:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Aug 2013 08:27:36 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>
Message-ID: <1377592056.61.0.475718560961.issue18623@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> If its a problem with the test I'm guessing it might have to do with how 
> os.WCOREDUMP() decides whether a process has dumped its core or not.

You are right, the status code doesn't seem affected by whether the core file was actually dumped or not:

$ ulimit -c
0
$ python -c "import os; os.abort()"; echo $?
Abandon
134
$ ulimit -c unlimited
$ python -c "import os; os.abort()"; echo $?
Abandon (core dumped)
134

And of course:

>>> os.WCOREDUMP(134)
True


I don't think there's any reliable way to test this: modern Linux kernels can intercept core file generation and run an executable instead (think Ubuntu's apport), so the only thing remaining to do is to just check that the context manager "works", i.e. doesn't raise anything.

(see http://linux.die.net/man/5/core "Piping core dumps to a program")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18623>
_______________________________________

From report at bugs.python.org  Tue Aug 27 10:58:41 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Tue, 27 Aug 2013 08:58:41 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
Message-ID: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>


New submission from Vlad Shcherbina:

When directory exists with a name chosen for new temporary file, OSError with EACCESS errno is thrown on windows, while attempts to chose another name only happen on EEXIST errors.


To reproduce, run
--------------- 8< -----------------
import sys
import tempfile
import os

print sys.platform
print sys.version

# Mock random names to ensure collision.
tempfile._RandomNameSequence = lambda: iter(['a', 'a', 'b'])

d = tempfile.mkdtemp()
print d

try:
    print tempfile.NamedTemporaryFile().name
finally:
    os.rmdir(d)
--------------- >8 -----------------


Expected result:
win32
2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)]
...\tmpa
...\tmpb


Actual result:
win32
2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)]
c:\users\shcher~1\appdata\local\temp\tmpa
Traceback (most recent call last):
  File "hz.py", line 13, in <module>
    print tempfile.NamedTemporaryFile().name
  File "C:\python_27_amd64\files\lib\tempfile.py", line 454, in NamedTemporaryFile
    (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags)
  File "C:\python_27_amd64\files\lib\tempfile.py", line 235, in _mkstemp_inner
    fd = _os.open(file, flags, 0600)
OSError: [Errno 13] Permission denied: 'c:\\users\\shcher~1\\appdata\\local\\temp\\tmpa'

----------
components: Library (Lib), Windows
messages: 196269
nosy: Vlad.Shcherbina
priority: normal
severity: normal
status: open
title: Failure to try another name for tempfile when directory with chosen name exists on windows
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18849>
_______________________________________

From report at bugs.python.org  Tue Aug 27 11:25:57 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 27 Aug 2013 09:25:57 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1377587752.16.0.513918110729.issue17741@psf.upfronthosting.co.za>
Message-ID: <CADiSq7d2CyfpPdbcykWut4N0xBjbYdO4TY2b0doCwRH1YbpHdQ@mail.gmail.com>


Nick Coghlan added the comment:

The whole point of the new API is not to replace XMLParser, but to
provide a convenience API to set up a particular combination of an
XMLParser with a particular kind of custom target. It just happens
that actually *implementing it* that way doesn't work right with the
current code. It is *not* necessary (or even appropriate) for it to
serve as a new building block, but as a convenience API to compose
*existing* building blocks in a particular way (or should be, except
that composition doesn't currently work right).

Once the underlying deficiencies are fixed, then the event capturing
target can be exposed directly, but in the meantime, the *composed*
version can be exposed by relying on internal APIs.

We could call the new class XMLParserWithEventCapturingTarget, but
that's a little clumsy :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Tue Aug 27 11:46:28 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 27 Aug 2013 09:46:28 +0000
Subject: [issue17908] Unittest runner needs an option to call
 gc.collect()	after each test
In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za>
Message-ID: <1377596788.16.0.222328275061.issue17908@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17908>
_______________________________________

From report at bugs.python.org  Tue Aug 27 11:50:51 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 27 Aug 2013 09:50:51 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
Message-ID: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>


New submission from Michele Orr?:

Got from irc; 
<JerryKwan> python bug in xml.etree.ElementTree, from version 2.7 to 3.2 http://www.reddit.com/r/Python/comments/1l6cta/python_bug_in_xmletreeelementtree/

I think we should keep consistency with lxml and forbid control chars in advance. 
<https://en.wikipedia.org/wiki/Valid_characters_in_XML#XML_1.1>

Attaching the test file proving the issue, slightly modified to work on 2.7 and 3.x

----------
files: test.py
messages: 196271
nosy: maker
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree accepts control chars.
Added file: http://bugs.python.org/file31482/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Tue Aug 27 11:52:02 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 27 Aug 2013 09:52:02 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377597122.03.0.598217042415.issue18850@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


----------
components: +Library (Lib), XML
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Tue Aug 27 12:04:40 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 27 Aug 2013 10:04:40 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1377592056.61.0.475718560961.issue18623@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2oP26pax83Et9fOndEJJw2FrohZMwS5sFXwO=oW153+g@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

The test works for me. The only problem is that faulthandler dumps a
stack: it might be better to use subprocess with stderr=devnull).

As for the status code, it looks like a bash bug:
"""
$ cat /tmp/test_core.py
import os

if os.fork() == 0:
    os.abort()
else:
    pid, status = os.waitpid(-1, 0)
    print("%d: %s" % (status, os.WCOREDUMP(status)))
$ python /tmp/test_core.py
134: True
$ ulimit -c 0
$ python /tmp/test_core.py
6: False
$ python -c "print(0x80 | 6)"
134
"""

And it's funny, because bash does detect the coredump generation, compare:
"""
$ python -c "import os; os.abort()"; echo $?
Abandon
134
"""

to

"""
$ python -c "import os; os.abort()"; echo $?
Abandon (core dumped)
134
"""

I had a quick look at the code, and indeed there's a bug: there's a
function rebuilding the exit status from the exit code:

"""
static int
process_exit_status (status)
     WAIT status;
{
  if (WIFSIGNALED (status))
    return (128 + WTERMSIG (status));
  else if (WIFSTOPPED (status) == 0)
    return (WEXITSTATUS (status));
  else
    return (EXECUTION_SUCCESS);
}
"""

Unfortunately, adding 128 sets the coredump flag every time,
regardless of the actual coredump status.
Never thought I'd encounter such a bug in bash :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18623>
_______________________________________

From report at bugs.python.org  Tue Aug 27 12:04:58 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 27 Aug 2013 10:04:58 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1377597898.34.0.533485358486.issue11798@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Looks good but review comments worth to be applied or rejected with reasonable note.

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Tue Aug 27 12:37:21 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 27 Aug 2013 10:37:21 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377599841.03.0.176667545523.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> The whole point of the new API is not to replace XMLParser, but to provide a convenience API to set up a particular combination of an XMLParser with a particular kind of custom target.

Ok, but I'm saying that we don't need that. It's all there, it all comes together at the interfaces of the parser. The two-way communication between parser and target already exists and is used by iterparse().

So, what I'm advocating is that we should not complicate the module interface with a new class (and eventually two classes) at all. Instead, we should just expose the *existing* interface of the parser in two ways, once as callbacks and once as collected events. I find that much easier to explain than any of the other proposals I've seen so far.

This is really not about doing it this way because it's technically too difficult to do differently. It's about keeping things simple for users and well integrated with what's there.

BTW, Eli asked for working code before we discuss. I've provided it. Now I would like to see working code for the proposed three-level design in order to make sure it actually works and feels right. I've already said that I've tried it and it didn't feel right. We can continue to discuss hot air for another month or two, or we can stick to discussing real code and real APIs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Tue Aug 27 13:23:08 2013
From: report at bugs.python.org (Matt McClure)
Date: Tue, 27 Aug 2013 11:23:08 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1377597898.34.0.533485358486.issue11798@psf.upfronthosting.co.za>
Message-ID: <BF6D7C1B-4B6D-4FB6-BEA4-94F83981B8A2@gmail.com>


Matt McClure added the comment:

Andrew,

I didn't understand your message. Are you asking me to change the patch somehow? Or asking Michael to review and apply it?

Best,
Matt

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Tue Aug 27 14:01:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Aug 2013 12:01:55 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377604915.57.0.389118525837.issue18850@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +eli.bendersky, scoder, serhiy.storchaka
versions: +Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Tue Aug 27 14:03:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Aug 2013 12:03:07 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1377604987.85.0.519978696927.issue18849@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +georg.brandl, ncoghlan, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18849>
_______________________________________

From report at bugs.python.org  Tue Aug 27 14:06:55 2013
From: report at bugs.python.org (Jan-Wijbrand Kolman)
Date: Tue, 27 Aug 2013 12:06:55 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
Message-ID: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>


New submission from Jan-Wijbrand Kolman:

An internal library that heavily uses subprocess.Popen() started failing its automated tests when we upgraded from Python 2.7.3 to Python 2.7.5. This library is used in a threaded environment. After debugging the issue, I was able to create a short Python script that demonstrates the error seen as in the failing tests.

This is the script (called "threadedsubprocess.py"):

===
import time
import threading
import subprocess

def subprocesscall():
    p = subprocess.Popen(
        ['ls', '-l'],
        stdin=subprocess.PIPE,
        stdout=subprocess.PIPE,
        stderr=subprocess.PIPE,
        )
    time.sleep(2) # simulate the Popen call takes some time to complete.
    out, err = p.communicate()
    print 'succeeding command in thread:', threading.current_thread().ident

def failingsubprocesscall():
    try:
        p = subprocess.Popen(
            ['thiscommandsurelydoesnotexist'],
            stdin=subprocess.PIPE,
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE,
            )
    except Exception as e:
        print 'failing command:', e, 'in thread:', threading.current_thread().ident

print 'main thread is:', threading.current_thread().ident

subprocesscall_thread = threading.Thread(target=subprocesscall)
subprocesscall_thread.start()
failingsubprocesscall()
subprocesscall_thread.join()
===

Note: this script does not exit with an IOError when ran from Python 2.7.3. It does fail at least 50% of the times when ran from Python 2.7.5 (both on the same Ubuntu 12.04 64-bit VM).

The error that is raised on Python 2.7.5 is this:

==
/opt/python/2.7.5/bin/python ./threadedsubprocess.py 
main thread is: 139899583563520
failing command: [Errno 2] No such file or directory 139899583563520
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/opt/python/2.7.5/lib/python2.7/threading.py", line 808, in __bootstrap_inner
    self.run()
  File "/opt/python/2.7.5/lib/python2.7/threading.py", line 761, in run
    self.__target(*self.__args, **self.__kwargs)
  File "./threadedsubprocess.py", line 13, in subprocesscall
    out, err = p.communicate()
  File "/opt/python/2.7.5/lib/python2.7/subprocess.py", line 806, in communicate
    return self._communicate(input)
  File "/opt/python/2.7.5/lib/python2.7/subprocess.py", line 1379, in _communicate
    self.stdin.close()
IOError: [Errno 9] Bad file descriptor

close failed in file object destructor:
IOError: [Errno 9] Bad file descriptor
==

When comparing the subprocess module from Python 2.7.3 to Python 2.7.5 I see the Popen()'s __init__() call indeed now explicitly closes the stdin, stdout and stderr file descriptors in case executing the command somehow fails. This seems to be an intended fix applied in Python 2.7.4 to prevent leaking file descriptors (http://hg.python.org/cpython/file/ab05e7dd2788/Misc/NEWS#l629).

The diff between Python 2.7.3 and Python 2.7.5 that seems to be relevant to this issue is in the Popen __init__():

==
@@ -671,12 +702,33 @@
          c2pread, c2pwrite,
          errread, errwrite) = self._get_handles(stdin, stdout, stderr)

-        self._execute_child(args, executable, preexec_fn, close_fds,
-                            cwd, env, universal_newlines,
-                            startupinfo, creationflags, shell,
-                            p2cread, p2cwrite,
-                            c2pread, c2pwrite,
-                            errread, errwrite)
+        try:
+            self._execute_child(args, executable, preexec_fn, close_fds,
+                                cwd, env, universal_newlines,
+                                startupinfo, creationflags, shell,
+                                p2cread, p2cwrite,
+                                c2pread, c2pwrite,
+                                errread, errwrite)
+        except Exception:
+            # Preserve original exception in case os.close raises.
+            exc_type, exc_value, exc_trace = sys.exc_info()
+
+            to_close = []
+            # Only close the pipes we created.
+            if stdin == PIPE:
+                to_close.extend((p2cread, p2cwrite))
+            if stdout == PIPE:
+                to_close.extend((c2pread, c2pwrite))
+            if stderr == PIPE:
+                to_close.extend((errread, errwrite))
+
+            for fd in to_close:
+                try:
+                    os.close(fd)
+                except EnvironmentError:
==

Note: I think to see a similar change in the subprocess.Popen() __init__() from Python-3.3.0 to Python-3.3.1.

----------
components: Library (Lib)
messages: 196276
nosy: janwijbrand
priority: normal
severity: normal
status: open
title: subprocess's Popen closes stdout/stderr filedescriptors used in another thread when Popen errors
type: behavior
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Tue Aug 27 14:16:01 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 27 Aug 2013 12:16:01 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377605761.82.0.354510828608.issue18850@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

This is a bit tricky in ET because it generally allows you to stick anything into the Element properties (and that's a feature). So catching this at tree building time (as lxml.etree does) isn't really possible.

However, at least catching it in the serialiser should be possible and would help. Regexes for well-formed tag names and text could do the job.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Tue Aug 27 14:20:14 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 27 Aug 2013 12:20:14 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377606014.19.0.0074889720562.issue18850@psf.upfronthosting.co.za>


Michele Orr? added the comment:

you mind if I try by myself to provide patch and unittest in the next few days?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Tue Aug 27 14:23:59 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 27 Aug 2013 12:23:59 +0000
Subject: [issue18800] Document Fraction's numerator and denominator properties
In-Reply-To: <1377104746.66.0.571132107535.issue18800@psf.upfronthosting.co.za>
Message-ID: <1377606239.36.0.741749610607.issue18800@psf.upfronthosting.co.za>


Madison May added the comment:

The docs page does mention, however, that Fraction inherits from numbers.Rational, and links to that page (http://docs.python.org/2/library/numbers.html#numbers.Rational). There the properties 'numerator' and 'denominator' are clearly documented.  Perhaps its still worth it to mention those properties on the Fraction docs page though, or to include them in one of the examples.

----------
nosy: +madison.may

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18800>
_______________________________________

From report at bugs.python.org  Tue Aug 27 14:29:41 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 27 Aug 2013 12:29:41 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377606581.55.0.144019347209.issue18850@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Go for it. That's usually the fastest way to get things done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Tue Aug 27 14:31:26 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 27 Aug 2013 12:31:26 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1377606686.11.0.84480123356.issue11798@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Matt, I've added new patch.

Will commit it after tomorrow if nobody object.

----------
Added file: http://bugs.python.org/file31483/issue11798.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Tue Aug 27 14:32:50 2013
From: report at bugs.python.org (Michael Foord)
Date: Tue, 27 Aug 2013 12:32:50 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1377606770.82.0.588946870233.issue11798@psf.upfronthosting.co.za>


Michael Foord added the comment:

Go ahead and commit. The functionality and patch are good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Tue Aug 27 14:46:59 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Aug 2013 12:46:59 +0000
Subject: [issue18836] Potential race condition in exceptions
In-Reply-To: <1377497509.71.0.034362539056.issue18836@psf.upfronthosting.co.za>
Message-ID: <1377607619.77.0.631163382869.issue18836@psf.upfronthosting.co.za>


R. David Murray added the comment:

Unless I'm completely misunderstanding (which I don't think I am), this is not a race condition, it is how the language is designed to operate.  The change you are proposing is a language-design level change that would require a PEP.  The appropriate place to discuss this the is the python-ideas list.

I'm going to close this issue.  If you get a positive response on python-ideas, you can reopen it with a link to the discussion.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18836>
_______________________________________

From report at bugs.python.org  Tue Aug 27 14:52:03 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Aug 2013 12:52:03 +0000
Subject: [issue18848] In unittest.TestResult .startTestRun() and
 .stopTestRun() methods don't work
In-Reply-To: <1377586130.68.0.700857287739.issue18848@psf.upfronthosting.co.za>
Message-ID: <1377607923.45.0.0798564120375.issue18848@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18848>
_______________________________________

From report at bugs.python.org  Tue Aug 27 14:56:12 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Aug 2013 12:56:12 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377608172.78.0.378535134098.issue18850@psf.upfronthosting.co.za>


R. David Murray added the comment:

Unless it is a security issue, this seems like the kind of fix that shouldn't be applied to maintenance releases.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Tue Aug 27 15:01:36 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Aug 2013 13:01:36 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377608496.4.0.886349438627.issue18851@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +gregory.p.smith, pitrou
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Tue Aug 27 15:15:08 2013
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 27 Aug 2013 13:15:08 +0000
Subject: [issue18852] Problem with pyreadline
Message-ID: <1377609308.01.0.92318264163.issue18852@psf.upfronthosting.co.za>


New submission from Thomas Heller:

In site.py, line 477, I find this code:

        # Reading the initialization (config) file may not be enough to set a
        # completion key, so we set one first and then read the file
        if 'libedit' in getattr(readline, '__doc__', ''):
            readline.parse_and_bind('bind ^I rl_complete')

I am using pyreadline on Windows, where readline.__doc__ is None.

So the above code crashes with this exception:

Python 3.4.0a1 (v3.4.0a1:46535f65e7f3, Aug  3 2013, 22:57:30) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Failed calling sys.__interactivehook__
Traceback (most recent call last):
  File "C:\Python34-64\lib\site.py", line 477, in register_readline
    if 'libedit' in getattr(readline, '__doc__', ''):
TypeError: argument of type 'NoneType' is not iterable

----------
components: Library (Lib)
keywords: 3.3regression
messages: 196285
nosy: theller
priority: normal
severity: normal
status: open
title: Problem with pyreadline
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18852>
_______________________________________

From report at bugs.python.org  Tue Aug 27 15:25:23 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 27 Aug 2013 13:25:23 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377609923.21.0.0687269632334.issue18850@psf.upfronthosting.co.za>


Michele Orr? added the comment:

I suppose it is, David, if in 2 minutes flat I can change your terminal name.

----------
Added file: http://bugs.python.org/file31484/inject.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Tue Aug 27 15:30:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Aug 2013 13:30:11 +0000
Subject: [issue18848] In unittest.TestResult .startTestRun() and
 .stopTestRun() methods don't work
In-Reply-To: <1377586130.68.0.700857287739.issue18848@psf.upfronthosting.co.za>
Message-ID: <1377610211.86.0.225903575198.issue18848@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +ezio.melotti, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18848>
_______________________________________

From report at bugs.python.org  Tue Aug 27 15:30:35 2013
From: report at bugs.python.org (Michael Foord)
Date: Tue, 27 Aug 2013 13:30:35 +0000
Subject: [issue18848] In unittest.TestResult .startTestRun() and
 .stopTestRun() methods don't work
In-Reply-To: <1377586130.68.0.700857287739.issue18848@psf.upfronthosting.co.za>
Message-ID: <1377610235.32.0.365010836767.issue18848@psf.upfronthosting.co.za>


Michael Foord added the comment:

It is the TextTestRunner that calls startTestRun and stopTestRun not the suite. 

The documentation could be improved to make that clear *or* the call could be moved into the TestSuite as not everybody uses the TextTestRunner. That would be a change in behaviour though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18848>
_______________________________________

From report at bugs.python.org  Tue Aug 27 15:31:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Aug 2013 13:31:09 +0000
Subject: [issue18852] Problem with pyreadline
In-Reply-To: <1377609308.01.0.92318264163.issue18852@psf.upfronthosting.co.za>
Message-ID: <1377610269.96.0.88999637785.issue18852@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18852>
_______________________________________

From report at bugs.python.org  Tue Aug 27 15:43:09 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Aug 2013 13:43:09 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377610989.91.0.760364300767.issue18850@psf.upfronthosting.co.za>


R. David Murray added the comment:

In that case, the fix needs to be applied to 3.2 and 2.6 as well.  Or at least considered for application.  It could be that this will break working (though dangerous) programs.  I'll leave it to folks more knowledgeable in this particular area than I to decide where the severity/backward compatibility line lies in this case.

----------
stage:  -> needs patch
type: behavior -> security
versions: +Python 2.6, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Tue Aug 27 15:45:50 2013
From: report at bugs.python.org (Sworddragon)
Date: Tue, 27 Aug 2013 13:45:50 +0000
Subject: [issue18836] Potential race condition in exceptions
In-Reply-To: <1377497509.71.0.034362539056.issue18836@psf.upfronthosting.co.za>
Message-ID: <1377611150.14.0.848216780687.issue18836@psf.upfronthosting.co.za>


Sworddragon added the comment:

> Unless I'm completely misunderstanding (which I don't think I am), this is not a race condition, it is how the language is designed to operate.

If it is intended not to be able to catch all exceptions and prevent a traceback being showed this should be indeed a PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18836>
_______________________________________

From report at bugs.python.org  Tue Aug 27 15:51:49 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 27 Aug 2013 13:51:49 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1377587752.16.0.513918110729.issue17741@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda_wTvmh6Uf5Lbc4XeD5VBzGGZ2WJvb-x1Yd8zLZAJjreg@mail.gmail.com>


Eli Bendersky added the comment:

I'm sorry if I sound offensive, but most of what I read as counter
> arguments in this ticket so far was either incomplete or (sometimes) even
> plain wrong. Some seemed pretty close to FUD, but maybe that's just me (and
> I'm guilty here too, I guess - sorry for that). Now, how could this
> discussion possibly give the me impression that everyone has the same level
> of understanding? Even your comment about "weird" targets, right above,
> after going through all of this discussion, makes me wonder if you really
> know how all of this works.
>
> Please take a closer look at the original code before Antoine changed it.
> Play with the parser targets a bit. That will help you understand this
> issue better.
>

Ah, awesome. Well, you can't say I didn't warn you, can you?

I am done discussing this issue with you, Stefan.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Tue Aug 27 16:04:27 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 27 Aug 2013 14:04:27 +0000
Subject: [issue18853] Got ResourceWarning unclosed file when running
 Lib/shlex.py demo
Message-ID: <1377612267.45.0.680080135941.issue18853@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

The python is compiled with --with-pydebug flag.

[sky at localhost cpython]$ cat /tmp/quote.txt 
manly "man" likes 'cute "cat"'
[sky at localhost cpython]$ ./python Lib/shlex.py /tmp/quote.txt 
Token: 'manly'
Token: '"man"'
Token: 'likes'
Token: '\'cute "cat"\''
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/quote.txt' mode='r' encoding='UTF-8'>

Attached the patch to close the file when running the demo.

----------
components: Library (Lib)
files: fix_resource_warning_shlex_test.patch
keywords: patch
messages: 196291
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Got ResourceWarning unclosed file when running Lib/shlex.py demo
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file31485/fix_resource_warning_shlex_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18853>
_______________________________________

From report at bugs.python.org  Tue Aug 27 16:05:12 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Aug 2013 14:05:12 +0000
Subject: [issue18854] is_multipart and walk should document their treatment of
 'message' parts.
Message-ID: <1377612312.75.0.466824716408.issue18854@psf.upfronthosting.co.za>


New submission from R. David Murray:

A 'message' part is not, in fact, a multipart in RFC terms.  (Only 'multipart' messages are multiparts.)  The email package models 'message' parts by making them single-element "multipart" messages, with the single element being a Message object representing the 'message' part's payload.

This is very useful; however, the fact that this is done should be documented in at least the is_multipart and walk methods.  As motivation for documenting this, consider a program that is looking for "the first part of type X" in a Message.  If an attached 'message' object has such a part, it would be discovered by a naive algorithm that uses 'walk', even though it is *inside* an attachment instead of part of the main message.  As for is_multipart, a naive reader of the documentation might expect that is_multipart would be true if and only if get_content_maintype == 'multipart', when this is in fact not true.

(I made these mistakes myself while implementing get_body and iter_parts in the new API additions.)

----------
components: email
messages: 196292
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: is_multipart and walk should document their treatment of 'message' parts.
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18854>
_______________________________________

From report at bugs.python.org  Tue Aug 27 16:15:18 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Aug 2013 14:15:18 +0000
Subject: [issue18852] site.py does not handle readline.__doc__ being None
In-Reply-To: <1377609308.01.0.92318264163.issue18852@psf.upfronthosting.co.za>
Message-ID: <1377612918.09.0.956877211377.issue18852@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't think __doc__ can ever not exist, so that code is just wrong :)

----------
keywords: +easy
nosy: +r.david.murray
stage:  -> needs patch
title: Problem with pyreadline -> site.py does not handle readline.__doc__ being None

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18852>
_______________________________________

From report at bugs.python.org  Tue Aug 27 16:20:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Aug 2013 14:20:04 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377613204.86.0.663479262833.issue18850@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue7727. Almost any other XML generation code (xml.sax.sautils.XMLGenerator, xml.dom.minidom.Element.writexml(), etc, but not plistlib.PlistWriter) has the same problem.

The problem with filtering control characters is that it will significantly slowdown XML generation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Tue Aug 27 16:22:23 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 27 Aug 2013 14:22:23 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377613343.57.0.834334476055.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Eli, I agree that we've put way more than enough time into the discussion by now. We all know each other's arguments and failed to convince each other.

Please come up with working code that shows that the approach you are advocating for the final implementation is doable and also helpful from an API user's point of view.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Tue Aug 27 16:26:31 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 27 Aug 2013 14:26:31 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377613591.73.0.981493978188.issue18850@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Michele, could you elaborate how you would exploit this issue as a security risk?

I mean, I can easily create a (non-)XML-document with control characters manually, and the parser would reject it.

What part of the create-to-serialise process exactly is a problem here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Tue Aug 27 16:56:21 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 27 Aug 2013 14:56:21 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1377615381.1.0.449041200433.issue11798@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Matt, would you sign licence agreement http://www.python.org/psf/contrib/ ?
The Python Software Fondation is asking all contributors to sign it.
Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Tue Aug 27 17:04:22 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 27 Aug 2013 15:04:22 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377615862.36.0.598330758678.issue18850@psf.upfronthosting.co.za>


Michele Orr? added the comment:

> Michele, could you elaborate how you would exploit this issue as a security risk?
Sure. What I meant in my message is: assume you have a script that simply stores each message it receives (from stdin, from a tcp stream, whatever) inside an xml tree like 
'<text>{message1}</text><text>{message2}<text>',
and prints the tree on SIGINT.

What I would expect is the xml document not to allow control chars, as "restricted and discouraged", and consistent with lxml. 
What instead happens is that the control chars are not handled, and thus anybody can send control chars in my terminal. Changing the terminal title is a trivial example of those. 

For sure an echo server may have the same issue, but the premises are different, because I expect to print just a byte stream.
Mentioning this fact in the documentation may be a possible solution, but I believe more that keeping consistency with lxml is the right way.

> I mean, I can easily create a (non-)XML-document with control characters manually, and the parser would reject it.
False? The parser is *not* rejecting control chars.
 
> What part of the create-to-serialise process exactly is a problem here?
ElementTree.tostring().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Tue Aug 27 17:16:10 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 27 Aug 2013 15:16:10 +0000
Subject: [issue18855] Inconsistent README filenames
Message-ID: <1377616570.1.0.108273179071.issue18855@psf.upfronthosting.co.za>


New submission from Madison May:

Is there any reason (other than backwards compatibility) that the names of README files are inconsistent?

README: 3 instances - root, /Mac, /Misc, /Tools
readme.txt: 2 instances - /PC, /PCbuild
README.txt: 1 instance - /Doc

----------
assignee: docs at python
components: Documentation
messages: 196299
nosy: docs at python, madison.may
priority: normal
severity: normal
status: open
title: Inconsistent README filenames

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18855>
_______________________________________

From report at bugs.python.org  Tue Aug 27 17:33:24 2013
From: report at bugs.python.org (Matt McClure)
Date: Tue, 27 Aug 2013 15:33:24 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1377617604.73.0.175074948574.issue11798@psf.upfronthosting.co.za>


Matt McClure added the comment:

Andrew,

I signed the agreement as matthewlmcclure and as matthewlmcclure-gmail. Is there any way I can merge those two user accounts?

I believe the original patch was Tom Wardill's. I just updated his patch.

----------
nosy: +matthewlmcclure

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Tue Aug 27 17:43:33 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Aug 2013 15:43:33 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1377618213.77.0.388819352303.issue11798@psf.upfronthosting.co.za>


R. David Murray added the comment:

There is no easy way to merge accounts in roundup.  If you've submitted the agreement, your "*" should show up in a bit :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Tue Aug 27 19:19:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Aug 2013 17:19:30 +0000
Subject: [issue18783] No more refer to Python "long"
In-Reply-To: <1376933723.97.0.818285065385.issue18783@psf.upfronthosting.co.za>
Message-ID: <3cPcJd2Pvvz7LkM@mail.python.org>


Roundup Robot added the comment:

New changeset 4d62a62ba44d by Serhiy Storchaka in branch '3.3':
Issue #18783: Removed existing mentions of Python long type in docstrings,
http://hg.python.org/cpython/rev/4d62a62ba44d

New changeset 0872257752c2 by Serhiy Storchaka in branch 'default':
Issue #18783: Removed existing mentions of Python long type in docstrings,
http://hg.python.org/cpython/rev/0872257752c2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18783>
_______________________________________

From report at bugs.python.org  Tue Aug 27 19:39:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Aug 2013 17:39:05 +0000
Subject: [issue18783] No more refer to Python "long"
In-Reply-To: <1376933723.97.0.818285065385.issue18783@psf.upfronthosting.co.za>
Message-ID: <1377625145.25.0.791957226686.issue18783@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Ezio and Terry for reviews.

> I presume you thought about it carefully in context.

Yes. Here can be any different types for which instances can be equal (1 == 1L, 1.0 == 1.0+0.0j).

> This kind of changes are a bit out of place in a patch like this.  They risk to
> introduce subtle problems and might go unnoticed during commit reviews.

I reverted code back to PyErr_SetString.

The only nontrivial changes are in Lib/pickletools.py, Lib/test/test_itertools.py and Lib/test/test_long.py (removed redundant handling of 'L' suffix in long representation).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18783>
_______________________________________

From report at bugs.python.org  Tue Aug 27 19:40:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Aug 2013 17:40:16 +0000
Subject: [issue18783] No more refer to Python "long"
In-Reply-To: <1376933723.97.0.818285065385.issue18783@psf.upfronthosting.co.za>
Message-ID: <1377625216.17.0.146481276202.issue18783@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18783>
_______________________________________

From report at bugs.python.org  Tue Aug 27 19:43:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Aug 2013 17:43:22 +0000
Subject: [issue18830] Remove duplicates from a result of getclasstree()
In-Reply-To: <1377442213.69.0.00603799982208.issue18830@psf.upfronthosting.co.za>
Message-ID: <1377625402.54.0.120249759368.issue18830@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18830>
_______________________________________

From report at bugs.python.org  Tue Aug 27 20:15:12 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 27 Aug 2013 18:15:12 +0000
Subject: [issue16201] socket.gethostbyname incorrectly parses ip
In-Reply-To: <1349983863.01.0.255097510924.issue16201@psf.upfronthosting.co.za>
Message-ID: <1377627312.24.0.9761667406.issue16201@psf.upfronthosting.co.za>


Michele Orr? added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16201>
_______________________________________

From report at bugs.python.org  Tue Aug 27 20:22:59 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 27 Aug 2013 18:22:59 +0000
Subject: [issue18564] Integer overflow in socketmodule
In-Reply-To: <1374861545.82.0.430674187566.issue18564@psf.upfronthosting.co.za>
Message-ID: <1377627779.81.0.509353284973.issue18564@psf.upfronthosting.co.za>


Michele Orr? added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18564>
_______________________________________

From report at bugs.python.org  Tue Aug 27 20:24:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Aug 2013 18:24:06 +0000
Subject: [issue18564] Integer overflow in socketmodule
In-Reply-To: <1374861545.82.0.430674187566.issue18564@psf.upfronthosting.co.za>
Message-ID: <1377627846.97.0.41274655163.issue18564@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, haven't you seen Charles-Fran?ois' comments on the review tool?
Click on the "review" link next to your patch :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18564>
_______________________________________

From report at bugs.python.org  Tue Aug 27 20:33:38 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 27 Aug 2013 18:33:38 +0000
Subject: [issue16083] HTTPServer does not correctly handle bad request line
In-Reply-To: <1348829642.54.0.0563748954245.issue16083@psf.upfronthosting.co.za>
Message-ID: <1377628418.7.0.800222805299.issue16083@psf.upfronthosting.co.za>


Michele Orr? added the comment:

Still is an issue, though. Exported on the current tip.

----------
versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file31486/issue16083.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16083>
_______________________________________

From report at bugs.python.org  Tue Aug 27 20:39:33 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 27 Aug 2013 18:39:33 +0000
Subject: [issue18830] Remove duplicates from a result of getclasstree()
In-Reply-To: <1377442213.69.0.00603799982208.issue18830@psf.upfronthosting.co.za>
Message-ID: <1377628773.42.0.117490145991.issue18830@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

What about if you extend the test coverage as well? Right now, we don't have test to test getclasstree method with unique parameter set to false.

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18830>
_______________________________________

From report at bugs.python.org  Tue Aug 27 20:44:00 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 27 Aug 2013 18:44:00 +0000
Subject: [issue18564] Integer overflow in socketmodule
In-Reply-To: <1374861545.82.0.430674187566.issue18564@psf.upfronthosting.co.za>
Message-ID: <1377629040.71.0.318053974143.issue18564@psf.upfronthosting.co.za>


Michele Orr? added the comment:

oops, didn't see :) thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18564>
_______________________________________

From report at bugs.python.org  Tue Aug 27 20:44:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Aug 2013 18:44:12 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>
Message-ID: <1377629052.37.0.618127220439.issue18623@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> As for the status code, it looks like a bash bug:

Your script gives different results here (on Ubuntu):

$ ulimit -c
0
$ ./python dumpcore.py 
6: False
$ ulimit -c unlimited
$ ./python dumpcore.py 
6: False

That's because Ubuntu overrides the core file pattern:

$ cat /proc/sys/kernel/core_pattern 
|/usr/share/apport/apport %p %s %c

If I ask for a regular core file, the script works:

$ sudo sh -c "echo core.%p > /proc/sys/kernel/core_pattern"
$ ./python dumpcore.py 
134: True

Which means the test really threatens to be unreliable (other systems may install similar mechanisms by default).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18623>
_______________________________________

From report at bugs.python.org  Tue Aug 27 21:19:21 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 27 Aug 2013 19:19:21 +0000
Subject: [issue18856] Added test coverage for calendar print functions
Message-ID: <1377631161.77.0.572665348858.issue18856@psf.upfronthosting.co.za>


New submission from Madison May:

Just redirected stdout to a string io object unittest.mock.patch() to add basic test coverage for calendar.py print functions (TextCalendary.prweek(), TextCalendar.prmonth(), TextCalendar.pryear(), and format()).

----------
components: Tests
files: calendar_print.diff
keywords: patch
messages: 196311
nosy: madison.may
priority: normal
severity: normal
status: open
title: Added test coverage for calendar print functions
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31487/calendar_print.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18856>
_______________________________________

From report at bugs.python.org  Tue Aug 27 21:25:08 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 27 Aug 2013 19:25:08 +0000
Subject: [issue18856] Added test coverage for calendar print functions
In-Reply-To: <1377631161.77.0.572665348858.issue18856@psf.upfronthosting.co.za>
Message-ID: <1377631508.52.0.539060972592.issue18856@psf.upfronthosting.co.za>


Madison May added the comment:

"...to a string io object USING unittest.mock.patch()..."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18856>
_______________________________________

From report at bugs.python.org  Tue Aug 27 21:26:40 2013
From: report at bugs.python.org (=?utf-8?q?Thomas_Wei=C3=9Fschuh?=)
Date: Tue, 27 Aug 2013 19:26:40 +0000
Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not
 match IDNA prefix
In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za>
Message-ID: <1377631600.35.0.7276310102.issue17997@psf.upfronthosting.co.za>


Changes by Thomas Wei?schuh <thomas at t-8ch.de>:


----------
nosy: +t-8ch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17997>
_______________________________________

From report at bugs.python.org  Tue Aug 27 21:48:19 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 27 Aug 2013 19:48:19 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377632899.15.0.63928429481.issue18850@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> The parser is *not* rejecting control chars.

The parser *is* rejecting control characters. It's an XML parser. See the example in the link you posted.


> assume you have a script that simply stores each message it receives (from stdin, from a tcp stream, whatever) inside an xml tree like 
> '<text>{message1}</text><text>{message2}<text>',
> and prints the tree on SIGINT.

That's not an XML specific issue. You are printing a byte string here, so repr() would be the right thing to use (and is actually being used automatically in Py3), instead of plain printing. The fact that you are wrapping the content in XML doesn't matter.


>> What part of the create-to-serialise process exactly is a problem here?
> ElementTree.tostring().

What I meant was: at what step of the process from creating an XML tree in memory to serialisation is it a problem that the tree contains control characters? Because once the data is serialised, it will just be rejected on input by any XML parser, and handling bytes data is a thing on its own (e.g. you could serialise to UTF16 and the result would contain null bytes - too bad).

It may just be a bad example that you chose here, but I really can't see this being a security problem. You are mishandling arbitrary untrusted binary data, that's all. Control characters are most likely not the only problem that you should guard against.

Unless there is a more dangerous way to exploit this that is actually due to XML being used, I'd suggest changing the type from "security" back to "behaviour".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Tue Aug 27 21:54:15 2013
From: report at bugs.python.org (Joshua Johnston)
Date: Tue, 27 Aug 2013 19:54:15 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
Message-ID: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>


New submission from Joshua Johnston:

This is strange behavior. When you encode nulls in other languages you don't get the string 'null' you usually get an empy string. Shouldn't str(None) == ''?

If not str(None) == 'None' and the string representation of a None value should not match a known string

>>> from urllib import urlencode
>>> urlencode({'josh': None})
'josh=None'

----------
components: Extension Modules
messages: 196314
nosy: Joshua.Johnston
priority: normal
severity: normal
status: open
title: urlencode of a None value uses the string 'None'
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Tue Aug 27 21:55:39 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 27 Aug 2013 19:55:39 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377633339.23.0.898286557846.issue18850@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Or maybe even to "enhancement". The behaviour that it writes out what you give it isn't exactly wrong, it's just inconvenient that you have to take care yourself that you pass it well-formed XML content.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Tue Aug 27 22:09:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Aug 2013 20:09:29 +0000
Subject: [issue18855] Inconsistent README filenames
In-Reply-To: <1377616570.1.0.108273179071.issue18855@psf.upfronthosting.co.za>
Message-ID: <1377634169.52.0.12617826552.issue18855@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

No reason really. We could standardize all of them on README.txt, perhaps.

----------
nosy: +pitrou
priority: normal -> low
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18855>
_______________________________________

From report at bugs.python.org  Tue Aug 27 22:18:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Aug 2013 20:18:05 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1377634685.65.0.72247575686.issue18857@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Tue Aug 27 22:42:52 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 27 Aug 2013 20:42:52 +0000
Subject: [issue18855] Inconsistent README filenames
In-Reply-To: <1377616570.1.0.108273179071.issue18855@psf.upfronthosting.co.za>
Message-ID: <1377636172.37.0.57987647947.issue18855@psf.upfronthosting.co.za>


Madison May added the comment:

It's obviously low priority, just thought I would mention it.  I found it a bit odd that "README" is used, though, since that means users will likely have to select the program they want to use to open the file (in Windows, at least).  

It might also be nice to follow the standard distutils idiom. From ?ric Araujo on issue11913, 

"In packaging/distutils2, the recommended idiom looks like this (in setup.cfg):

    [metadata]
    description-file = README.whatever"

In other words, README.txt would work nicely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18855>
_______________________________________

From report at bugs.python.org  Tue Aug 27 22:47:25 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Aug 2013 20:47:25 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1377636445.32.0.194672592681.issue18857@psf.upfronthosting.co.za>


R. David Murray added the comment:

In Python the str of a None value is indeed 'None', just as the str of a True value is 'True'.  Unless the protocol to which you are encoding supports null values, you shouldn't be using None values in the input to the serialization.  If you want an empty string in the output, use an empty string in the input.

Now, that said, it seems to me that while it is not (apparently) RFC compliant, query strings do have a natural way to support null values: a name without a value.  It would therefore be convenient if urlencode supported null values by turning something like {'josh': None, 'fred': 'abc'} into:

    josh&fred=abc

That is what I would expect it to do, so I'd be in favor of that enhancement.

I note that parse_qs and parse_qsl don't handle this case either, which surprises me since I think such value-less query string parameters are fairly common.

----------
nosy: +r.david.murray
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.4 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Tue Aug 27 23:00:54 2013
From: report at bugs.python.org (Joshua Johnston)
Date: Tue, 27 Aug 2013 21:00:54 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1377637254.18.0.973568918141.issue18857@psf.upfronthosting.co.za>


Joshua Johnston added the comment:

Hi David,

That is what I would expect it to do as well. I'm relatively new to Python but this is causing all kinds of problems with oauth signing using ims_lti_py as well as my own code using urlencode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Tue Aug 27 23:12:40 2013
From: report at bugs.python.org (pmoody)
Date: Tue, 27 Aug 2013 21:12:40 +0000
Subject: [issue17400] ipaddress should make it easy to identify rfc6598
 addresses
In-Reply-To: <1363052217.02.0.113831391012.issue17400@psf.upfronthosting.co.za>
Message-ID: <1377637960.33.0.865058107802.issue17400@psf.upfronthosting.co.za>


pmoody added the comment:

The problem is that 'shared' describes exactly one network, unless you mean that we should try to start 'private' as 'shared'. That's something I really don't want to do because it leads to confusion like this.

Do you not think that is_global or is_forwardable (per the iana registry) is worthwhile?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17400>
_______________________________________

From report at bugs.python.org  Tue Aug 27 23:27:23 2013
From: report at bugs.python.org (Jan Kaliszewski)
Date: Tue, 27 Aug 2013 21:27:23 +0000
Subject: [issue18858] dummy_threading lacks threading.get_ident() equivalent
Message-ID: <1377638843.21.0.0472654933915.issue18858@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski:

In Python 3.3 threading.get_ident() has been added as a public and documented function, but there is no dummy_threading.get_ident():

    >>> import threading, dummy_threading
    >>> threading.get_ident()
    139974728402752
    >>> dummy_threading.get_ident()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    AttributeError: 'module' object has no attribute 'get_ident'

By the way: it may be worth to check for other possible inconsistencies between avaliable interfaces of threading and dummy_threading.

----------
components: Library (Lib)
messages: 196321
nosy: zuo
priority: normal
severity: normal
status: open
title: dummy_threading lacks threading.get_ident() equivalent
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18858>
_______________________________________

From report at bugs.python.org  Wed Aug 28 00:06:21 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 27 Aug 2013 22:06:21 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1377613343.57.0.834334476055.issue17741@psf.upfronthosting.co.za>
Message-ID: <CADiSq7c_R5cdUneFDGW+SEt+Y7bJuum8E5C02nWSvtDgyyYPPg@mail.gmail.com>


Nick Coghlan added the comment:

Stefan, your proposed merged design isn't going to happen. Two alternative
ways of using the one class is far more complicated to explain to users
than exposing a helper that composes the existing API components to address
a particular use case (particularly when the helper is hiding the fact that
the theoretical underlying composition doesn't currently work the way it
should according to the public APIs).

As a higher level helper, users that are comfortable with and prefer the
lower level API are then clearly free to ignore. This recasting of the
nature of the API as a composition of the lower level components is a
*direct* response to your concern about it being a capability that the
lower level API should support directly.

You clearly don't like that design choice, but this isn't a democracy.
Arguing further on this point will just be ranting for the sake of ranting,
rather than having any chance of changing Eli's mind as module maintainer.

As far as naming goes, I still think it's better to drop "Parser" from the
name entirely. Call it "XMLEventReader" or something like that. The point
is to use it when you want to get the events out without blocking when no
events have been triggered and don't want to set up your own class to
receive event notifications through the target push API. The docs should
make it clear that this API is "pull only" - if people need callbacks or
other push triggers, then that's still what custom targets are for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Wed Aug 28 00:14:35 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 27 Aug 2013 22:14:35 +0000
Subject: [issue17400] ipaddress should make it easy to identify rfc6598
 addresses
In-Reply-To: <1377637960.33.0.865058107802.issue17400@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eKoGAEV2UMP5oQXNVXop9oc3taDhcjcVcQhooesQ55dw@mail.gmail.com>


Nick Coghlan added the comment:

I'd also be fine with "is_carrier_private", or, as you say, the inverse
"is_global" for "not is_private and not is_carrier_private and not (any of
the other private addresses)" (assuming I understood that suggestion
correctly).

I guess the "is_global" one is the most useful, since that lets you know if
you can send or store that address directly, or if you need to translate it
to a persistent global address somehow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17400>
_______________________________________

From report at bugs.python.org  Wed Aug 28 00:28:16 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Aug 2013 22:28:16 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1377642496.19.0.493409703577.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file31488/ca6217fbec85.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Wed Aug 28 00:28:34 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 27 Aug 2013 22:28:34 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <CADiSq7c_R5cdUneFDGW+SEt+Y7bJuum8E5C02nWSvtDgyyYPPg@mail.gmail.com>
Message-ID: <CADiSq7c9_irL06cFw14AdHEEf4n2qu-n-fdE_sHv+Emeu1jFzg@mail.gmail.com>


Nick Coghlan added the comment:

Sorry, Stefan, I missed your last comment before posting mine. It appears
you had already reached the same conclusion I had regarding further high
level design discussion being pointless :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Wed Aug 28 00:44:21 2013
From: report at bugs.python.org (Alex Volkov)
Date: Tue, 27 Aug 2013 22:44:21 +0000
Subject: [issue18731] Increased test coverage for uu and telnet
Message-ID: <1377643461.79.0.131386576227.issue18731@psf.upfronthosting.co.za>


New submission from Alex Volkov:

Okay,

I'm submitting the patch just for uu / test_uu.

I replaced all try/finally statemets with 'with' context, added try..finally statement for both test cases.

uu.py, line 61 is exposed by test_encode_osstat_assert -- os.stat is duckpunched out of the system, then test case verifies that default permissions(666) is written into a file.

I didn't have try...finally statement because I wasn't sure how the test case will behave when inner try..finally is triggered, so far the tests seem to pass..

----------
Added file: http://bugs.python.org/file31489/uu_test_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18731>
_______________________________________

From report at bugs.python.org  Wed Aug 28 01:10:58 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Tue, 27 Aug 2013 23:10:58 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377645058.27.0.254229685955.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

I took a crack from another angle. I converted my application using cython and then used gcc. Finally, ran valgrind over the binary. It is not finished yet but already spotted plenty of hints.

----------
Added file: http://bugs.python.org/file31490/python2.7_through_cython_valgrind.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Wed Aug 28 01:15:20 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 27 Aug 2013 23:15:20 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377645320.51.0.0963654486453.issue17741@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

W.r.t. the summary in http://bugs.python.org/msg196177, after some further chat with Nick, a name that sounds good for us for the class is XMLPullParser. It has both XML and Parser in it, so the intention is clear. On the other hand, Pull works well for analogy with the existing pull API in xml.dom.pulldom, *and* suggests that the push API is inactive and gets redirected to a pull API (thanks Nick for this insight). 

The method names remain as suggested there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Wed Aug 28 01:19:59 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Tue, 27 Aug 2013 23:19:59 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377645599.48.0.59991748021.issue18850@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Incidentally I read today http://blastedbio.blogspot.co.uk/2012/05/blast-tabular-missing-descriptions.html mentioning ^A being used. Maybe that would stop working?

----------
nosy: +mmokrejs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Wed Aug 28 01:20:54 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Aug 2013 23:20:54 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <3cPmKd6G23z7Lky@mail.python.org>


Roundup Robot added the comment:

New changeset ef889c3d5dc6 by Victor Stinner in branch 'default':
Issue #18571: Implementation of the PEP 446: file descriptors and file handles
http://hg.python.org/cpython/rev/ef889c3d5dc6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Wed Aug 28 01:21:15 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Aug 2013 23:21:15 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1377645675.0.0.377009650043.issue18571@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Wed Aug 28 01:23:11 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Aug 2013 23:23:11 +0000
Subject: [issue10115] Support accept4() for atomic setting of flags at socket
 creation
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1377645791.56.0.799774782773.issue10115@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Python 3.4 now uses accept4() internally for socket.socket.accept(), the new socket is created non-inheritable. See the PEP 446 for more information (PEP implemented in the issue #18571).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Wed Aug 28 01:23:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Aug 2013 23:23:20 +0000
Subject: [issue10115] Support accept4() for atomic setting of flags at socket
 creation
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1377645800.9.0.450567251384.issue10115@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Wed Aug 28 01:24:06 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Aug 2013 23:24:06 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>
Message-ID: <1377645846.7.0.840837036731.issue12107@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Sockets are now created non-inheritable in Python 3.4. See the PEP 446 for more information (PEP implemented in the issue #18571).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________

From report at bugs.python.org  Wed Aug 28 01:25:04 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Aug 2013 23:25:04 +0000
Subject: [issue16946] subprocess: _close_open_fd_range_safe() does not set
 close-on-exec flag on Linux < 2.6.23 if O_CLOEXEC is defined
In-Reply-To: <1358002453.56.0.227593845503.issue16946@psf.upfronthosting.co.za>
Message-ID: <1377645904.67.0.377024396634.issue16946@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue has been fixed in the implementation of the PEP 446 (issue #18571).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16946>
_______________________________________

From report at bugs.python.org  Wed Aug 28 01:25:53 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Aug 2013 23:25:53 +0000
Subject: [issue17070] PEP 433: Use the new cloexec to improve security and
 avoid bugs
In-Reply-To: <1359464957.74.0.458887600287.issue17070@psf.upfronthosting.co.za>
Message-ID: <1377645953.32.0.438486775788.issue17070@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The PEP 446 has been implemented (see issue #18571), this issue can be closed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17070>
_______________________________________

From report at bugs.python.org  Wed Aug 28 01:36:22 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 27 Aug 2013 23:36:22 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377646582.35.0.727508577747.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

Did you read Misc/README.valgrind (in the Python tree)?  The warnings you've seen so far are probably all nonsense, and README.valgrind explains how to avoid getting them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Wed Aug 28 01:50:16 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Tue, 27 Aug 2013 23:50:16 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377647416.39.0.374861768188.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

No, I did not know that. Thanks, I did now.

<quote>
  * Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c,
    then rebuild Python
  * Uncomment the lines in Misc/valgrind-python.supp that
    suppress the warnings for PyObject_Free and PyObject_Realloc

</quote>

Why isn't there a configure switch for this? :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Wed Aug 28 02:00:51 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 28 Aug 2013 00:00:51 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377648051.83.0.376161096754.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

I don't know why there isn't a configure switch for this - but then I've never used valgrind - LOL ;-)

Other developers use valgrind on Python routinely, though.  So it's unlikely you'll find a legitimate problem _in Python_ reported by valgrind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Wed Aug 28 02:07:00 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Wed, 28 Aug 2013 00:07:00 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377648420.38.0.118927757223.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

I was just checking whether configure picked up my --with-pymalloc and incidentally saw:

  --with-valgrind         Enable Valgrind support

maybe Misc/README.valgrind needs revision and should explain what that does as well? ;-)

It should also explain what is one supposed to do with Misc/valgrind-python.supp. It becomes clear once one goes to edit that file, true. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Wed Aug 28 02:19:49 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 28 Aug 2013 00:19:49 +0000
Subject: [issue18859] README.valgrind should mention --with-valgrind
Message-ID: <1377649189.0.0.381916551624.issue18859@psf.upfronthosting.co.za>


New submission from Tim Peters:

In issue 18843 a user noted that Misc/README.valgrind doesn't mention the --with-valgrind configure option.  It probably should.  But since I've never used valgrind, I'm not the guy to do it ;-)

----------
components: Build
messages: 196338
nosy: tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: README.valgrind should mention --with-valgrind
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18859>
_______________________________________

From report at bugs.python.org  Wed Aug 28 02:20:57 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 28 Aug 2013 00:20:57 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377649257.34.0.192694995762.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

I opened issue 18859 about the lack of --with-valgrind info in Misc/README.valgrind.  Thanks for noticing!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Wed Aug 28 02:43:49 2013
From: report at bugs.python.org (janzert)
Date: Wed, 28 Aug 2013 00:43:49 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1377650629.1.0.101268294306.issue18606@psf.upfronthosting.co.za>


janzert added the comment:

Seems that the discussion is now down to implementation issues and the PEP is at the point of needing to ask python-dev for a PEP dictator?

----------
nosy: +janzert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Wed Aug 28 02:56:27 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Wed, 28 Aug 2013 00:56:27 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1377650629.1.0.101268294306.issue18606@psf.upfronthosting.co.za>
Message-ID: <CAHVvXxR-Vo090ZMgPTiwSdXr-oNvY7+QOSK9Wyf02oZV=_Oz9g@mail.gmail.com>


Oscar Benjamin added the comment:

On Aug 28, 2013 1:43 AM, "janzert" <report at bugs.python.org> wrote:
>
> Seems that the discussion is now down to implementation issues and the
PEP is at the point of needing to ask python-dev for a PEP dictator?

I would say so. AFAICT Steven has addressed all of the issues that have
been raised. I've read through the module in full and I'm happy with the
API/specification exactly as it now is (including the sum function since
the last patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Wed Aug 28 03:28:31 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Aug 2013 01:28:31 +0000
Subject: [issue18860] Add content manager API to email package
Message-ID: <1377653310.93.0.882700028291.issue18860@psf.upfronthosting.co.za>


New submission from R. David Murray:

Here is a patch, layered on top of the patch in issue 18785, to add the content manager support.  This patch contains only the base ContentManager class, not the proposed functional registries.

----------
components: email
files: contentmanager.patch
keywords: patch
messages: 196342
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Add content manager API to email package
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31491/contentmanager.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18860>
_______________________________________

From report at bugs.python.org  Wed Aug 28 03:28:42 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Aug 2013 01:28:42 +0000
Subject: [issue18860] Add content manager API to email package
In-Reply-To: <1377653310.93.0.882700028291.issue18860@psf.upfronthosting.co.za>
Message-ID: <1377653322.05.0.344019859936.issue18860@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
dependencies: +Add get_body and iter_attachments to provisional email API

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18860>
_______________________________________

From report at bugs.python.org  Wed Aug 28 04:13:00 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 28 Aug 2013 02:13:00 +0000
Subject: [issue18780] SystemError when formatting int subclass
In-Reply-To: <1376921434.69.0.557024484243.issue18780@psf.upfronthosting.co.za>
Message-ID: <1377655980.04.0.816958633186.issue18780@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Okay, simple fix, patch and tests attached.

----------
keywords: +patch
nosy: +ncoghlan
stage:  -> patch review
Added file: http://bugs.python.org/file31492/issue18780.stoneleaf.01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18780>
_______________________________________

From report at bugs.python.org  Wed Aug 28 04:42:07 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 28 Aug 2013 02:42:07 +0000
Subject: [issue18861] Problems with recursive automatic exception chaining
Message-ID: <1377657727.9.0.627993776621.issue18861@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

Consider this:

$ python3 test_exc.py 
Traceback (most recent call last):
  File "test_exc.py", line 14, in <module>
    fail1()
  File "test_exc.py", line 11, in fail1
    fail2()
  File "test_exc.py", line 5, in fail2
    raise RuntimeError('Third') from None
RuntimeError: Third

$ cat test_exc.py 
def fail2():
    try:
        raise RuntimeError('Second')
    except RuntimeError:
        raise RuntimeError('Third') from None

def fail1():
    try:
        raise RuntimeError('First')
    except:
        fail2()
        raise

fail1()


Any exception raised in fail2() is the immediate consequence of the 'First' exception should thus be chained to the 'First' exception.

However, if somewhere in the call stack under fail2() an exception is caught and re-raised from None (to convert between exception types), this also results in a loss of the chain to the initial exception.


The correct stacktrace (in my opinion) would be:
Traceback (most recent call last):
  File "test_exc.py", line 9, in fail1
    raise RuntimeError('First')
RuntimeError: First

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test_exc.py", line 14, in <module>
    fail1()
  File "test_exc.py", line 11, in fail1
    fail2()
  File "test_exc.py", line 5, in fail2
    raise RuntimeError('Third')
RuntimeError: Third

----------
components: Interpreter Core
messages: 196344
nosy: Nikratio
priority: normal
severity: normal
status: open
title: Problems with recursive automatic exception chaining
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18861>
_______________________________________

From report at bugs.python.org  Wed Aug 28 04:43:24 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 28 Aug 2013 02:43:24 +0000
Subject: [issue18861] Problems with recursive automatic exception chaining
In-Reply-To: <1377657727.9.0.627993776621.issue18861@psf.upfronthosting.co.za>
Message-ID: <1377657804.55.0.286706138642.issue18861@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

The second paragraph should of course read "...consequence of the 'First' exception *and* should thus be chained..."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18861>
_______________________________________

From report at bugs.python.org  Wed Aug 28 05:10:36 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 28 Aug 2013 03:10:36 +0000
Subject: [issue18862] Implement __subclasshook__() for Finders and Loaders in
 importlib.abc
Message-ID: <1377659436.77.0.0929523139133.issue18862@psf.upfronthosting.co.za>


New submission from Eric Snow:

It would be helpful to have __subclasshook__() implemented on the finders and loaders in importlib.abc, following the approach taken by ABCs in collections.abc.  This came up relative to PEP 431, but would be generally useful (if only to a limited audience <wink>).

----------
components: Library (Lib)
keywords: easy
messages: 196346
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Implement __subclasshook__() for Finders and Loaders in importlib.abc
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18862>
_______________________________________

From report at bugs.python.org  Wed Aug 28 06:32:12 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 28 Aug 2013 04:32:12 +0000
Subject: [issue18859] README.valgrind should mention --with-valgrind
In-Reply-To: <1377649189.0.0.381916551624.issue18859@psf.upfronthosting.co.za>
Message-ID: <1377664332.43.0.00891152170895.issue18859@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18859>
_______________________________________

From report at bugs.python.org  Wed Aug 28 06:39:49 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 28 Aug 2013 04:39:49 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377664789.05.0.753831901614.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> the push API is inactive and gets redirected to a pull API

Given that this is aimed to become a redundant 'convenience' wrapper around something else at a point, I assume that you are aware that the above is just an arbitrary restriction due to the fact that the parser does not accept arbitrary targets as input.

Also, the refrence to pulldom is a bad one, because pulldom reads data as you request it ("pull"). This class creates events based on the data you *push* into it. So it's really a push API from the POV of the user, not so much a pull API.

Anyway, it should be possible to emulate both this class and the pie-in-the-sky three-level API based on what I suggested, so I can't see this addition being a problem. I may even end up making the same visual split in lxml.etree deliberately, in order to make it clear that this feature only applies to the push parser API, i.e. when using feed() and close(), as opposed to what parse() and fromstring() use. That would mean that there'd also be a corresponding class for the HTMLParser then, and both would inherit from the base parsers and thus obviously (and conveniently) accept arbitrary parser targets.

I think I'm ok with adding that class. I liked Greg Ewing's suggestion of calling it AsyncParser, though, i.e. AsyncXMLParser. It makes it obvious what the use case is and avoids any references to push or pull that will always confuse some users, based on what part of the feature they are focussing on in their code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Wed Aug 28 07:25:47 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 28 Aug 2013 05:25:47 +0000
Subject: [issue18836] Potential race condition in exceptions
In-Reply-To: <1377497509.71.0.034362539056.issue18836@psf.upfronthosting.co.za>
Message-ID: <1377667547.13.0.911675019255.issue18836@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

> If it is intended not to be able to catch all exceptions
> and prevent a traceback being showed this should be indeed a PEP.

You may want to have a look at sys.excepthook.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18836>
_______________________________________

From report at bugs.python.org  Wed Aug 28 07:44:04 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 28 Aug 2013 05:44:04 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <1377668644.58.0.202306021653.issue18571@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

14.1 --- a/Lib/multiprocessing/util.py
    14.2 +++ b/Lib/multiprocessing/util.py

   14.13  #
   14.14  # Return pipe with CLOEXEC set on fds
   14.15  #
   14.16 +# Deprecated: os.pipe() creates non-inheritable file descriptors
   14.17 +# since Python 3.4
   14.18 +#
   14.19  
   14.20  def pipe():
   14.21 -    import _posixsubprocess
   14.22 -    return _posixsubprocess.cloexec_pipe()
   14.23 +    return os.pipe()

I guess you could remove util.pipe() altogether: it wasn't part of the public API.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Wed Aug 28 08:14:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 06:14:42 +0000
Subject: [issue18859] README.valgrind should mention --with-valgrind
In-Reply-To: <1377649189.0.0.381916551624.issue18859@psf.upfronthosting.co.za>
Message-ID: <1377670482.82.0.674426675019.issue18859@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18859>
_______________________________________

From report at bugs.python.org  Wed Aug 28 08:28:31 2013
From: report at bugs.python.org (G. Scott Johnston)
Date: Wed, 28 Aug 2013 06:28:31 +0000
Subject: [issue18863] Encoding a unicode with unicode() and ignoring errors
Message-ID: <1377671311.74.0.613410259035.issue18863@psf.upfronthosting.co.za>


New submission from G. Scott Johnston:

I've come up with the following series of minimal examples to demonstrate my bug. 


>>> unicode("")
u''
>>> unicode("", errors="ignore")
u''


>>> unicode("abc?")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3: ordinal not in range(128)
>>> unicode("abc?", errors="ignore")
u'abc'


>>> unicode(3)
u'3'
>>> unicode(3, errors="ignore")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: coercing to Unicode: need string or buffer, int found


>>> unicode(unicode(""))
u''
>>> unicode(unicode(""), errors="ignore")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: decoding Unicode is not supported


The first two pairs of mini-programs are reasonable behaviour.  If the errors parameter is set to "ignore", no additional errors are thrown, but characters that produce encoding errors are skipped in the output, as expected.  

The third pair of mini-programs can be solved by instead writing unicode(str(3), errors="ignore").  This should likely be done automatically, given the fact that unicode(3) behaves as expected, and properly converts between types.  The fact that the conversion is done automatically without the errors parameter leads me to believe that there is a logic problem with the code, where the setting errors="ignore" changes the path of execution by more than just skipping characters that cause encoding errors.

The fourth pair of mini-programs is simply baffling.  The first mini-program clearly demonstrates that decoding a Unicode object is in fact supported.  The fact that the second mini-program claims it's not supported further demonstrates that the logic depends on the errors="ignore" parameter more than it should.

----------
messages: 196350
nosy: G..Scott.Johnston
priority: normal
severity: normal
status: open
title: Encoding a unicode with unicode() and ignoring errors
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18863>
_______________________________________

From report at bugs.python.org  Wed Aug 28 08:45:08 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 28 Aug 2013 06:45:08 +0000
Subject: [issue18863] Encoding a unicode with unicode() and ignoring errors
In-Reply-To: <1377671311.74.0.613410259035.issue18863@psf.upfronthosting.co.za>
Message-ID: <1377672308.84.0.110957126715.issue18863@psf.upfronthosting.co.za>


Ned Deily added the comment:

See http://docs.python.org/2/library/functions.html#unicode.  It appears to me that unicode() is behaving exactly as documented. In particular:

"If encoding and/or errors are given, unicode() will decode the object which can either be an 8-bit string or a character buffer using the codec for encoding."

"If no optional parameters are given, unicode() will mimic the behaviour of str() except that it returns Unicode strings instead of 8-bit strings. More precisely, if object is a Unicode string or subclass it will return that Unicode string without any additional decoding applied."

One can argue about whether this documented behavior makes the most sense but, since it is documented to behave that way and that any significant changes to that behavior at this late stage of the life of Python 2 could break existing programs, I think there will be little support for making such a change now.  Sorry!

----------
nosy: +ned.deily
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18863>
_______________________________________

From report at bugs.python.org  Wed Aug 28 08:56:18 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 28 Aug 2013 06:56:18 +0000
Subject: [issue18864] Implementation for PEP 451
 (importlib.machinery.ModuleSpec)
Message-ID: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za>


New submission from Eric Snow:

This ticket will track the implementation for PEP 451 (ModuleSpec).  I'll have a patch up in the next couple days.

----------
assignee: eric.snow
components: Interpreter Core, Library (Lib)
messages: 196352
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Implementation for PEP 451 (importlib.machinery.ModuleSpec)
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18864>
_______________________________________

From report at bugs.python.org  Wed Aug 28 09:15:10 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 28 Aug 2013 07:15:10 +0000
Subject: [issue18745] Test enum in test_json is ignorant of infinity value
In-Reply-To: <1376553540.47.0.197538167938.issue18745@psf.upfronthosting.co.za>
Message-ID: <1377674110.11.0.856291584413.issue18745@psf.upfronthosting.co.za>


Ethan Furman added the comment:

The added tests for inf, -inf, and nan are good.

The refactoring of the dictionary tests are not good.  The reason is that before _json.c was fixed (issue18264) it would return the string value of an IntEnum instead of the string value of the IntEnum member's value attribute.

--> class Number(IntEnum):
...    one = 1
...    two = 2

--> json.dumps(Number.one)
'Number.one'  # should be '1'

As a constant we get a failure when trying to round-trip:

--> json.loads(json.dumps(Number.one))
Traceback (most recent call last):
  ...
ValueError: Expecting value: line 1 column 1 (char 0)

But as a dictionary we do not (because keys get morphed into strings):

--> json.dumps({Number.one: 'one'})
'{"Number.one": "one"}'  # should be '{"1": "one"}'

Which round-trips fine, but yields the wrong result:

>>> loads(dumps({Number.one: 'one'}))
{'Number.one': 'one'}  # should be {'1': 'one'}

So the dictionary tests (and the list tests) are there to make sure that json.dumps is converting them properly, not to make sure that they round-trip, and by changing from repr to loads/dumps the point of the test is lost.

Updated tests attached.

----------
Added file: http://bugs.python.org/file31493/issue18745.stoneleaf.01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18745>
_______________________________________

From report at bugs.python.org  Wed Aug 28 09:35:42 2013
From: report at bugs.python.org (Jeong-Min Lee)
Date: Wed, 28 Aug 2013 07:35:42 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377675342.88.0.34620131134.issue18851@psf.upfronthosting.co.za>


Changes by Jeong-Min Lee <falsetru at gmail.com>:


----------
nosy: +Jeong-Min.Lee

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Wed Aug 28 09:36:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Aug 2013 07:36:45 +0000
Subject: [issue18865] multiprocessing: remove util.pipe()?
Message-ID: <1377675405.74.0.563721263875.issue18865@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In the implementation of the PEP 446, issue #18571, I replaced multiprocessing.util.pipe() with os.pipe() in the multiprocessing module.

Can we remove the multiprocessing.util.pipe() function? It is not public nor documented.

Charles-Fran?ois Natali added the comment (in issue #18571):

   14.1 --- a/Lib/multiprocessing/util.py
   14.2 +++ b/Lib/multiprocessing/util.py

   14.13  #
   14.14  # Return pipe with CLOEXEC set on fds
   14.15  #
   14.16 +# Deprecated: os.pipe() creates non-inheritable file descriptors
   14.17 +# since Python 3.4
   14.18 +#
   14.19
   14.20  def pipe():
   14.21 -    import _posixsubprocess
   14.22 -    return _posixsubprocess.cloexec_pipe()
   14.23 +    return os.pipe()

I guess you could remove util.pipe() altogether: it wasn't part of the public API.

----------
messages: 196354
nosy: haypo, neologix, sbt
priority: normal
severity: normal
status: open
title: multiprocessing: remove util.pipe()?
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18865>
_______________________________________

From report at bugs.python.org  Wed Aug 28 09:37:39 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Aug 2013 07:37:39 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1377668644.58.0.202306021653.issue18571@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZa0+yBMuviZ2LJQxsW0NxpyjX=vdx7D3WziiyjfxO6Hw@mail.gmail.com>


STINNER Victor added the comment:

> I guess you could remove util.pipe() altogether: it wasn't part of the public API.

Ah yes, I wanted to create an issue for that but I forgot. Here you
have: issue #18865.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18571>
_______________________________________

From report at bugs.python.org  Wed Aug 28 09:55:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 07:55:25 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1377676525.97.0.413989138692.issue18849@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> needs patch
versions: +Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18849>
_______________________________________

From report at bugs.python.org  Wed Aug 28 09:58:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 07:58:16 +0000
Subject: [issue18861] Problems with recursive automatic exception chaining
In-Reply-To: <1377657727.9.0.627993776621.issue18861@psf.upfronthosting.co.za>
Message-ID: <1377676696.24.0.434916737427.issue18861@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18861>
_______________________________________

From report at bugs.python.org  Wed Aug 28 10:17:17 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 28 Aug 2013 08:17:17 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1377677837.69.0.245951420255.issue18738@psf.upfronthosting.co.za>


Ethan Furman added the comment:

On 08/14/2013 09:27 PM, on PyDev, Nick Coghlan wrote:
> For enums, I believe they should be formatted like their
> base types (so !s and !r will show the enum name, anything without
> coercion will show the value).

I agree.  While one of the big reasons for an Enum type was the pretty str and repr, I don't see format in that area.


So, these are some of the ways we have to display an object:

str()       calls obj.__str__()
repr()      calls obj.__repr__()

"%s"        calls obj.__str__()
"%r"        calls obj.__repr__()
"%d"        calls... not sure, but we see the int value

"{}".format()  should (IMO) also display the value of the object

Using int as the case study, its presentation types are ['b', 'd', 'n', 'o', 'x', 'X'].  Notice there is no 's' nor 'r' in there, as int expects to display a number, not arbitrary text.

So, for mixed-type Enumerations, I think any format calls should simply be forwarded to the mixed-in type (unless, of course, a custom __format__ was specified in the new Enumeration).

Patch attached.

----------
nosy: +ncoghlan
Added file: http://bugs.python.org/file31494/issue18738.stoneleaf.03.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Wed Aug 28 10:33:30 2013
From: report at bugs.python.org (Mathieu Dutour Sikiric)
Date: Wed, 28 Aug 2013 08:33:30 +0000
Subject: [issue18866] Invitation to connect on LinkedIn
Message-ID: <123334601.8021512.1377678808806.JavaMail.app@ela4-app0134.prod>


New submission from Mathieu Dutour Sikiric:

LinkedIn
------------

Python,

I'd like to add you to my professional network on LinkedIn.

- Mathieu

Mathieu Dutour Sikiric
visitor at Technische Universit?t Darmstadt
Croatia

Confirm that you know Mathieu Dutour Sikiric:
https://www.linkedin.com/e/-3qcne3-hkwae47b-w/isd/16114407170/_uBqO9cI/?hs=false&tok=1LB6yqjv-xn5U1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hkwae47b-w/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I5360506395_1/?hs=false&tok=2-0L5OcgWxn5U1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

----------
messages: 196357
nosy: mathieu37
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18866>
_______________________________________

From report at bugs.python.org  Wed Aug 28 10:36:46 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Aug 2013 08:36:46 +0000
Subject: [issue18866] Invitation to connect on LinkedIn
Message-ID: <1377679006.15.0.410256019967.issue18866@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
Removed message: http://bugs.python.org/msg196357

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18866>
_______________________________________

From report at bugs.python.org  Wed Aug 28 10:36:59 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Aug 2013 08:36:59 +0000
Subject: [issue18866] spam
Message-ID: <1377679019.88.0.993641307919.issue18866@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
title: Invitation to connect on LinkedIn -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18866>
_______________________________________

From report at bugs.python.org  Wed Aug 28 10:40:00 2013
From: report at bugs.python.org (Mathieu Dutour Sikiric)
Date: Wed, 28 Aug 2013 08:40:00 +0000
Subject: [issue18867] Invitation to connect on LinkedIn
Message-ID: <1370453702.8006392.1377679198049.JavaMail.app@ela4-app1201.prod>


New submission from Mathieu Dutour Sikiric:

LinkedIn
------------

Python,

I'd like to add you to my professional network on LinkedIn.

- Mathieu

Mathieu Dutour Sikiric
visitor at Technische Universit?t Darmstadt
Croatia

Confirm that you know Mathieu Dutour Sikiric:
https://www.linkedin.com/e/-3qcne3-hkwamgk2-6i/isd/16114407170/_uBqO9cI/?hs=false&tok=2qk9t5ByeDn5U1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hkwamgk2-6i/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I5360539519_1/?hs=false&tok=0MVwAfDXCDn5U1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

----------
messages: 196358
nosy: mathieu37
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18867>
_______________________________________

From report at bugs.python.org  Wed Aug 28 10:43:50 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Aug 2013 08:43:50 +0000
Subject: [issue18867] Invitation to connect on LinkedIn
Message-ID: <1377679430.61.0.242918070791.issue18867@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
Removed message: http://bugs.python.org/msg196358

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18867>
_______________________________________

From report at bugs.python.org  Wed Aug 28 10:44:01 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Aug 2013 08:44:01 +0000
Subject: [issue18867] spam
Message-ID: <1377679441.71.0.79165664744.issue18867@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
title: Invitation to connect on LinkedIn -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18867>
_______________________________________

From report at bugs.python.org  Wed Aug 28 11:19:24 2013
From: report at bugs.python.org (Joe Borg)
Date: Wed, 28 Aug 2013 09:19:24 +0000
Subject: [issue18868] Python3 unbuffered stdin
Message-ID: <1377681564.92.0.926371389199.issue18868@psf.upfronthosting.co.za>


New submission from Joe Borg:

I'm in need of an unbuffered stdin for Python3.  Using the '-u' flag worked fine in Python2.  But, it seems, Python3's stdin is always buffered; as seen in http://bugs.python.org/issue4705.

This is not always desirable.  For example:

#!/bin/python3
import os, subprocess, time

with open("%s/unbuffered_test.log" % (os.getenv("HOME")), "w") as f:
    with subprocess.Popen(["%s/unbuffered_test.sh" % (os.getenv("HOME"))], stdin=subprocess.PIPE, stdout=f, stderr=f) as p:
        p.stdin.write(bytes("test\n", encoding="utf-8"))
        time.sleep(10)

Where unbuffered_test.sh is:
#!/bin/sh
read INPUT
echo $INPUT
exit 0

Running with -u in Python2 sees the log file populated before the 10 seconds are up.  This isn't the case in Python3.  This making controlling applications, using subprocess, basically impossible; without putting p.stdin.flush() after each command (which does work in the example above).

I ran this example in Python3.3.2.

----------
messages: 196359
nosy: Joe.Borg
priority: normal
severity: normal
status: open
title: Python3 unbuffered stdin
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18868>
_______________________________________

From report at bugs.python.org  Wed Aug 28 11:19:38 2013
From: report at bugs.python.org (Joe Borg)
Date: Wed, 28 Aug 2013 09:19:38 +0000
Subject: [issue18868] Python3 unbuffered stdin
In-Reply-To: <1377681564.92.0.926371389199.issue18868@psf.upfronthosting.co.za>
Message-ID: <1377681578.67.0.415801525786.issue18868@psf.upfronthosting.co.za>


Changes by Joe Borg <cyborg101010 at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18868>
_______________________________________

From report at bugs.python.org  Wed Aug 28 11:21:57 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Wed, 28 Aug 2013 09:21:57 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377681717.28.0.0738472057978.issue18850@psf.upfronthosting.co.za>


Michele Orr? added the comment:

> The parser *is* rejecting control characters. It's an XML parser. See the example in the link you posted.
Ehrm, my apologies.

> That's not an XML specific issue. You are printing a byte string here, so repr() would be the right thing to use (and is actually being used automatically in 
> Py3), instead of plain printing. The fact that you are wrapping the content in XML doesn't matter.
[citation needed] 
After a quick scan in the documentation I did not see anything mentioning this. Instead, I see many cases in which escape chars and binary-to-text encodings are mentioned.

> What I meant was: at what step of the process from creating an XML tree in memory to serialisation is it a problem that the tree contains control characters? 
> Because once the data is serialised, it will just be rejected on input by any XML parser, and handling bytes data is a thing on its own (e.g. you could serialise 
> to UTF16 and the result would contain null bytes - too bad).
m, I think the problem lies in the expectation of having fromstring(tostring(tree)) = tree

> Unless there is a more dangerous way to exploit this that is actually due to XML being used, I'd suggest changing the type from "security" back to "behaviour".
> Or maybe even to "enhancement". The behaviour that it writes out what you give it isn't exactly wrong, it's just inconvenient that you have to take care yourself 
> that you pass it well-formed XML content.
I think the point here is clarifying whether xml expect text or just a byte string. In case that's a stream of byte, I agree with you, is more a "behaviour" problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Wed Aug 28 11:32:39 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 28 Aug 2013 09:32:39 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377682359.14.0.723612148936.issue18850@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> I think the point here is clarifying whether xml expect text or just a byte string. In case that's a stream of byte, I agree with you, is more a "behaviour" problem.

XML is *defined* as a stream of bytes.

Regarding the API side in ElementTree, Py2 accepts byte strings and Py3 requires Unicode strings. Py2 will not change in that regard, and I can't see this being a serious enough issue to change the ET-API there, so IMHO we can ignore Py2.x completely for this issue. (changing ticket accordingly)

However, Py3 will happily write out control characters if they appear in the Unicode text string, so the issue is the same there. A fix for Py3 would be to add an input validation step, preferably at serialisation time.

----------
type: security -> enhancement
versions:  -Python 2.6, Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Wed Aug 28 11:37:27 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Wed, 28 Aug 2013 09:37:27 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377682647.83.0.158936797282.issue18850@psf.upfronthosting.co.za>


Michele Orr? added the comment:

> Incidentally I read today http://blastedbio.blogspot.co.uk/2012/05/blast-tabular-missing-descriptions.html mentioning ^A being used. 
> Maybe that would stop working?
I don't see any problem in any xml output. Indeed:
"You can't put a nasty non-printing ASCII character in XML, so they were switched to something else. That is my working theory for this anyway."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Wed Aug 28 11:42:07 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 28 Aug 2013 09:42:07 +0000
Subject: [issue18865] multiprocessing: remove util.pipe()?
In-Reply-To: <1377675405.74.0.563721263875.issue18865@psf.upfronthosting.co.za>
Message-ID: <1377682927.48.0.725010013605.issue18865@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

Yes I will remove it.  I was planning on doing so when PEP 446 was implemented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18865>
_______________________________________

From report at bugs.python.org  Wed Aug 28 11:45:06 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Wed, 28 Aug 2013 09:45:06 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377683106.4.0.362919328318.issue18850@psf.upfronthosting.co.za>


Michele Orr? added the comment:

> XML is *defined* as a stream of bytes.
Can you *paste* the *source* proving what you are arguing, please?  

> Regarding the API side in ElementTree, Py2 accepts byte strings and Py3 requires Unicode strings.
"accepts"? python3 works with ElementTree(bytes(unicode))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Wed Aug 28 11:48:10 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 28 Aug 2013 09:48:10 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377683290.4.0.0737237729061.issue18850@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

>> XML is *defined* as a stream of bytes.
> Can you *paste* the *source* proving what you are arguing, please?

http://www.w3.org/TR/REC-xml/


> python3 works with ElementTree(bytes(unicode))

What does this sentence mean?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Wed Aug 28 12:01:36 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Wed, 28 Aug 2013 10:01:36 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377684096.9.0.244824864493.issue18850@psf.upfronthosting.co.za>


Michele Orr? added the comment:

>>> XML is *defined* as a stream of bytes.
>> Can you *paste* the *source* proving what you are arguing, please?
> http://www.w3.org/TR/REC-xml/
"""
The first two suggestions are directly derived from the rules given for identifiers in Standard Annex #31 (UAX #31) of the Unicode Standard, version 5.0 [Unicode], and exclude all control characters, enclosing nonspacing marks, non-decimal numbers, private-use characters, punctuation characters (with the noted exceptions), symbol characters, unassigned codepoints, and white space characters. The other suggestions are mostly derived from Appendix B in previous editions of this specification.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Wed Aug 28 12:05:46 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Wed, 28 Aug 2013 10:05:46 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377684346.42.0.50426257014.issue18850@psf.upfronthosting.co.za>


Michele Orr? added the comment:

"""
Document authors are encouraged to avoid "compatibility characters", as defined in section 2.3 of [Unicode]. The characters defined in the following ranges are also discouraged. They are either control characters or permanently undefined Unicode characters:
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Wed Aug 28 12:08:25 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Wed, 28 Aug 2013 10:08:25 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377684505.61.0.935354237585.issue18850@psf.upfronthosting.co.za>


Michele Orr? added the comment:

Does not seem to me just a "byte string" where you can put binary data. 
Hence, I expect the xml tree to escape/reject those. 
Hence, Is not an enhancement, but a bug. Unless we just want to document this.

(not going to change the metadata, otherwise we'll end up changing on each message).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Wed Aug 28 12:26:03 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 28 Aug 2013 10:26:03 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377685563.46.0.415007843465.issue18850@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

We are talking about two different things here.

I said that (serialised) XML is defined as a sequence of bytes. Read the spec on that.

What you are talking about is the Infoset, or the parsed/generated in-memory XML tree. That's obviously not bytes, it's defined based on Unicode. Parsing and serialising does the mapping here.

The "attack" that you presented is based on serialised XML, thus on a sequence of bytes. What I am saying is that this "attack" can be done by any kind of binary data, so it's not XML specific, thus not a problem with ElementTree.

The fact that ElementTree allows you to generate non well-formed 'XML' containing control characters when you tell it to do so is unfortunate, but it's neither a security risk (you already had the non well-formed content in your hands *before* you passed it into ElementTree), nor clearly a bug, because the user specifically requested the serialisation of an in-memory tree that contained these control characters.

But, once again, it would be nice if ElementTree rejected this input in one way or another, and that's a feature request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Wed Aug 28 12:27:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Aug 2013 10:27:32 +0000
Subject: [issue18865] multiprocessing: remove util.pipe()?
In-Reply-To: <1377675405.74.0.563721263875.issue18865@psf.upfronthosting.co.za>
Message-ID: <3cQ36q6435zPXP@mail.python.org>


Roundup Robot added the comment:

New changeset 38f028939028 by Richard Oudkerk in branch 'default':
Issue #18865: PEP 446 makes multiprocessing.util.pipe() unnecessary.
http://hg.python.org/cpython/rev/38f028939028

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18865>
_______________________________________

From report at bugs.python.org  Wed Aug 28 12:32:48 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Aug 2013 10:32:48 +0000
Subject: [issue18855] Inconsistent README filenames
In-Reply-To: <1377616570.1.0.108273179071.issue18855@psf.upfronthosting.co.za>
Message-ID: <1377685968.11.0.316525876156.issue18855@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eric.araujo, ezio.melotti, tim.peters
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18855>
_______________________________________

From report at bugs.python.org  Wed Aug 28 12:33:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Aug 2013 10:33:53 +0000
Subject: [issue16799] start using argparse.Namespace in regrtest
In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za>
Message-ID: <1377686033.29.0.374207294092.issue16799@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is updated patch with tests.

Please open separated issues if you want suggest semantic changes (removing, renaming or changing behavior of some options).

----------
Added file: http://bugs.python.org/file31495/regrtest_argparse_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16799>
_______________________________________

From report at bugs.python.org  Wed Aug 28 12:44:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Aug 2013 10:44:42 +0000
Subject: [issue18865] multiprocessing: remove util.pipe()?
In-Reply-To: <1377675405.74.0.563721263875.issue18865@psf.upfronthosting.co.za>
Message-ID: <3cQ3Vd5fw8z7Lkd@mail.python.org>


Roundup Robot added the comment:

New changeset 3e397ecedc55 by Victor Stinner in branch 'default':
Issue #18865: remove unused import from multiprocessing.util.spawnv_passfds()
http://hg.python.org/cpython/rev/3e397ecedc55

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18865>
_______________________________________

From report at bugs.python.org  Wed Aug 28 12:54:18 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Wed, 28 Aug 2013 10:54:18 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377687258.55.0.640594810591.issue18850@psf.upfronthosting.co.za>


Michele Orr? added the comment:

>I said that (serialised) XML is defined as a sequence of bytes. 
> Read the spec on that.
And I'm saying that's inexact. I have expectations that control chars are escaped in the serialized xml, because the spec I'm reading says so, and because the documentation does not warn me about this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Wed Aug 28 13:01:05 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 28 Aug 2013 11:01:05 +0000
Subject: [issue18786] test_multiprocessing_spawn crashes under PowerLinux
In-Reply-To: <1376948017.66.0.62278437821.issue18786@psf.upfronthosting.co.za>
Message-ID: <1377687665.25.0.997642461296.issue18786@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

The PPC64 buildbot is still failing intermittently.

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18786>
_______________________________________

From report at bugs.python.org  Wed Aug 28 13:04:42 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 28 Aug 2013 11:04:42 +0000
Subject: [issue18865] multiprocessing: remove util.pipe()?
In-Reply-To: <1377675405.74.0.563721263875.issue18865@psf.upfronthosting.co.za>
Message-ID: <1377687882.68.0.732762819445.issue18865@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18865>
_______________________________________

From report at bugs.python.org  Wed Aug 28 13:38:46 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 28 Aug 2013 11:38:46 +0000
Subject: [issue18786] test_multiprocessing_spawn crashes under PowerLinux
In-Reply-To: <1376948017.66.0.62278437821.issue18786@psf.upfronthosting.co.za>
Message-ID: <1377689926.51.0.258906597973.issue18786@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

It looks like the main process keeps getting killed by SIGUSR1.  Don't know why.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18786>
_______________________________________

From report at bugs.python.org  Wed Aug 28 13:42:42 2013
From: report at bugs.python.org (Sworddragon)
Date: Wed, 28 Aug 2013 11:42:42 +0000
Subject: [issue18836] Potential race condition in exceptions
In-Reply-To: <1377497509.71.0.034362539056.issue18836@psf.upfronthosting.co.za>
Message-ID: <1377690162.91.0.981696255512.issue18836@psf.upfronthosting.co.za>


Sworddragon added the comment:

> You may want to have a look at sys.excepthook.

This would not solve the race condition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18836>
_______________________________________

From report at bugs.python.org  Wed Aug 28 13:54:58 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 28 Aug 2013 11:54:58 +0000
Subject: [issue18786] test_multiprocessing_spawn crashes under PowerLinux
In-Reply-To: <1376948017.66.0.62278437821.issue18786@psf.upfronthosting.co.za>
Message-ID: <1377690898.24.0.25076288076.issue18786@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

> It looks like the main process keeps getting killed by SIGUSR1.
> Don't know why.

In Lib/test/_test_multiprocessing.py:
"""
    def test_poll_eintr(self):
        got_signal = [False]
        def record(*args):
            got_signal[0] = True
        pid = os.getpid()
        oldhandler = signal.signal(signal.SIGUSR1, record)
        try:
            killer = self.Process(target=self._killer, args=(pid,))
            killer.start()
            p = self.Process(target=time.sleep, args=(1,))
            p.start()
            p.join()
            self.assertTrue(got_signal[0])
            self.assertEqual(p.exitcode, 0)
            killer.join()
        finally:
            signal.signal(signal.SIGUSR1, oldhandler)
"""

If the _killer process takes too long to start, it won't send SIGUSR1 before the p process returns (0.5s vs 1s): which means that the default SIGUSR1 handler will be restored before SIGUSR1 is sent. Then SIGUSR1 comes in, resulting on the failure above.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18786>
_______________________________________

From report at bugs.python.org  Wed Aug 28 14:02:24 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Aug 2013 12:02:24 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1377691344.61.0.330532078193.issue7897@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Since we now got subtests, can this be closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed Aug 28 14:56:08 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Wed, 28 Aug 2013 12:56:08 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377694568.82.0.135382613934.issue18850@psf.upfronthosting.co.za>


Michele Orr? added the comment:

Just pointed by a friend - <http://www.w3.org/TR/REC-xml/#sec-cdata-sect>
I suppose this is insanely used to put binary blobs inside xml until "only the CDEnd string is recognized as markup".
That's what I needed. 

Amen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Wed Aug 28 14:57:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Aug 2013 12:57:29 +0000
Subject: [issue18786] test_multiprocessing_spawn crashes under PowerLinux
In-Reply-To: <1376948017.66.0.62278437821.issue18786@psf.upfronthosting.co.za>
Message-ID: <3cQ6Rr3rDcz7Ljg@mail.python.org>


Roundup Robot added the comment:

New changeset fa23e49c7dd3 by Richard Oudkerk in branch 'default':
Issue #18786: Don't reinstall old SIGUSR1 handler prematurely.
http://hg.python.org/cpython/rev/fa23e49c7dd3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18786>
_______________________________________

From report at bugs.python.org  Wed Aug 28 14:58:29 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 28 Aug 2013 12:58:29 +0000
Subject: [issue18786] test_multiprocessing_spawn crashes under PowerLinux
In-Reply-To: <1376948017.66.0.62278437821.issue18786@psf.upfronthosting.co.za>
Message-ID: <1377694709.8.0.956723027646.issue18786@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> If the _killer process takes too long to start, it won't send SIGUSR1 
> before the p process returns...

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18786>
_______________________________________

From report at bugs.python.org  Wed Aug 28 15:15:14 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Aug 2013 13:15:14 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1377695714.01.0.0919932323295.issue7897@psf.upfronthosting.co.za>


R. David Murray added the comment:

subtests don't satisfy my use cases.  You can't run an individual subtest by name, and I find that to be a very important thing to be able to do during development and debugging.  At the moment at least I'm fine with just having my parameterize decorator in the email module, so I'm not motivated to move this forward right now.  I would like to come back to it eventually, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed Aug 28 15:54:38 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 28 Aug 2013 13:54:38 +0000
Subject: [issue18786] test_multiprocessing_spawn crashes under PowerLinux
In-Reply-To: <1377694709.8.0.956723027646.issue18786@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0A4KRgm5ppEA3H8qD=Kr_8adbUQVn6r+zMA=PZ2ehseg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Thanks!

You're welcome :)

BTW, I don't know if that would fulfill the goal of your test here,
but when I want to check for EINTR handling, I just use alarm (see
attached patch). The only downside is that the minimum delay is 1
second.

----------
keywords: +patch
Added file: http://bugs.python.org/file31496/eintr_alarm.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18786>
_______________________________________
-------------- next part --------------
--- cpython-df2fdd42b375/Lib/test/_test_multiprocessing.py	2013-08-26 20:28:21.000000000 +0000
+++ cpython/Lib/test/_test_multiprocessing.py	2013-08-28 13:51:02.000000000 +0000
@@ -2923,29 +2923,21 @@
 
     ALLOWED_TYPES = ('processes',)
 
-    @classmethod
-    def _killer(cls, pid):
-        time.sleep(0.5)
-        os.kill(pid, signal.SIGUSR1)
-
-    @unittest.skipUnless(hasattr(signal, 'SIGUSR1'), 'requires SIGUSR1')
+    @unittest.skipUnless(hasattr(signal, 'alarm'), 'requires signal.alarm')
     def test_poll_eintr(self):
         got_signal = [False]
         def record(*args):
             got_signal[0] = True
         pid = os.getpid()
-        oldhandler = signal.signal(signal.SIGUSR1, record)
-        try:
-            killer = self.Process(target=self._killer, args=(pid,))
-            killer.start()
-            p = self.Process(target=time.sleep, args=(1,))
-            p.start()
-            p.join()
-            self.assertTrue(got_signal[0])
-            self.assertEqual(p.exitcode, 0)
-            killer.join()
-        finally:
-            signal.signal(signal.SIGUSR1, oldhandler)
+        oldhandler = signal.signal(signal.SIGALRM, record)
+        self.addCleanup(signal.signal, signal.SIGALRM, oldhandler)
+        self.addCleanup(signal.alarm, 0)
+        signal.alarm(1)
+        p = self.Process(target=time.sleep, args=(2,))
+        p.start()
+        p.join()
+        self.assertTrue(got_signal[0])
+        self.assertEqual(p.exitcode, 0)
 
 #
 # Test to verify handle verification, see issue 3321

From report at bugs.python.org  Wed Aug 28 16:25:21 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 28 Aug 2013 14:25:21 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377699921.91.0.29692012696.issue17741@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

This patch implements the renaming and updates the documentation.

----------
Added file: http://bugs.python.org/file31497/issue17741.api-renames.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Wed Aug 28 16:27:29 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 28 Aug 2013 14:27:29 +0000
Subject: [issue18868] Python3 unbuffered stdin
In-Reply-To: <1377681564.92.0.926371389199.issue18868@psf.upfronthosting.co.za>
Message-ID: <1377700049.07.0.346292459469.issue18868@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

Try using Popen(..., bufsize=0).

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18868>
_______________________________________

From report at bugs.python.org  Wed Aug 28 16:28:47 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 28 Aug 2013 14:28:47 +0000
Subject: [issue18786] test_multiprocessing_spawn crashes under PowerLinux
In-Reply-To: <1376948017.66.0.62278437821.issue18786@psf.upfronthosting.co.za>
Message-ID: <1377700127.27.0.481068548039.issue18786@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

It should be fixed now so I will close.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18786>
_______________________________________

From report at bugs.python.org  Wed Aug 28 16:34:21 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Aug 2013 14:34:21 +0000
Subject: [issue18868] Python3 unbuffered stdin
In-Reply-To: <1377681564.92.0.926371389199.issue18868@psf.upfronthosting.co.za>
Message-ID: <1377700461.72.0.461133408946.issue18868@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray
versions:  -Python 3.1, Python 3.2, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18868>
_______________________________________

From report at bugs.python.org  Wed Aug 28 18:24:53 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 28 Aug 2013 16:24:53 +0000
Subject: [issue18869] test suite: faulthandler signal handler is lost
Message-ID: <1377707093.4.0.0816466324955.issue18869@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

At the beginning of the test suit execution, faulthandler registers its signal handler for fatal signals, as well as SIGUSR1 and SIGALRM.

The problem is that some tests temporary change those handlers, e.g. for EINTR-handling tests.
While they do restore the original handlers after the test, this doesn't work as expected because of an artifact of the signal implementation: when a signal handler isn't registered through the signal module (e.g. directly from C for faulthandler), getsignal() and setsignal() return None/SIG_DFL (depending on whether it was registered before or after the module initialization). Which means that when the test is done, it will restore the default signal handler, and not the faulthandler's one. Thus, any subsequent crash due to this signal won't benefit from faulthandler debug output, see e.g. (issue #18786):
http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.x/builds/616/steps/test/logs/stdio
"""
[310/379] test_multiprocessing_spawn
make: *** [buildbottest] User defined signal 1
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/semaphore_tracker.py:121: UserWarning: semaphore_tracker: There appear to be 4 leaked semaphores to clean up at shutdown
  len(cache))
program finished with exit code 2
elapsedTime=2459.665997
"""

One way to fix this would be to add a WithSignalHandler(signal, handler) context manager to test.support that would replace the signal handler upon entry, and re-register faulthandler's handler upon exit.

----------
components: Tests
messages: 196387
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: test suite: faulthandler signal handler is lost
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18869>
_______________________________________

From report at bugs.python.org  Wed Aug 28 18:39:49 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 28 Aug 2013 16:39:49 +0000
Subject: [issue18702] Report skipped tests as skipped
In-Reply-To: <1376132966.91.0.713996712724.issue18702@psf.upfronthosting.co.za>
Message-ID: <1377707989.33.0.0917458951527.issue18702@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18702>
_______________________________________

From report at bugs.python.org  Wed Aug 28 18:53:51 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 28 Aug 2013 16:53:51 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377708831.88.0.753134810879.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Any comments regarding my naming suggestion?

Calling it a "push" parser is just too ambiguous.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Wed Aug 28 18:54:19 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 28 Aug 2013 16:54:19 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377708859.35.0.387196322301.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Erm, "pull" parser, but you see what I mean.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Wed Aug 28 18:55:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Aug 2013 16:55:20 +0000
Subject: [issue18869] test suite: faulthandler signal handler is lost
In-Reply-To: <1377707093.4.0.0816466324955.issue18869@psf.upfronthosting.co.za>
Message-ID: <1377708920.68.0.5645539933.issue18869@psf.upfronthosting.co.za>


R. David Murray added the comment:

See also issue 3948 for another variation of this problem with getsignal/setsignal.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18869>
_______________________________________

From report at bugs.python.org  Wed Aug 28 19:36:51 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 28 Aug 2013 17:36:51 +0000
Subject: [issue18864] Implementation for PEP 451
 (importlib.machinery.ModuleSpec)
In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za>
Message-ID: <1377711411.53.0.0698459958476.issue18864@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18864>
_______________________________________

From report at bugs.python.org  Wed Aug 28 19:37:31 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 28 Aug 2013 17:37:31 +0000
Subject: [issue18858] dummy_threading lacks threading.get_ident() equivalent
In-Reply-To: <1377638843.21.0.0472654933915.issue18858@psf.upfronthosting.co.za>
Message-ID: <1377711451.52.0.725801150909.issue18858@psf.upfronthosting.co.za>


Brett Cannon added the comment:

There should actually be a test to catch the inconsistencies.

----------
nosy: +brett.cannon
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18858>
_______________________________________

From report at bugs.python.org  Wed Aug 28 19:45:33 2013
From: report at bugs.python.org (Piotr Lopusiewicz)
Date: Wed, 28 Aug 2013 17:45:33 +0000
Subject: [issue14597] Cannot unload dll in ctypes until script exits
In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za>
Message-ID: <1377711933.86.0.531527745465.issue14597@psf.upfronthosting.co.za>


Piotr Lopusiewicz added the comment:

>>For most ctypes uses, closing is irrelevant, since people typically access system libraries that are independently loaded anyway, so closing them would not have any effect.

My use case is this: I test some things, then I need to recompile my .dll without closing the interpreter (as building stuff to begin tests is quiet expensive) then reload it. I can't recompile it because Windows blocks the .dll file and gcc can't overwrite it. Deleting the reference and running gc.collect() doesn't work.
It would be very nice to have a way to do this.

----------
nosy: +Piotr.Lopusiewicz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14597>
_______________________________________

From report at bugs.python.org  Wed Aug 28 19:50:16 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 28 Aug 2013 17:50:16 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377712216.33.0.344375875746.issue18851@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Yes, the problem is that the pipes FDs are closed twice if fork() succeeds, but exec() fails.

They're closed in _execute_child():
  1286                 if p2cread is not None and p2cwrite is not None:
  1287                     os.close(p2cread)
  1288                 if c2pwrite is not None and c2pread is not None:
  1289                     os.close(c2pwrite)
  1290                 if errwrite is not None and errread is not None:
  1291                     os.close(errwrite)

And then again in Popen.__init__:
   716             if stdin == PIPE:
   717                 to_close.extend((p2cread, p2cwrite))
   718             if stdout == PIPE:
   719                 to_close.extend((c2pread, c2pwrite))
   720             if stderr == PIPE:
   721                 to_close.extend((errread, errwrite))

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Wed Aug 28 19:50:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 17:50:22 +0000
Subject: [issue18869] test suite: faulthandler signal handler is lost
In-Reply-To: <1377707093.4.0.0816466324955.issue18869@psf.upfronthosting.co.za>
Message-ID: <1377712222.75.0.805473660121.issue18869@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Or perhaps we could enhance the signal module so that getsignal() return something (i.e. a specific object) which can restore the C signal handler. That would be better than special-casing faulthandler, IMHO.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18869>
_______________________________________

From report at bugs.python.org  Wed Aug 28 19:53:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 17:53:46 +0000
Subject: [issue18868] Python3 unbuffered stdin
In-Reply-To: <1377681564.92.0.926371389199.issue18868@psf.upfronthosting.co.za>
Message-ID: <1377712426.41.0.17029173977.issue18868@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Indeed, this is not related to sys.stdin, but to Popen's own buffering, and the fix is either to pass "bufsize=0" or to flush() when you need to.

I'm closing as invalid, don't hesitate to re-open if I misunderstood something.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18868>
_______________________________________

From report at bugs.python.org  Wed Aug 28 20:09:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 18:09:28 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377713368.65.0.987352134441.issue18851@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I wonder how the closing works under Windows. os.close() is called on handles returned by _get_handles(), but those are Windowns HANDLE values, not C file descriptors: os.close() probably fails on them (don't have a Windows VM to check, sorry). I guess the HANDLEs are then leaked...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Wed Aug 28 20:17:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 18:17:35 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377713855.02.0.218976244145.issue18851@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch for 2.7. I don't know how to write a test for it, though.

----------
keywords: +patch
Added file: http://bugs.python.org/file31498/subprocess_issue18851.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Wed Aug 28 20:18:22 2013
From: report at bugs.python.org (Merlijn van Deen)
Date: Wed, 28 Aug 2013 18:18:22 +0000
Subject: [issue18870] eval() uses latin-1 to decode str
Message-ID: <1377713902.12.0.966249722349.issue18870@psf.upfronthosting.co.za>


New submission from Merlijn van Deen:

Steps to reproduce:
-------------------
>>> eval("u'?'")
# in an utf-8 console, so this is equivalent to
>>> eval("u'\xc3\xa4'")

Actual result:
----------------
u'\xc3\xa4'
# i.e.: u'??'

Expected result:
-----------------
SyntaxError: Non-ASCII character '\xc3' in file <string> on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
(which is what would happen if it was in a source file)

Or, alternatively:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 2: ordinal not in range(128)
(which is what results from decoding the str with sys.getdefaultencoding())

Instead, the string is interpreted as latin-1. The same happens for ast.literal_eval - even calling compile() directly.

In python 3.2, this is the result, as utf-8 is used as default source encoding:
>>> eval(b"'\xc3\xa4'")
'?'

Workarounds
----------
>>> eval("# encoding: utf-8\nu'\xc3\xa4'")
u'\xe4'
>>> eval("u'\xc3\xa4'".decode('utf-8'))
u'\xe4'


I understand this might be considered a WONTFIX, as it would change behavior some people might depend on. Nonetheless, documenting this explicitly seems a sensible thing to do.

----------
messages: 196398
nosy: valhallasw
priority: normal
severity: normal
status: open
title: eval() uses latin-1 to decode str
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18870>
_______________________________________

From report at bugs.python.org  Wed Aug 28 20:24:40 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 28 Aug 2013 18:24:40 +0000
Subject: [issue18869] test suite: faulthandler signal handler is lost
In-Reply-To: <1377712222.75.0.805473660121.issue18869@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM145_gEos1-6rmY6nXdXTURXfOE1JLueQm45Hyuy3eZ5A@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Or perhaps we could enhance the signal module so that getsignal() return something (i.e. a specific object) which can restore the C signal handler. That would be better than special-casing faulthandler, IMHO.

Yes, I thought about that, see http://bugs.python.org/msg146560
The only problem I saw at that time is that we must make sure that the
object is indeed valid, otherwise the signal handler can jump to an
invalid address, and boom.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18869>
_______________________________________

From report at bugs.python.org  Wed Aug 28 20:26:52 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 18:26:52 +0000
Subject: [issue18869] test suite: faulthandler signal handler is lost
In-Reply-To: <CAH_1eM145_gEos1-6rmY6nXdXTURXfOE1JLueQm45Hyuy3eZ5A@mail.gmail.com>
Message-ID: <1377714404.2501.1.camel@fsol>


Antoine Pitrou added the comment:

> > Or perhaps we could enhance the signal module so that getsignal() return something (i.e. a specific object) which can restore the C signal handler. That would be better than special-casing faulthandler, IMHO.
> 
> Yes, I thought about that, see http://bugs.python.org/msg146560
> The only problem I saw at that time is that we must make sure that the
> object is indeed valid, otherwise the signal handler can jump to an
> invalid address, and boom.

Well, to make sure the object is valid, you can just ensure instances
can't be created from Python (for example, make tp_new raise an error),
and that the internal state can't be mutated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18869>
_______________________________________

From report at bugs.python.org  Wed Aug 28 20:27:29 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 28 Aug 2013 18:27:29 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <1377425438.05.0.844782118298.issue18643@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3hbHu-g826CXyEqp0uqR5748X8MUK040w8DcRfnWum-g@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Victor, did you have a chance to test the patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Wed Aug 28 20:28:54 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Aug 2013 18:28:54 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <3cQFpF345Mz7Lkb@mail.python.org>


Roundup Robot added the comment:

New changeset 1c2a37459c70 by Andrew Svetlov in branch 'default':
Issue #11798: TestSuite now drops references to own tests after execution.
http://hg.python.org/cpython/rev/1c2a37459c70

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Wed Aug 28 20:29:31 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 28 Aug 2013 18:29:31 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1377714571.97.0.371571732328.issue11798@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Wed Aug 28 20:33:38 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 28 Aug 2013 18:33:38 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <CAP7+vJJJFBg+=87Dh9mMHUzDSV7quHUZL51hwVZCM-F9VFQeJA@mail.gmail.com>
Message-ID: <CAH_1eM3zApLb9ktPS7gn=Q63C0vEuKHbrF6peu43K0nBYSnUPA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Alright, here's the patch, with all the changes discussed (and of
cours a separate selectors.py).

----------
Added file: http://bugs.python.org/file31499/selectors-14.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________
-------------- next part --------------
diff -r df2fdd42b375 Doc/library/selectors.rst
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Doc/library/selectors.rst	Wed Aug 28 18:34:10 2013 +0200
@@ -0,0 +1,229 @@
+:mod:`selectors` -- High-level I/O multiplexing
+===============================================
+
+.. module:: selectors
+   :synopsis: High-level I/O multiplexing.
+
+.. versionadded:: 3.4
+
+
+Introduction
+------------
+
+This module allows high-level and efficient I/O multiplexing, built upon the
+:mod:`select` module primitives. Users are encouraged to use this module
+instead, unless they want precise control over the OS-level primitives used.
+
+It defines a :class:`BaseSelector` abstract base class, along with several
+concrete implementations (:class:`KqueueSelector`, :class:`EpollSelector`...),
+that can be used to wait for I/O readiness notification on multiple file
+objects. In the following, "file object" refers to any object with a
+:meth:`fileno()` method, or a raw file descriptor. See :term:`file object`.
+
+:class:`DefaultSelector` is an alias to the most efficient implementation
+available on the current platform: this should be the default choice for most
+users.
+
+.. note::
+   The type of file objects supported depends on the platform: on Windows,
+   sockets are supported, but not pipes, whereas on Unix, both are supported
+   (some other types may be supported as well, such as fifos or special
+   devices).
+
+.. seealso::
+
+   :mod:`select`
+       Low-level I/O multiplexing module.
+
+
+Classes
+-------
+
+Classes hierarchy::
+
+   BaseSelector
+   +-- SelectSelector
+   +-- PollSelector
+   +-- EpollSelector
+   +-- KqueueSelector
+
+
+In the following, *events* is a bitwise mask indicating which I/O events should
+be waited for on a given file object. It can be a combination of the constants
+below:
+
+   +-----------------------+-----------------------------------------------+
+   | Constant              | Meaning                                       |
+   +=======================+===============================================+
+   | :const:`EVENT_READ`   | Available for read                            |
+   +-----------------------+-----------------------------------------------+
+   | :const:`EVENT_WRITE`  | Available for write                           |
+   +-----------------------+-----------------------------------------------+
+
+
+.. class:: SelectorKey
+
+   A :class:`SelectorKey` is a :class:`~collections.namedtuple` used to
+   associate a file object to its underlying file decriptor, selected event
+   mask and attached data. It is returned by several :class:`BaseSelector`
+   methods.
+
+   .. attribute:: fileobj
+
+      File object registered.
+
+   .. attribute:: fd
+
+      Underlying file descriptor.
+
+   .. attribute:: events
+
+      Events that must be waited for this file object.
+
+   .. attribute:: data
+
+      Optional opaque data associated to this file object: for example, this
+      could be used to store per-client session.
+
+
+.. class:: BaseSelector
+
+   A :class:`BaseSelector` is used to wait for I/O event readiness on multiple
+   file objects. It supports file stream registration, unregistration, and a
+   method to wait for I/O events on those streams, with an optional timeout.
+   It's an abstract base class, so cannot be instanciated. Use
+   :class:`DefaultSelector` instead, or one of :class:`SelectSelector`,
+   :class:`KqueueSelector` etc. if you want to specifically use an
+   implementation, and your platform supports it.
+   :class:`BaseSelector` and its concrete implementations support the context
+   manager protocol.
+
+   .. method:: register(fileobj, events, data=None)
+
+      Register a file object for selection, monitoring it for I/O events.
+
+      *fileobj* is the file object to monitor
+      *events* is a bitwise mask of events to monitor
+      *data* is an opaque object
+
+      This returns a new :class:`SelectorKey` instance, or raises a
+      :exc:`ValueError` in case of invalid event mask or file descriptor, or
+      :exc:`KeyError` if the file object is already registered.
+
+   .. method:: unregister(fileobj)
+
+      Unregister a file object from selection, removing it from monitoring.
+
+      *fileobj* must be a file object previously registered.
+
+      This returns the associated :class:`SelectorKey` instance, or raises a
+      :exc:`KeyError` if the file object is not registered.
+
+   .. method:: modify(fileobj, events, data=None)
+
+      Change a registered file object monitored events or attached data.
+
+      This is equivalent to :meth:`BaseSelector.unregister(fileobj)` followed by
+      :meth:`BaseSelector.register(fileobj, events, data)`, except that it can be
+      implemented more efficiently.
+
+      This returns a new :class:`SelectorKey` instance, or raises a
+      :exc:`ValueError` in case of invalid event mask or file descriptor, or
+      :exc:`KeyError` if the file object is not registered.
+
+   .. method:: select(timeout=None)
+
+      Wait until some registered file objects become ready, or the timeout
+      expires.
+
+      if ``timeout > 0``, this specifies the maximum wait time, in seconds
+      if ``timeout <= 0``, the call won't block, and will report the currently
+      ready file objects
+      if *timeout* is ``None``, the call will block until a monitored file object
+      becomes ready
+
+      This returns a list of ``(key, events)`` tuple, one for each ready file
+      object.
+
+      *key* is the :class:`SelectorKey` instance corresponding to a ready file
+      object
+      *events* is a bitmask of events ready on this file object
+
+   .. method:: close()
+
+      Close the selector.
+
+      This must be called to make sure that any underlying resource is freed.
+
+   .. method:: get_key(fileobj)
+
+      Return the key associated to a registered file object.
+
+      This returns the :class:`SelectorKey` instance associated to this file
+      object, or raises :exc:`KeyError` if the file object is not registered.
+
+
+.. class:: DefaultSelector()
+
+   The default selector class, using the most efficient implementation
+   available on the current platform. This should be the default choice for
+   most users.
+
+
+.. class:: SelectSelector()
+
+   :func:`~select.select`-based selector.
+
+
+.. class:: PollSelector()
+
+   :func:`~select.poll`-based selector.
+
+
+.. class:: EpollSelector()
+
+   :func:`~select.epoll`-based selector.
+
+   .. method:: fileno()
+
+      This returns the file descriptor used by the underlying
+      :func:`~select.epoll` object.
+
+
+.. class:: KqueueSelector()
+
+   :func:`~select.kqueue`-based selector.
+
+   .. method:: fileno()
+
+      This returns the file descriptor used by the underlying
+      :func:`~select.kqueue` object.
+
+
+Examples of selector usage::
+
+   >>> import selectors
+   >>> import socket
+   >>>
+   >>> s = selectors.DefaultSelector()
+   >>> r, w = socket.socketpair()
+   >>>
+   >>> s.register(r, selectors.EVENT_READ)
+   SelectorKey(fileobj=<socket.socket fd=4, family=1, type=1, proto=0>, fd=4, events=1, data=None)
+   >>> s.register(w, selectors.EVENT_WRITE)
+   SelectorKey(fileobj=<socket.socket fd=5, family=1, type=1, proto=0>, fd=5, events=2, data=None)
+   >>>
+   >>> print(s.select())
+   [(SelectorKey(fileobj=<socket.socket fd=5, family=1, type=1, proto=0>, fd=5, events=2, data=None), 2)]
+   >>>
+   >>> for key, events in s.select():
+   ...     if events & selectors.EVENT_WRITE:
+   ...         key.fileobj.send(b'spam')
+   ...
+   4
+   >>> for key, events in s.select():
+   ...     if events & selectors.EVENT_READ:
+   ...         print(key.fileobj.recv(1024))
+   ...
+   b'spam'
+   >>> s.close()
diff -r df2fdd42b375 Doc/whatsnew/3.4.rst
--- a/Doc/whatsnew/3.4.rst	Mon Aug 26 22:28:21 2013 +0200
+++ b/Doc/whatsnew/3.4.rst	Wed Aug 28 18:34:10 2013 +0200
@@ -160,10 +160,11 @@
 New Modules
 ===========
 
-.. module name
-.. -----------
+selectors
+---------
 
-* None yet.
+The new :mod:`selectors` module allows high-level and efficient I/O
+multiplexing, built upon the :mod:`select` module primitives.
 
 
 Improved Modules
diff -r df2fdd42b375 Lib/selectors.py
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Lib/selectors.py	Wed Aug 28 18:34:10 2013 +0200
@@ -0,0 +1,422 @@
+"""Selectors module.
+
+This module allows high-level and efficient I/O multiplexing, built upon the
+`select` module primitives.
+"""
+
+
+from abc import ABCMeta, abstractmethod
+from collections import namedtuple
+import functools
+import select
+import sys
+try:
+    from time import monotonic as time
+except ImportError:
+    from time import time as time
+
+
+# generic events, that must be mapped to implementation-specific ones
+EVENT_READ = (1 << 0)
+EVENT_WRITE = (1 << 1)
+
+
+def _fileobj_to_fd(fileobj):
+    """Return a file descriptor from a file object.
+
+    Parameters:
+    fileobj -- file object
+
+    Returns:
+    corresponding file descriptor
+    """
+    if isinstance(fileobj, int):
+        fd = fileobj
+    else:
+        try:
+            fd = int(fileobj.fileno())
+        except (AttributeError, ValueError):
+            raise ValueError("Invalid file object: {!r}".format(fileobj)) from None
+    if fd < 0:
+        raise ValueError("Invalid file descriptor: {}".format(fd))
+    return fd
+
+
+def _select_interrupt_wrapper(func):
+    """InterruptedError-safe wrapper for select(), taking the (optional)
+    timeout into account."""
+    @functools.wraps(func)
+    def wrapper(self, timeout=None):
+        if timeout is not None and timeout > 0:
+            deadline = time() + timeout
+        while True:
+            try:
+                return func(self, timeout)
+            except InterruptedError:
+                if timeout is not None:
+                    if timeout > 0:
+                        timeout = deadline - time()
+                    if timeout <= 0:
+                        # timeout expired
+                        return []
+
+    return wrapper
+
+
+SelectorKey = namedtuple('SelectorKey', ['fileobj', 'fd', 'events', 'data'])
+"""Object used to associate a file object to its backing file descriptor,
+selected event mask and attached data."""
+
+
+class BaseSelector(metaclass=ABCMeta):
+    """Base selector class.
+
+    A selector supports registering file objects to be monitored for specific
+    I/O events.
+
+    A file object is a file descriptor or any object with a `fileno()` method.
+    An arbitrary object can be attached to the file object, which can be used
+    for example to store context information, a callback, etc.
+
+    A selector can use various implementations (select(), poll(), epoll()...)
+    depending on the platform. The default `Selector` class uses the most
+    performant implementation on the current platform.
+    """
+
+    def __init__(self):
+        # this maps file descriptors to keys
+        self._fd_to_key = {}
+        # this maps file objects to keys - for fast (un)registering
+        self._fileobj_to_key = {}
+
+    def register(self, fileobj, events, data=None):
+        """Register a file object.
+
+        Parameters:
+        fileobj -- file object
+        events  -- events to monitor (bitwise mask of EVENT_READ|EVENT_WRITE)
+        data    -- attached data
+
+        Returns:
+        SelectorKey instance
+        """
+        if (not events) or (events & ~(EVENT_READ | EVENT_WRITE)):
+            raise ValueError("Invalid events: {}".format(events))
+
+        key = SelectorKey(fileobj, _fileobj_to_fd(fileobj), events, data)
+
+        if key.fd in self._fd_to_key:
+            raise KeyError("{!r} (FD {}) is already "
+                           "registered".format(fileobj, key.fd))
+
+        self._fd_to_key[key.fd] = key
+        self._fileobj_to_key[fileobj] = key
+        return key
+
+    def unregister(self, fileobj):
+        """Unregister a file object.
+
+        Parameters:
+        fileobj -- file object
+
+        Returns:
+        SelectorKey instance
+        """
+        try:
+            key = self._fileobj_to_key.pop(fileobj)
+            del self._fd_to_key[key.fd]
+        except KeyError:
+            raise KeyError("{!r} is not registered".format(fileobj)) from None
+        return key
+
+    def modify(self, fileobj, events, data=None):
+        """Change a registered file object monitored events or attached data.
+
+        Parameters:
+        fileobj -- file object
+        events  -- events to monitor (bitwise mask of EVENT_READ|EVENT_WRITE)
+        data    -- attached data
+
+        Returns:
+        SelectorKey instance
+        """
+        # TODO: Subclasses can probably optimize this even further.
+        try:
+            key = self._fileobj_to_key[fileobj]
+        except KeyError:
+            raise KeyError("{!r} is not registered".format(fileobj)) from None
+        if events != key.events or data != key.data:
+            # TODO: If only the data changed, use a shortcut that only
+            # updates the data.
+            self.unregister(fileobj)
+            return self.register(fileobj, events, data)
+        else:
+            return key
+
+    @abstractmethod
+    def select(self, timeout=None):
+        """Perform the actual selection, until some monitored file objects are
+        ready or a timeout expires.
+
+        Parameters:
+        timeout -- if timeout > 0, this specifies the maximum wait time, in
+                   seconds
+                   if timeout <= 0, the select() call won't block, and will
+                   report the currently ready file objects
+                   if timeout is None, select() will block until a monitored
+                   file object becomes ready
+
+        Returns:
+        list of (key, events) for ready file objects
+        `events` is a bitwise mask of EVENT_READ|EVENT_WRITE
+        """
+        raise NotImplementedError()
+
+    def close(self):
+        """Close the selector.
+
+        This must be called to make sure that any underlying resource is freed.
+        """
+        self._fd_to_key.clear()
+        self._fileobj_to_key.clear()
+
+    def get_key(self, fileobj):
+        """Return the key associated to a registered file object.
+
+        Returns:
+        SelectorKey for this file object
+        """
+        try:
+            return self._fileobj_to_key[fileobj]
+        except KeyError:
+            raise KeyError("{} is not registered".format(fileobj)) from None
+
+    def __enter__(self):
+        return self
+
+    def __exit__(self, *args):
+        self.close()
+
+    def _key_from_fd(self, fd):
+        """Return the key associated to a given file descriptor.
+
+        Parameters:
+        fd -- file descriptor
+
+        Returns:
+        corresponding key, or None if not found
+        """
+        try:
+            return self._fd_to_key[fd]
+        except KeyError:
+            return None
+
+
+class SelectSelector(BaseSelector):
+    """Select-based selector."""
+
+    def __init__(self):
+        super().__init__()
+        self._readers = set()
+        self._writers = set()
+
+    def register(self, fileobj, events, data=None):
+        key = super().register(fileobj, events, data)
+        if events & EVENT_READ:
+            self._readers.add(key.fd)
+        if events & EVENT_WRITE:
+            self._writers.add(key.fd)
+        return key
+
+    def unregister(self, fileobj):
+        key = super().unregister(fileobj)
+        self._readers.discard(key.fd)
+        self._writers.discard(key.fd)
+        return key
+
+    if sys.platform == 'win32':
+        def _select(self, r, w, _, timeout=None):
+            r, w, x = select.select(r, w, w, timeout)
+            return r, w + x, []
+    else:
+        _select = select.select
+
+    @_select_interrupt_wrapper
+    def select(self, timeout=None):
+        timeout = None if timeout is None else max(timeout, 0)
+        r, w, _ = self._select(self._readers, self._writers, [], timeout)
+        r = set(r)
+        w = set(w)
+        ready = []
+        for fd in r | w:
+            events = 0
+            if fd in r:
+                events |= EVENT_READ
+            if fd in w:
+                events |= EVENT_WRITE
+
+            key = self._key_from_fd(fd)
+            if key:
+                ready.append((key, events & key.events))
+        return ready
+
+
+if hasattr(select, 'poll'):
+
+    class PollSelector(BaseSelector):
+        """Poll-based selector."""
+
+        def __init__(self):
+            super().__init__()
+            self._poll = select.poll()
+
+        def register(self, fileobj, events, data=None):
+            key = super().register(fileobj, events, data)
+            poll_events = 0
+            if events & EVENT_READ:
+                poll_events |= select.POLLIN
+            if events & EVENT_WRITE:
+                poll_events |= select.POLLOUT
+            self._poll.register(key.fd, poll_events)
+            return key
+
+        def unregister(self, fileobj):
+            key = super().unregister(fileobj)
+            self._poll.unregister(key.fd)
+            return key
+
+        @_select_interrupt_wrapper
+        def select(self, timeout=None):
+            timeout = None if timeout is None else max(int(1000 * timeout), 0)
+            ready = []
+            fd_event_list = self._poll.poll(timeout)
+            for fd, event in fd_event_list:
+                events = 0
+                if event & ~select.POLLIN:
+                    events |= EVENT_WRITE
+                if event & ~select.POLLOUT:
+                    events |= EVENT_READ
+
+                key = self._key_from_fd(fd)
+                if key:
+                    ready.append((key, events & key.events))
+            return ready
+
+
+if hasattr(select, 'epoll'):
+
+    class EpollSelector(BaseSelector):
+        """Epoll-based selector."""
+
+        def __init__(self):
+            super().__init__()
+            self._epoll = select.epoll()
+
+        def fileno(self):
+            return self._epoll.fileno()
+
+        def register(self, fileobj, events, data=None):
+            key = super().register(fileobj, events, data)
+            epoll_events = 0
+            if events & EVENT_READ:
+                epoll_events |= select.EPOLLIN
+            if events & EVENT_WRITE:
+                epoll_events |= select.EPOLLOUT
+            self._epoll.register(key.fd, epoll_events)
+            return key
+
+        def unregister(self, fileobj):
+            key = super().unregister(fileobj)
+            self._epoll.unregister(key.fd)
+            return key
+
+        @_select_interrupt_wrapper
+        def select(self, timeout=None):
+            timeout = -1 if timeout is None else max(timeout, 0)
+            max_ev = len(self._fd_to_key)
+            ready = []
+            fd_event_list = self._epoll.poll(timeout, max_ev)
+            for fd, event in fd_event_list:
+                events = 0
+                if event & ~select.EPOLLIN:
+                    events |= EVENT_WRITE
+                if event & ~select.EPOLLOUT:
+                    events |= EVENT_READ
+
+                key = self._key_from_fd(fd)
+                if key:
+                    ready.append((key, events & key.events))
+            return ready
+
+        def close(self):
+            super().close()
+            self._epoll.close()
+
+
+if hasattr(select, 'kqueue'):
+
+    class KqueueSelector(BaseSelector):
+        """Kqueue-based selector."""
+
+        def __init__(self):
+            super().__init__()
+            self._kqueue = select.kqueue()
+
+        def fileno(self):
+            return self._kqueue.fileno()
+
+        def register(self, fileobj, events, data=None):
+            key = super().register(fileobj, events, data)
+            if events & EVENT_READ:
+                kev = select.kevent(key.fd, select.KQ_FILTER_READ, select.KQ_EV_ADD)
+                self._kqueue.control([kev], 0, 0)
+            if events & EVENT_WRITE:
+                kev = select.kevent(key.fd, select.KQ_FILTER_WRITE, select.KQ_EV_ADD)
+                self._kqueue.control([kev], 0, 0)
+            return key
+
+        def unregister(self, fileobj):
+            key = super().unregister(fileobj)
+            if key.events & EVENT_READ:
+                kev = select.kevent(key.fd, select.KQ_FILTER_READ, select.KQ_EV_DELETE)
+                self._kqueue.control([kev], 0, 0)
+            if key.events & EVENT_WRITE:
+                kev = select.kevent(key.fd, select.KQ_FILTER_WRITE, select.KQ_EV_DELETE)
+                self._kqueue.control([kev], 0, 0)
+            return key
+
+        @_select_interrupt_wrapper
+        def select(self, timeout=None):
+            timeout = None if timeout is None else max(timeout, 0)
+            max_ev = len(self._fd_to_key)
+            ready = []
+            kev_list = self._kqueue.control(None, max_ev, timeout)
+            for kev in kev_list:
+                fd = kev.ident
+                flag = kev.filter
+                events = 0
+                if flag == select.KQ_FILTER_READ:
+                    events |= EVENT_READ
+                if flag == select.KQ_FILTER_WRITE:
+                    events |= EVENT_WRITE
+
+                key = self._key_from_fd(fd)
+                if key:
+                    ready.append((key, events & key.events))
+            return ready
+
+        def close(self):
+            super().close()
+            self._kqueue.close()
+
+
+# Choose the best implementation: roughly, epoll|kqueue > poll > select.
+# select() also can't accept a FD > FD_SETSIZE (usually around 1024)
+if 'KqueueSelector' in globals():
+    DefaultSelector = KqueueSelector
+elif 'EpollSelector' in globals():
+    DefaultSelector = EpollSelector
+elif 'PollSelector' in globals():
+    DefaultSelector = PollSelector
+else:
+    DefaultSelector = SelectSelector
diff -r df2fdd42b375 Lib/test/test_selectors.py
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Lib/test/test_selectors.py	Wed Aug 28 18:34:10 2013 +0200
@@ -0,0 +1,380 @@
+import errno
+import os
+import random
+import selectors
+import signal
+import socket
+from test import support
+import unittest
+try:
+    from time import monotonic as time
+except ImportError:
+    from time import time as time
+from time import sleep
+try:
+    import resource
+except ImportError:
+    resource = None
+
+
+if hasattr(socket, 'socketpair'):
+    socketpair = socket.socketpair
+else:
+    def socketpair(family=socket.AF_INET, type=socket.SOCK_STREAM, proto=0):
+        with socket.socket(family, type, proto) as l:
+            l.bind(('127.0.0.1', 0))
+            l.listen(3)
+            c = socket.socket(family, type, proto)
+            try:
+                c.connect(l.getsockname())
+                caddr = c.getsockname()
+                while True:
+                    a, addr = l.accept()
+                    # check that we've got the correct client
+                    if addr == caddr:
+                        return c, a
+                    a.close()
+            except OSError:
+                c.close()
+                raise
+
+
+def find_ready_matching(ready, flag):
+    match = []
+    for key, events in ready:
+        if events & flag:
+            match.append(key.fileobj)
+    return match
+
+
+class BaseSelectorTestCase(unittest.TestCase):
+
+    def test_register(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        key = s.register(rd, selectors.EVENT_READ, "data")
+        self.assertIsInstance(key, selectors.SelectorKey)
+        self.assertEqual(key.fileobj, rd)
+        self.assertEqual(key.fd, rd.fileno())
+        self.assertEqual(key.events, selectors.EVENT_READ)
+        self.assertEqual(key.data, "data")
+
+        # register an unknown event
+        self.assertRaises(ValueError, s.register, 0, 999999)
+
+        # register an invalid FD
+        self.assertRaises(ValueError, s.register, -10, selectors.EVENT_READ)
+
+        # register twice
+        self.assertRaises(KeyError, s.register, rd, selectors.EVENT_READ)
+
+        # register the same FD, but with a different object
+        self.assertRaises(KeyError, s.register, rd.fileno(), selectors.EVENT_READ)
+
+    def test_unregister(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        s.register(rd, selectors.EVENT_READ)
+        s.unregister(rd)
+
+        # unregister an unknown file obj
+        self.assertRaises(KeyError, s.unregister, 999999)
+
+        # unregister twice
+        self.assertRaises(KeyError, s.unregister, rd)
+
+    def test_modify(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        key = s.register(rd, selectors.EVENT_READ)
+
+        # modify events
+        key2 = s.modify(rd, selectors.EVENT_WRITE)
+        self.assertNotEqual(key.events, key2.events)
+        self.assertEqual(key2, s.get_key(rd))
+
+        s.unregister(rd)
+
+        # modify data
+        d1 = object()
+        d2 = object()
+
+        key = s.register(rd, selectors.EVENT_READ, d1)
+        key2 = s.modify(rd, selectors.EVENT_READ, d2)
+        self.assertEqual(key.events, key2.events)
+        self.assertNotEqual(key.data, key2.data)
+        self.assertEqual(key2, s.get_key(rd))
+
+        # modify unknown file obj
+        self.assertRaises(KeyError, s.modify, 999999, selectors.EVENT_READ)
+
+    def test_close(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        s.register(rd, selectors.EVENT_READ)
+        s.register(wr, selectors.EVENT_WRITE)
+
+        s.close()
+        self.assertRaises(KeyError, s.get_key, rd)
+        self.assertRaises(KeyError, s.get_key, wr)
+
+    def test_get_key(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        key = s.register(rd, selectors.EVENT_READ, "data")
+        self.assertEqual(key, s.get_key(rd))
+
+        # unknown file obj
+        self.assertRaises(KeyError, s.get_key, 999999)
+
+    def test_select(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        s.register(rd, selectors.EVENT_READ)
+        wr_key = s.register(wr, selectors.EVENT_WRITE)
+
+        result = s.select()
+        for key, events in result:
+            self.assertTrue(isinstance(key, selectors.SelectorKey))
+            self.assertTrue(events)
+            self.assertFalse(events & ~(selectors.EVENT_READ |
+                                        selectors.EVENT_WRITE))
+
+        self.assertEqual([(wr_key, selectors.EVENT_WRITE)], result)
+
+    def test_context_manager(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        with s as sel:
+            sel.register(rd, selectors.EVENT_READ)
+            sel.register(wr, selectors.EVENT_WRITE)
+
+        self.assertRaises(KeyError, s.get_key, rd)
+        self.assertRaises(KeyError, s.get_key, wr)
+
+    def test_fileno(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        if hasattr(s, 'fileno'):
+            fd = s.fileno()
+            self.assertTrue(isinstance(fd, int))
+            self.assertGreaterEqual(fd, 0)
+
+    def test_selector(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        NUM_SOCKETS = 12
+        MSG = b" This is a test."
+        MSG_LEN = len(MSG)
+        readers = []
+        writers = []
+        r2w = {}
+        w2r = {}
+
+        for i in range(NUM_SOCKETS):
+            rd, wr = socketpair()
+            self.addCleanup(rd.close)
+            self.addCleanup(wr.close)
+            s.register(rd, selectors.EVENT_READ)
+            s.register(wr, selectors.EVENT_WRITE)
+            readers.append(rd)
+            writers.append(wr)
+            r2w[rd] = wr
+            w2r[wr] = rd
+
+        bufs = []
+
+        while writers:
+            ready = s.select()
+            ready_writers = find_ready_matching(ready, selectors.EVENT_WRITE)
+            if not ready_writers:
+                self.fail("no sockets ready for writing")
+            wr = random.choice(ready_writers)
+            wr.send(MSG)
+
+            for i in range(10):
+                ready = s.select()
+                ready_readers = find_ready_matching(ready, selectors.EVENT_READ)
+                if ready_readers:
+                    break
+                # there might be delay between the write to the write end and
+                # the read end is reported ready
+                sleep(0.1)
+            else:
+                self.fail("no sockets ready for reading")
+            self.assertEqual([w2r[wr]], ready_readers)
+            rd = ready_readers[0]
+            buf = rd.recv(MSG_LEN)
+            self.assertEqual(len(buf), MSG_LEN)
+            bufs.append(buf)
+            s.unregister(r2w[rd])
+            s.unregister(rd)
+            writers.remove(r2w[rd])
+
+        self.assertEqual(bufs, [MSG] * NUM_SOCKETS)
+
+    def test_timeout(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        s.register(wr, selectors.EVENT_WRITE)
+        self.assertEqual(1, len(s.select(0)))
+        self.assertEqual(1, len(s.select(-1)))
+
+        s.unregister(wr)
+        s.register(rd, selectors.EVENT_READ)
+        t = time()
+        self.assertFalse(s.select(0))
+        self.assertFalse(s.select(-1))
+        self.assertTrue(time() - t < 0.3)
+
+        t = time()
+        self.assertFalse(s.select(1))
+        self.assertTrue(0.7 < time() - t < 1.3)
+
+    @unittest.skipUnless(hasattr(signal, "alarm"),
+                         "signal.alarm() required for this test")
+    def test_interrupted_retry(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        orig_alrm_handler = signal.signal(signal.SIGALRM, lambda *args: None)
+        self.addCleanup(signal.alarm, 0)
+        self.addCleanup(signal.signal, signal.SIGALRM, orig_alrm_handler)
+
+        signal.alarm(1)
+
+        s.register(rd, selectors.EVENT_READ)
+        t = time()
+        self.assertFalse(s.select(2))
+        self.assertTrue(1.7 < time() - t < 2.3)
+
+
+class ScalableSelectorMixIn:
+
+    @support.requires_mac_ver(10, 5)
+    @unittest.skipUnless(resource, "Test needs resource module")
+    def test_above_fd_setsize(self):
+        # A scalable implementation should have no problem with more than
+        # FD_SETSIZE file descriptors. Since we don't know the value, we just
+        # try to set the soft RLIMIT_NOFILE to the hard RLIMIT_NOFILE ceiling.
+        try:
+            soft, hard = resource.getrlimit(resource.RLIMIT_NOFILE)
+            resource.setrlimit(resource.RLIMIT_NOFILE, (hard, hard))
+            self.addCleanup(resource.setrlimit, resource.RLIMIT_NOFILE,
+                            (soft, hard))
+            NUM_FDS = hard
+        except OSError:
+            NUM_FDS = soft
+
+        # guard for already allocated FDs (stdin, stdout...)
+        NUM_FDS -= 32
+
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        for i in range(NUM_FDS):
+            try:
+                fd = os.dup(wr.fileno())
+            except OSError as e:
+                if e.errno == errno.EMFILE:
+                    # too many FD, skip
+                    self.skipTest("FD limit reached")
+                raise
+
+            self.addCleanup(os.close, fd)
+            s.register(fd, selectors.EVENT_WRITE)
+
+        self.assertEqual(NUM_FDS, len(s.select()))
+
+
+class DefaultSelectorTestCase(BaseSelectorTestCase):
+
+    SELECTOR = selectors.DefaultSelector
+
+
+class SelectSelectorTestCase(BaseSelectorTestCase):
+
+    SELECTOR = selectors.SelectSelector
+
+
+ at unittest.skipUnless(hasattr(selectors, 'PollSelector'),
+                     "Test needs selectors.PollSelector")
+class PollSelectorTestCase(BaseSelectorTestCase, ScalableSelectorMixIn):
+
+    SELECTOR = getattr(selectors, 'PollSelector', None)
+
+
+ at unittest.skipUnless(hasattr(selectors, 'EpollSelector'),
+                     "Test needs selectors.EpollSelector")
+class EpollSelectorTestCase(BaseSelectorTestCase, ScalableSelectorMixIn):
+
+    SELECTOR = getattr(selectors, 'EpollSelector', None)
+
+
+ at unittest.skipUnless(hasattr(selectors, 'KqueueSelector'),
+                     "Test needs selectors.KqueueSelector)")
+class KqueueSelectorTestCase(BaseSelectorTestCase, ScalableSelectorMixIn):
+
+    SELECTOR = getattr(selectors, 'KqueueSelector', None)
+
+
+def test_main():
+    tests = [DefaultSelectorTestCase, SelectSelectorTestCase,
+             PollSelectorTestCase, EpollSelectorTestCase,
+             KqueueSelectorTestCase]
+    support.run_unittest(*tests)
+    support.reap_children()
+
+
+if __name__ == "__main__":
+    test_main()

From report at bugs.python.org  Wed Aug 28 21:27:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Aug 2013 19:27:51 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1377718071.84.0.790013620877.issue11798@psf.upfronthosting.co.za>


R. David Murray added the comment:

This seems to be producing a test failure in test_doctest.  eg:

 http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.x/builds/1920

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Wed Aug 28 21:32:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 19:32:58 +0000
Subject: [issue18871] Be more stringent about the test suite
Message-ID: <1377718378.43.0.460982109409.issue18871@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Here is a proposal to make the devguide more precise and explicit about needing to run the entire test suite before committing a change.

----------
assignee: docs at python
components: Devguide, Documentation
files: test_suite.patch
keywords: patch
messages: 196405
nosy: asvetlov, docs at python, eric.araujo, ezio.melotti, ncoghlan, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: Be more stringent about the test suite
type: enhancement
versions: 3rd party
Added file: http://bugs.python.org/file31500/test_suite.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18871>
_______________________________________

From report at bugs.python.org  Wed Aug 28 21:35:53 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Aug 2013 19:35:53 +0000
Subject: [issue18702] Report skipped tests as skipped
In-Reply-To: <1376132966.91.0.713996712724.issue18702@psf.upfronthosting.co.za>
Message-ID: <1377718553.98.0.286189690357.issue18702@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18702>
_______________________________________

From report at bugs.python.org  Wed Aug 28 21:39:45 2013
From: report at bugs.python.org (Matt McClure)
Date: Wed, 28 Aug 2013 19:39:45 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1377718785.19.0.89843588753.issue11798@psf.upfronthosting.co.za>


Matt McClure added the comment:

This might fix it (untested):

diff -r d748d7020192 Lib/test/test_doctest.py
--- a/Lib/test/test_doctest.py	Sat Aug 03 10:09:25 2013 -0400
+++ b/Lib/test/test_doctest.py	Wed Aug 28 15:35:58 2013 -0400
@@ -2329,6 +2329,8 @@
 
     Now, when we run the test:
 
+      >>> suite = doctest.DocFileSuite('test_doctest.txt',
+      ...                          optionflags=doctest.DONT_ACCEPT_BLANKLINE)
       >>> result = suite.run(unittest.TestResult())
       >>> print(result.failures[0][1]) # doctest: +ELLIPSIS
       Traceback ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Wed Aug 28 21:45:07 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Aug 2013 19:45:07 +0000
Subject: [issue18870] eval() uses latin-1 to decode str
In-Reply-To: <1377713902.12.0.966249722349.issue18870@psf.upfronthosting.co.za>
Message-ID: <1377719107.42.0.212952835006.issue18870@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't think it is even "won't fix".  Your "workarounds" are just the way you need to feed non-latin1 text into Python2.  Since the default source encoding in python2 is latin-1, and that is documented, I'm not sure what additional documentation you want?

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18870>
_______________________________________

From report at bugs.python.org  Wed Aug 28 21:46:58 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Aug 2013 19:46:58 +0000
Subject: [issue18869] test suite: faulthandler signal handler is lost
In-Reply-To: <1377707093.4.0.0816466324955.issue18869@psf.upfronthosting.co.za>
Message-ID: <1377719218.1.0.755359429815.issue18869@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"One way to fix this would be to add a WithSignalHandler(signal, handler) context manager to test.support that would replace the signal handler upon entry, and re-register faulthandler's handler upon exit."

faulthandler.dump_traceback_later() is registered before each test, in test.regrtest.runtest().

You may reinstall signal handlers before each test, or fix signal.getsignal() and signal.signal(). I don't have a preference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18869>
_______________________________________

From report at bugs.python.org  Wed Aug 28 21:50:44 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Aug 2013 19:50:44 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <1375531895.31.0.501848123953.issue18643@psf.upfronthosting.co.za>
Message-ID: <1377719444.58.0.503445696134.issue18643@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Victor, did you have a chance to test the patch?

I tested socketpair.diff (modified to use it even on Linux) on another computer, and test ran successfully.

On my main computer (Fedora 18, Linux kernel 3.9.4), the test is failing. With sendall_write.diff, the test does pass. test.support.PIPE_MAX_SIZE=4194305 (4 MB) on this computer. I don't know for the other one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Wed Aug 28 21:51:10 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Aug 2013 19:51:10 +0000
Subject: [issue18871] Be more stringent about the test suite
In-Reply-To: <1377718378.43.0.460982109409.issue18871@psf.upfronthosting.co.za>
Message-ID: <1377719470.38.0.10949767816.issue18871@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks OK to me.  Do we want to also recommend more explicitly that the tests be run with -uall?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18871>
_______________________________________

From report at bugs.python.org  Wed Aug 28 21:56:42 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Aug 2013 19:56:42 +0000
Subject: [issue17036] Implementation of the PEP 433: Easier suppression of
 file descriptor inheritance
In-Reply-To: <1359151285.62.0.659364968053.issue17036@psf.upfronthosting.co.za>
Message-ID: <1377719802.39.0.0104757349486.issue17036@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The PEP 433 was rejected, replaced with the PEP 446.

----------
resolution:  -> rejected
status: open -> closed
superseder:  -> Implementation of the PEP 446: non-inheritable file descriptors

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17036>
_______________________________________

From report at bugs.python.org  Wed Aug 28 22:16:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 20:16:18 +0000
Subject: [issue18871] Be more stringent about the test suite
In-Reply-To: <1377718378.43.0.460982109409.issue18871@psf.upfronthosting.co.za>
Message-ID: <1377720978.63.0.846673837679.issue18871@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I don't know. I wouldn't insist too much on -uall, because generally it won't find anything more (except for network tests, perhaps).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18871>
_______________________________________

From report at bugs.python.org  Wed Aug 28 22:20:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 20:20:31 +0000
Subject: [issue18870] eval() uses latin-1 to decode str
In-Reply-To: <1377713902.12.0.966249722349.issue18870@psf.upfronthosting.co.za>
Message-ID: <1377721231.63.0.0300050247602.issue18870@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Since the default source encoding in python2 is latin-1

Mmh, really? According to PEP 263:

    Python will default to ASCII as standard encoding if no other
    encoding hints are given.

And indeed when trying Merlijn's code in a .py file rather than an eval() call, I get:

SyntaxError: Non-ASCII character '\xc3' in file tcc.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details

----------
components: +Interpreter Core -Documentation
nosy: +benjamin.peterson, pitrou
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18870>
_______________________________________

From report at bugs.python.org  Wed Aug 28 22:23:29 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Aug 2013 20:23:29 +0000
Subject: [issue18870] eval() uses latin-1 to decode str
In-Reply-To: <1377713902.12.0.966249722349.issue18870@psf.upfronthosting.co.za>
Message-ID: <1377721409.91.0.751261467486.issue18870@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Where / how do you type the eval() instruction? In IDLE, in the interactive prompt (>>>) or in a script (test.py)? What is your OS and what is your locale encoding?

Example:

$ python -m platform
Linux-3.9.4-200.fc18.x86_64-x86_64-with-fedora-18-Spherical_Cow
$ python -c 'import locale; print(locale.getpreferredencoding())'
UTF-8

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18870>
_______________________________________

From report at bugs.python.org  Wed Aug 28 22:24:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 20:24:39 +0000
Subject: [issue18870] eval() uses latin-1 to decode str
In-Reply-To: <1377713902.12.0.966249722349.issue18870@psf.upfronthosting.co.za>
Message-ID: <1377721479.81.0.637994950538.issue18870@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

$ python
Python 2.7.4 (default, Apr 19 2013, 18:28:01) 
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> eval("u'?'")
u'\xc3\xa4'
>>> import locale
>>> locale.getpreferredencoding()
'UTF-8'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18870>
_______________________________________

From report at bugs.python.org  Wed Aug 28 22:29:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 20:29:23 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377721763.84.0.113405055855.issue18851@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, here is a fixed patch for Windows under 2.7.

----------
Added file: http://bugs.python.org/file31501/subprocess_issue18851_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Wed Aug 28 22:32:46 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 28 Aug 2013 20:32:46 +0000
Subject: [issue18869] test suite: faulthandler signal handler is lost
In-Reply-To: <1377707093.4.0.0816466324955.issue18869@psf.upfronthosting.co.za>
Message-ID: <1377721966.57.0.494882203526.issue18869@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

I'll tackle #13285 instead.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
superseder:  -> signal module ignores external signal changes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18869>
_______________________________________

From report at bugs.python.org  Wed Aug 28 22:38:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 20:38:14 +0000
Subject: [issue13285] signal module ignores external signal changes
In-Reply-To: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za>
Message-ID: <1377722294.4.0.763693693854.issue13285@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13285>
_______________________________________

From report at bugs.python.org  Wed Aug 28 22:54:54 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 28 Aug 2013 20:54:54 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <1375531895.31.0.501848123953.issue18643@psf.upfronthosting.co.za>
Message-ID: <1377723294.33.0.45458883146.issue18643@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Since I'll update socket tests to also use support.PIPE_MAX_SIZE, maybe we should rename this variable while we're at it?
Anybody can think of a name that would work both for sockets and pipes?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Wed Aug 28 22:56:56 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Aug 2013 20:56:56 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <1375531895.31.0.501848123953.issue18643@psf.upfronthosting.co.za>
Message-ID: <1377723416.46.0.990785965458.issue18643@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Since I'll update socket tests to also use support.PIPE_MAX_SIZE, maybe we should rename this variable while we're at it?"

Why not using a different value (constant) for sockets?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Wed Aug 28 22:59:44 2013
From: report at bugs.python.org (Lorin Hochstein)
Date: Wed, 28 Aug 2013 20:59:44 +0000
Subject: [issue18872] platform.linux_distribution() doesn't recognize Amazon
 Linux
Message-ID: <1377723584.12.0.843452970556.issue18872@psf.upfronthosting.co.za>


New submission from Lorin Hochstein:

Amazon EC2 has their own Fedora-like Linux distribution (http://aws.amazon.com/amazon-linux-ami/). This distribution isn't recognized by platform.linux_distribution():

>>> import platform
>>> platform.linux_distribution()
('', '', '')

$ cat /etc/issue
Amazon Linux AMI release 2013.03
Kernel \r on an \m

Tested on Python 2.6.8.

----------
components: Library (Lib)
messages: 196420
nosy: Lorin.Hochstein
priority: normal
severity: normal
status: open
title: platform.linux_distribution() doesn't recognize Amazon Linux
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18872>
_______________________________________

From report at bugs.python.org  Wed Aug 28 23:01:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 21:01:41 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <1375531895.31.0.501848123953.issue18643@psf.upfronthosting.co.za>
Message-ID: <1377723701.98.0.186672988386.issue18643@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

By alternating between PIPE and SOCK, you get POPK, which is as descriptive as it gets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Wed Aug 28 23:09:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 21:09:36 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377724176.73.0.370375250677.issue18851@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Updated patch with test.

----------
Added file: http://bugs.python.org/file31502/subprocess_issue18851_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Wed Aug 28 23:11:40 2013
From: report at bugs.python.org (Lorin Hochstein)
Date: Wed, 28 Aug 2013 21:11:40 +0000
Subject: [issue18872] platform.linux_distribution() doesn't recognize Amazon
 Linux
In-Reply-To: <1377723584.12.0.843452970556.issue18872@psf.upfronthosting.co.za>
Message-ID: <1377724300.96.0.348489731474.issue18872@psf.upfronthosting.co.za>


Lorin Hochstein added the comment:

$ cat /etc/system-release
Amazon Linux AMI release 2013.03

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18872>
_______________________________________

From report at bugs.python.org  Wed Aug 28 23:24:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 21:24:42 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377725082.95.0.0758799697416.issue18850@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Wed Aug 28 23:29:35 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 28 Aug 2013 21:29:35 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <1377723416.46.0.990785965458.issue18643@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3XLDNQ6B=UnaReQrjPUxuONktY=U-Hajr6sqfTyANO1g@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Why not using a different value (constant) for sockets?

We can add a new constant (e.g. SOCK_MAX_SIZE), that would be fine, as
long as it aliases to PIPE_MAX_SIZE.
There's no need to have two values (the current 4MB value is fine).

> By alternating between PIPE and SOCK, you get POPK, which is as descriptive as it gets.

Thank you Antoine :-)

I'll think I'll go for:
SOCK_MAX_SIZE = PIPE_MAX_SIZE = 4MB

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Wed Aug 28 23:32:32 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 28 Aug 2013 21:32:32 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1377695714.01.0.0919932323295.issue7897@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dOA+VSRLQQcTFMdaMZ56h6WoqQYW+hWiHVsr3FnVBdKA@mail.gmail.com>


Nick Coghlan added the comment:

Right, subtests are about improving reporting without adding selectivity.
Explicitly parameterized tests require more structural changes to tests,
but give the selectivity that subtests don't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed Aug 28 23:36:30 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 28 Aug 2013 21:36:30 +0000
Subject: [issue18871] Be more stringent about the test suite
In-Reply-To: <1377720978.63.0.846673837679.issue18871@psf.upfronthosting.co.za>
Message-ID: <CADiSq7ccAHQkcyZOTmO-ADZpwMRc3Q9-SzwjNSRM=8Fd98MsWQ@mail.gmail.com>


Nick Coghlan added the comment:

Looks good to me. I think it's OK to leave the optional resources in the
set of things covered by the buildbots rather than expecting them to always
be run in pre-commit testing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18871>
_______________________________________

From report at bugs.python.org  Wed Aug 28 23:51:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Aug 2013 21:51:47 +0000
Subject: [issue18871] Be more stringent about the test suite
In-Reply-To: <1377718378.43.0.460982109409.issue18871@psf.upfronthosting.co.za>
Message-ID: <3cQLJL5XlmzNHd@mail.python.org>


Roundup Robot added the comment:

New changeset a62bb0481ac9 by Antoine Pitrou in branch 'default':
Issue #18871: make it more explicit that the test suite should be run before committing
http://hg.python.org/devguide/rev/a62bb0481ac9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18871>
_______________________________________

From report at bugs.python.org  Wed Aug 28 23:52:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 21:52:40 +0000
Subject: [issue18871] Be more stringent about the test suite
In-Reply-To: <1377718378.43.0.460982109409.issue18871@psf.upfronthosting.co.za>
Message-ID: <1377726760.44.0.463273787281.issue18871@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks for allowing me to be lazy, Nick :-)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18871>
_______________________________________

From report at bugs.python.org  Wed Aug 28 23:53:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Aug 2013 21:53:22 +0000
Subject: [issue18870] eval() uses latin-1 to decode str
In-Reply-To: <1377713902.12.0.966249722349.issue18870@psf.upfronthosting.co.za>
Message-ID: <1377726802.3.0.972836709525.issue18870@psf.upfronthosting.co.za>


R. David Murray added the comment:

Heh.  Obviously I've forgotten some things about python2.  I could have sworn the default was latin-1, but perhaps that was just the stdlib standard for coding cookies?  I don't use python2 much any more...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18870>
_______________________________________

From report at bugs.python.org  Thu Aug 29 00:12:23 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 28 Aug 2013 22:12:23 +0000
Subject: [issue18871] Be more stringent about the test suite
In-Reply-To: <1377726760.44.0.463273787281.issue18871@psf.upfronthosting.co.za>
Message-ID: <CADiSq7coRj4YFV9j5WB-7ysBoo89f1CNyPxaHPrnshpBSe7mVg@mail.gmail.com>


Nick Coghlan added the comment:

The fact I don't run the tests with - uall before committing had nothing to
do with it whatsoever. Nope. Nothing at all ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18871>
_______________________________________

From report at bugs.python.org  Thu Aug 29 00:25:05 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Aug 2013 22:25:05 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <3cQM2n1MK7z7Lk0@mail.python.org>


Roundup Robot added the comment:

New changeset 17f23cf029cf by Andrew Svetlov in branch 'default':
Fix tests for #11798
http://hg.python.org/cpython/rev/17f23cf029cf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Aug 29 00:46:30 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Aug 2013 22:46:30 +0000
Subject: [issue18870] eval() uses latin-1 to decode str
In-Reply-To: <1377713902.12.0.966249722349.issue18870@psf.upfronthosting.co.za>
Message-ID: <1377729990.72.0.807115924764.issue18870@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Yeah, this is an obnoxious bug. Too late to fix in Python 3, though. I would take a doc patch.

----------
components: +Documentation -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18870>
_______________________________________

From report at bugs.python.org  Thu Aug 29 00:52:48 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 28 Aug 2013 22:52:48 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1377730368.1.0.212253976159.issue11798@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Sorry. Tests are fixed now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Aug 29 01:14:00 2013
From: report at bugs.python.org (paul j3)
Date: Wed, 28 Aug 2013 23:14:00 +0000
Subject: [issue15112] argparse: nargs='*' positional argument doesn't accept
 any items if preceded by an option and another positional
In-Reply-To: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za>
Message-ID: <1377731640.23.0.845238561528.issue15112@psf.upfronthosting.co.za>


paul j3 added the comment:

These three changes end up testing for the same thing. The initial 'if' catches different test cases.  'subparsers' or 'remainder' might 'confuse' the 'O' test.  The zero-width test ends up weeding out everything but the test cases added for this issue.

    # if we haven't hit the end of the command line strings,
    if start_index + sum(arg_counts) != len(arg_strings_pattern):
        while arg_counts and arg_counts[-1] == 0: 
            arg_counts.pop()

    # same test using selected_pattern (= arg_strings_pattern[start_index:])
    if len(selected_pattern) != sum(arg_counts):
        while arg_counts and arg_counts[-1] == 0: 
            arg_counts.pop()

    # alt test: test for optional in the remaining pattern
    if 'O' in selected_pattern:
        while arg_counts and arg_counts[-1] == 0: 
            arg_counts.pop()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15112>
_______________________________________

From report at bugs.python.org  Thu Aug 29 01:50:28 2013
From: report at bugs.python.org (Paul Bonser)
Date: Wed, 28 Aug 2013 23:50:28 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
Message-ID: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>


New submission from Paul Bonser:

lib2to3.pgen2.tokenize:detect_encoding looks for the regex "coding[:=]\s*([-\w.]+)" in the first two lines of the file without first checking if they are comment lines.

You can get 2to3 to fail with "SyntaxError: unknown encoding: 0" with a single line file:

    coding=0

A simple fix would be to check that the line is a comment before trying to look up the encoding from that line.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 196435
nosy: Paul.Bonser
priority: normal
severity: normal
status: open
title: "Encoding" detected in non-comment lines
type: crash
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18873>
_______________________________________

From report at bugs.python.org  Thu Aug 29 01:53:11 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Aug 2013 23:53:11 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
Message-ID: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Thanks to the PEP 445, it becomes possible to trace easily memory allocations. I propose to add a new tracemalloc module computing the memory usage per file and per line number.

I implemented the module as a third party module for Python 2.5-3.4, but it requires to patch and recompile Python:
https://pypi.python.org/pypi/pytracemalloc


My proposed implementation is different:

* use a simple C implementation of an hash table called "cfuhash" (coming from the libcfu project) instead of depending on the glib library ; I simplified and adapted the implementation for my usage

* no enable() / disable() function: tracemalloc can only be enabled before startup by setting PYTHONTRACEMALLOC=1 environment variable

* traces (size of the memory block, Python filename, Python line number) are stored directly in the memory block, not in a separated hash table

I chose PYTHONTRACEMALLOC env var instead of enable()/disable() functions to be able to really trace *all* memory allocated by Python, especially memory allocated at startup, during Python initialization.


TODO:

* The (high-level) API should be reviewed and discussed

* The documention should be improved

* PyMem_Raw API is not hooked yet because the code is not thread-safe (it relies on the Python GIL)

* Filenames should not be encoded: the hash table should directly use Unicode strings (PyObject*), encoding a filename allocates memory and may call the garbage collector

* Memory is not released at exit


For the documentation, see the following page:
https://pypi.python.org/pypi/pytracemalloc


See also the https://bitbucket.org/haypo/pyfailmalloc project and the issue #18408.

----------
hgrepos: 206
messages: 196436
nosy: haypo
priority: normal
severity: normal
status: open
title: Add a new tracemalloc module to trace memory allocations
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18874>
_______________________________________

From report at bugs.python.org  Thu Aug 29 02:07:26 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Aug 2013 00:07:26 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1377734846.28.0.309793481784.issue18874@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Example of output:


$ PYTHONTRACEMALLOC=1 ./python -m test
...
== CPython 3.4.0a1+ (default:2ce9e5f6b47c+, Aug 29 2013, 02:03:02) [GCC 4.7.2 20121109 (Red Hat 4.7.2-8)]
==   Linux-3.9.4-200.fc18.x86_64-x86_64-with-fedora-18-Spherical_Cow little-endian
==   /home/haypo/prog/python/tracemalloc/build/test_python_11087
...
[  1/380] test_grammar
[  2/380] test_opcodes
[  3/380] test_dict
[  4/380] test_builtin
[  5/380] test_exceptions
[  6/380] test_types
[  7/380] test_unittest

2013-08-29 02:06:22: Top 25 allocations per file and line
#1: <frozen importlib._bootstrap>:704: size=5 MiB, count=56227, average=105 B
#2: .../tracemalloc/Lib/linecache.py:127: size=1004 KiB, count=8706, average=118 B
#3: .../Lib/unittest/mock.py:1764: size=895 KiB, count=7841, average=116 B
#4: .../Lib/unittest/mock.py:1805: size=817 KiB, count=15101, average=55 B
#5: .../Lib/test/test_dict.py:35: size=768 KiB, count=8, average=96 KiB
#6: <frozen importlib._bootstrap>:274: size=703 KiB, count=4604, average=156 B
#7: ???:?: size=511 KiB, count=4445, average=117 B
#8: .../Lib/unittest/mock.py:350: size=370 KiB, count=1227, average=308 B
#9: .../Lib/unittest/case.py:306: size=343 KiB, count=1390, average=253 B
#10: .../Lib/unittest/case.py:496: size=330 KiB, count=650, average=521 B
#11: .../Lib/unittest/case.py:327: size=291 KiB, count=717, average=416 B
#12: .../Lib/collections/__init__.py:368: size=239 KiB, count=2170, average=113 B
#13: .../Lib/test/test_grammar.py:132: size=195 KiB, count=1250, average=159 B
#14: .../Lib/unittest/mock.py:379: size=118 KiB, count=152, average=800 B
#15: .../tracemalloc/Lib/contextlib.py:37: size=102 KiB, count=672, average=156 B
#16: <frozen importlib._bootstrap>:1430: size=91 KiB, count=1193, average=78 B
#17: .../tracemalloc/Lib/inspect.py:1399: size=79 KiB, count=104, average=784 B
#18: .../tracemalloc/Lib/abc.py:133: size=77 KiB, count=275, average=289 B
#19: .../Lib/unittest/case.py:43: size=73 KiB, count=593, average=127 B
#20: .../Lib/unittest/mock.py:491: size=67 KiB, count=153, average=450 B
#21: <frozen importlib._bootstrap>:1438: size=64 KiB, count=20, average=3321 B
#22: .../Lib/unittest/case.py:535: size=56 KiB, count=76, average=766 B
#23: .../tracemalloc/Lib/sre_compile.py:508: size=54 KiB, count=115, average=485 B
#24: .../Lib/unittest/case.py:300: size=48 KiB, count=616, average=80 B
#25: .../Lib/test/regrtest.py:1207: size=48 KiB, count=2, average=24 KiB
7333 more: size=4991 KiB, count=28051, average=182 B
Total Python memory: size=17 MiB, count=136358, average=136 B
Total process memory: size=42 MiB (ignore tracemalloc: 22 KiB)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18874>
_______________________________________

From report at bugs.python.org  Thu Aug 29 02:18:37 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Aug 2013 00:18:37 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1377735517.3.0.833976884839.issue18874@psf.upfronthosting.co.za>


STINNER Victor added the comment:

tracemalloc.get_process_memory() should be moved to the shutil module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18874>
_______________________________________

From report at bugs.python.org  Thu Aug 29 02:57:58 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Aug 2013 00:57:58 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1377737878.67.0.991801048271.issue18874@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm not sure that the DisplayGarbage class is still useful. The PEP 442 has been implemented in Python 3.4, so objects with __del__() method are no more "uncollectable". I don't know which kind of objects can enter the gc.garbage list (by default, not using gc.set_debug(gc.DEBUG_SAVEALL)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18874>
_______________________________________

From report at bugs.python.org  Thu Aug 29 02:59:38 2013
From: report at bugs.python.org (Lorin Hochstein)
Date: Thu, 29 Aug 2013 00:59:38 +0000
Subject: [issue18872] platform.linux_distribution() doesn't recognize Amazon
 Linux
In-Reply-To: <1377723584.12.0.843452970556.issue18872@psf.upfronthosting.co.za>
Message-ID: <1377737978.02.0.177981191068.issue18872@psf.upfronthosting.co.za>


Lorin Hochstein added the comment:

Adding 'system' as one of the supported distros does the trick.

>>> platform.linux_distribution(supported_dists=['system'])
('Amazon Linux AMI', '2013.03', '')

Simple patch attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file31503/amazon-linux.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18872>
_______________________________________

From report at bugs.python.org  Thu Aug 29 05:25:01 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 29 Aug 2013 03:25:01 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377746701.93.0.201619299154.issue18850@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Is that you actual use case? That you *want* to store binary data in XML, instead of getting it properly rejected as non well-formed content?

Then I suggest going the canonical route of passing it through base64 first, or any of the other binary-to-characters encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Thu Aug 29 06:19:08 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 29 Aug 2013 04:19:08 +0000
Subject: [issue18760] Fix internal doc references for the xml package
In-Reply-To: <1376681899.06.0.47911099673.issue18760@psf.upfronthosting.co.za>
Message-ID: <1377749948.36.0.433653086961.issue18760@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

lgtm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18760>
_______________________________________

From report at bugs.python.org  Thu Aug 29 09:13:01 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 29 Aug 2013 07:13:01 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377760381.74.0.451764700718.issue18851@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

fyi - i am unable to reproduce this when using subprocess32 instead of subprocess.  https://pypi.python.org/pypi/subprocess32

That is what i recommend _anyone_ using Python 2.x use instead.

Regardless if this was reintroduced in 2.7.5 we need to re-fix it.

i haven't tested 3.2 or 3.3 or default yet (given the backport isn't showing the problem i'm hoping they don't either but they need testing).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Thu Aug 29 09:17:50 2013
From: report at bugs.python.org (Phil Connell)
Date: Thu, 29 Aug 2013 07:17:50 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
 locals and globals when they are not wanted
Message-ID: <1377760670.84.0.457546104631.issue1565525@psf.upfronthosting.co.za>


Changes by Phil Connell <pconnell at gmail.com>:


----------
nosy: +pconnell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Thu Aug 29 09:36:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Aug 2013 07:36:12 +0000
Subject: [issue18760] Fix internal doc references for the xml package
In-Reply-To: <1376681899.06.0.47911099673.issue18760@psf.upfronthosting.co.za>
Message-ID: <3cQbGg20SCz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset a426e5c03d6e by Serhiy Storchaka in branch '3.3':
Issue #18760: Improved cross-references in the xml package.
http://hg.python.org/cpython/rev/a426e5c03d6e

New changeset 32b59d122989 by Serhiy Storchaka in branch 'default':
Issue #18760: Improved cross-references in the xml package.
http://hg.python.org/cpython/rev/32b59d122989

New changeset 9c66b9cb886b by Serhiy Storchaka in branch '2.7':
Issue #18760: Improved cross-references in the xml package.
http://hg.python.org/cpython/rev/9c66b9cb886b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18760>
_______________________________________

From report at bugs.python.org  Thu Aug 29 09:36:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 07:36:22 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <1377761782.4.0.853807318883.issue18873@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +easy
nosy: +benjamin.peterson
stage:  -> needs patch
type: crash -> behavior
versions: +Python 3.4 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18873>
_______________________________________

From report at bugs.python.org  Thu Aug 29 09:51:31 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 29 Aug 2013 07:51:31 +0000
Subject: [issue18869] test suite: faulthandler signal handler is lost
In-Reply-To: <1377707093.4.0.0816466324955.issue18869@psf.upfronthosting.co.za>
Message-ID: <1377762691.29.0.181295100171.issue18869@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18869>
_______________________________________

From report at bugs.python.org  Thu Aug 29 09:54:59 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 07:54:59 +0000
Subject: [issue18760] Fix internal doc references for the xml package
In-Reply-To: <1376681899.06.0.47911099673.issue18760@psf.upfronthosting.co.za>
Message-ID: <1377762899.54.0.852982993741.issue18760@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18760>
_______________________________________

From report at bugs.python.org  Thu Aug 29 10:46:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Aug 2013 08:46:57 +0000
Subject: [issue18743] References to non-existant "StringIO" module
In-Reply-To: <1376542911.78.0.658455842148.issue18743@psf.upfronthosting.co.za>
Message-ID: <3cQcrJ3GR3z7Lk0@mail.python.org>


Roundup Robot added the comment:

New changeset 6c0f5af2f5a5 by Serhiy Storchaka in branch '3.3':
Issue #18743: Fix references to non-existant "StringIO" module
http://hg.python.org/cpython/rev/6c0f5af2f5a5

New changeset 676bbd5b0254 by Serhiy Storchaka in branch 'default':
Issue #18743: Fix references to non-existant "StringIO" module
http://hg.python.org/cpython/rev/676bbd5b0254

New changeset 8c768bbacd92 by Serhiy Storchaka in branch '2.7':
Issue #18743: Improved cross-references to the StringIO class.
http://hg.python.org/cpython/rev/8c768bbacd92

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18743>
_______________________________________

From report at bugs.python.org  Thu Aug 29 10:48:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 08:48:46 +0000
Subject: [issue18743] References to non-existant "StringIO" module
In-Reply-To: <1376542911.78.0.658455842148.issue18743@psf.upfronthosting.co.za>
Message-ID: <1377766126.85.0.968224929263.issue18743@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18743>
_______________________________________

From report at bugs.python.org  Thu Aug 29 10:50:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 08:50:02 +0000
Subject: [issue18758] Fix internal references in the documentation
In-Reply-To: <1376678338.7.0.979265810368.issue18758@psf.upfronthosting.co.za>
Message-ID: <1377766202.7.0.254851791962.issue18758@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: docs at python -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18758>
_______________________________________

From report at bugs.python.org  Thu Aug 29 11:01:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Aug 2013 09:01:17 +0000
Subject: [issue17974] Migrate unittest to argparse
In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za>
Message-ID: <1377766877.59.0.0383388288708.issue17974@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think this should be committed. This is the first step in making command-line args easily customizable (e.g. by exposing the parsers as a public API in TestProgram).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17974>
_______________________________________

From report at bugs.python.org  Thu Aug 29 11:04:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Aug 2013 09:04:33 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377767073.49.0.502535571682.issue18851@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Gregory, it seems fixed indeed under Unix but I'm not sure about Windows. Read what I wrote above: apparently the cleanup code calls os.close() on a Windows HANDLE; then conveniently it swallows the exception :-)

Also, the Windows version of _execute_child doesn't set _closed_child_pipe_fds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Thu Aug 29 11:04:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Aug 2013 09:04:54 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377767094.1.0.623864740681.issue18851@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(in any case, the test is probably worth adding)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Thu Aug 29 11:27:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Aug 2013 09:27:12 +0000
Subject: [issue16799] start using argparse.Namespace in regrtest
In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za>
Message-ID: <3cQdkl48p1z7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 997de0edc5bd by Serhiy Storchaka in branch 'default':
Issue #16799: Switched from getopt to argparse style in regrtest's argument
http://hg.python.org/cpython/rev/997de0edc5bd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16799>
_______________________________________

From report at bugs.python.org  Thu Aug 29 11:34:06 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 29 Aug 2013 09:34:06 +0000
Subject: [issue18806] socketmodule: fix/improve setipaddr() numeric addresses
 handling
In-Reply-To: <1377150255.36.0.551541174341.issue18806@psf.upfronthosting.co.za>
Message-ID: <1377768846.22.0.410234636678.issue18806@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> socket.gethostbyname incorrectly parses ip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18806>
_______________________________________

From report at bugs.python.org  Thu Aug 29 11:34:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 09:34:43 +0000
Subject: [issue16799] start using argparse.Namespace in regrtest
In-Reply-To: <1356664271.75.0.0861175623583.issue16799@psf.upfronthosting.co.za>
Message-ID: <1377768883.24.0.984216263093.issue16799@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16799>
_______________________________________

From report at bugs.python.org  Thu Aug 29 11:38:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Aug 2013 09:38:30 +0000
Subject: [issue17974] Migrate unittest to argparse
In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za>
Message-ID: <3cQdzp0Kwsz7Ljp@mail.python.org>


Roundup Robot added the comment:

New changeset 340f45374cf5 by Serhiy Storchaka in branch 'default':
Issue #17974: Switch unittest from using getopt to using argparse.
http://hg.python.org/cpython/rev/340f45374cf5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17974>
_______________________________________

From report at bugs.python.org  Thu Aug 29 11:39:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 09:39:50 +0000
Subject: [issue17974] Migrate unittest to argparse
In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za>
Message-ID: <1377769190.57.0.770381729703.issue17974@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17974>
_______________________________________

From report at bugs.python.org  Thu Aug 29 12:07:44 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 29 Aug 2013 10:07:44 +0000
Subject: [issue16201] socket.gethostbyname incorrectly parses ip
In-Reply-To: <1349983863.01.0.255097510924.issue16201@psf.upfronthosting.co.za>
Message-ID: <1377770864.76.0.573171280218.issue16201@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Stupid question: why use scanf()/strtol() to parse an IP address, and not simply inet_pton()/inet_aton(), which are made precisely for that purpose?
inet_pton() is POSIX (it was introduced at the same time as getaddrinfo(), which is used unconditionally a couple lines below). If it's not available, we could use inet_aton() as fallback (which is amusingly not POSIX, but I doubt we'll find a platform with neither inet_pton() nor inet_aton()).

Using inet_pton() would have the added advantage of working with IPv6 addresses: right now, a numeric IPv6 address is always resolved by getaddrinfo(), which results in a performance overhead:

$ python -m timeit -s "from socket import *; s = socket(AF_INET, SOCK_DGRAM); DATA = 'hello'" "s.sendto(DATA, ('127.0.0.1', 42))"
100000 loops, best of 3: 6.86 usec per loop
$ python -m timeit -s "from socket import *; s = socket(AF_INET6, SOCK_DGRAM); DATA = 'hello'" "s.sendto(DATA, ('::1', 42))"
10000 loops, best of 3: 24.2 usec per loop

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16201>
_______________________________________

From report at bugs.python.org  Thu Aug 29 12:09:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 10:09:24 +0000
Subject: [issue18830] Remove duplicates from a result of getclasstree()
In-Reply-To: <1377442213.69.0.00603799982208.issue18830@psf.upfronthosting.co.za>
Message-ID: <1377770964.52.0.348332644418.issue18830@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch with additional test.

----------
Added file: http://bugs.python.org/file31504/getclasstree_no_dups_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18830>
_______________________________________

From report at bugs.python.org  Thu Aug 29 12:11:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 10:11:56 +0000
Subject: [issue18672] Fix format specifiers for debug output in _sre.c
In-Reply-To: <1375805518.91.0.887667887132.issue18672@psf.upfronthosting.co.za>
Message-ID: <1377771116.42.0.348006134743.issue18672@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18672>
_______________________________________

From report at bugs.python.org  Thu Aug 29 12:12:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 10:12:28 +0000
Subject: [issue18672] Fix format specifiers for debug output in _sre.c
In-Reply-To: <1375805518.91.0.887667887132.issue18672@psf.upfronthosting.co.za>
Message-ID: <1377771148.68.0.0205783325959.issue18672@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18672>
_______________________________________

From report at bugs.python.org  Thu Aug 29 12:12:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 10:12:38 +0000
Subject: [issue18684] Pointers point out of array bound in _sre.c
In-Reply-To: <1375962984.07.0.918202360038.issue18684@psf.upfronthosting.co.za>
Message-ID: <1377771158.39.0.547343472049.issue18684@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18684>
_______________________________________

From report at bugs.python.org  Thu Aug 29 12:12:56 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 29 Aug 2013 10:12:56 +0000
Subject: [issue16201] socket.gethostbyname incorrectly parses ip
In-Reply-To: <1377770864.76.0.573171280218.issue16201@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2c2iLOVKOUQk-37j4XfibomJhy7muj-eUQ9t0G-AEDig@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Note that for IPv6 addresses, we should just extract manually the
scope ID ('%' prefix) if present.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16201>
_______________________________________

From report at bugs.python.org  Thu Aug 29 12:13:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 10:13:50 +0000
Subject: [issue18685] Restore re performance to pre-PEP393 level
In-Reply-To: <1375967417.95.0.0303828296889.issue18685@psf.upfronthosting.co.za>
Message-ID: <1377771230.2.0.998526638066.issue18685@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Fix format specifiers for debug output in _sre.c, Pointers point out of array bound in _sre.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18685>
_______________________________________

From report at bugs.python.org  Thu Aug 29 12:57:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 10:57:16 +0000
Subject: [issue13107] Text width in optparse.py can become negative
In-Reply-To: <1317812903.38.0.572106699519.issue13107@psf.upfronthosting.co.za>
Message-ID: <1377773836.56.0.755362850917.issue13107@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, argparse has same problem.

>>> import os, argparse
>>> p = argparse.ArgumentParser(prog='PROG')
>>> os.environ['COLUMNS'] = '16'
>>> print(p.format_help())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/argparse.py", line 2329, in format_help
    return formatter.format_help()
  File "/home/serhiy/py/cpython/Lib/argparse.py", line 276, in format_help
    help = self._root_section.format_help()
  File "/home/serhiy/py/cpython/Lib/argparse.py", line 206, in format_help
    func(*args)
  File "/home/serhiy/py/cpython/Lib/argparse.py", line 206, in format_help
    func(*args)
  File "/home/serhiy/py/cpython/Lib/argparse.py", line 514, in _format_action
    help_lines = self._split_lines(help_text, help_width)
  File "/home/serhiy/py/cpython/Lib/argparse.py", line 614, in _split_lines
    return _textwrap.wrap(text, width)
  File "/home/serhiy/py/cpython/Lib/textwrap.py", line 355, in wrap
    return w.wrap(text)
  File "/home/serhiy/py/cpython/Lib/textwrap.py", line 300, in wrap
    return self._wrap_chunks(chunks)
  File "/home/serhiy/py/cpython/Lib/textwrap.py", line 227, in _wrap_chunks
    raise ValueError("invalid width %r (must be > 0)" % self.width)
ValueError: invalid width 0 (must be > 0)

----------
assignee: serhiy.storchaka -> 
versions: +Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13107>
_______________________________________

From report at bugs.python.org  Thu Aug 29 13:58:18 2013
From: report at bugs.python.org (irdb)
Date: Thu, 29 Aug 2013 11:58:18 +0000
Subject: [issue18875] Automatic insertion of the closing parentheses, brackets,
 and braces
Message-ID: <1377777498.6.0.468253349222.issue18875@psf.upfronthosting.co.za>


New submission from irdb:

Many other IDE's have this feature that allows automatic insertion of closing parentheses as user is typing something. I think it saves time and increases programming speed. Is it possible to have this on IDLE, too?

----------
components: IDLE
messages: 196456
nosy: irdb
priority: normal
severity: normal
status: open
title: Automatic insertion of the closing parentheses, brackets, and braces
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18875>
_______________________________________

From report at bugs.python.org  Thu Aug 29 14:33:58 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Aug 2013 12:33:58 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <3cQjtF4Ct3z7LjY@mail.python.org>


Roundup Robot added the comment:

New changeset f6c7ad7d029a by Richard Oudkerk in branch 'default':
Issue #8713: Test should not print message about start method.
http://hg.python.org/cpython/rev/f6c7ad7d029a

New changeset e99832a60e63 by Richard Oudkerk in branch 'default':
Issue #8713: Cleanup before saving process._dangling.
http://hg.python.org/cpython/rev/e99832a60e63

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Thu Aug 29 15:02:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Aug 2013 13:02:54 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377781374.42.0.983605921221.issue18808@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Thu Aug 29 15:38:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Aug 2013 13:38:46 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <3cQlK13lXMz7LjY@mail.python.org>


Roundup Robot added the comment:

New changeset 6d998a43102b by Richard Oudkerk in branch 'default':
Issue #8713: Print dangling processes/threads, if any.
http://hg.python.org/cpython/rev/6d998a43102b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Thu Aug 29 15:47:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 13:47:48 +0000
Subject: [issue16510] Using appropriate checks in tests
In-Reply-To: <1353321858.76.0.504726837876.issue16510@psf.upfronthosting.co.za>
Message-ID: <1377784068.14.0.49394264563.issue16510@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Patch updated to sync with tip. It is 5% less than first version because some changes already applied in other commits.

----------
Added file: http://bugs.python.org/file31505/tests_asserts_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16510>
_______________________________________

From report at bugs.python.org  Thu Aug 29 16:13:59 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 29 Aug 2013 14:13:59 +0000
Subject: [issue16201] socket.gethostbyname incorrectly parses ip
In-Reply-To: <CAH_1eM2c2iLOVKOUQk-37j4XfibomJhy7muj-eUQ9t0G-AEDig@mail.gmail.com>
Message-ID: <CAH_1eM37KJ7JuFaiN-xYxLiAjiNR2+H1QBz2kbDyN69pK=FvjQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Here's a patch using inet_pton() if available, otherwise inet_aton()
if available, otherwise fallback to getaddrinfo().
This should work on every platform, but if a platform has neither
inet_pton() nor inet_aton(), calling getaddrinfo() will incur an
overhead.
All Unices have either inet_aton() or inet_pton().
For Windows >= Vista, inet_pton() is available.
I'm not sure whether XP has one of them: if not, then we might keep
the hand-parsing as a fallback.

This adds support for numeric IPv6 addresses (if inet_pton() is
available), which notably speeds up sendto() on IPv6 sockets, and
gives a tiny speedup for IPv4 sockets:
before:
$ ./python -m timeit -s "import socket; s =
socket.socket(socket.AF_INET, socket.SOCK_DGRAM); DATA = b'x'"
"s.sendto(DATA, ('127.0.0.1', 4242))"
100000 loops, best of 3: 13.2 usec per loop
$ ./python -m timeit -s "import socket; s =
socket.socket(socket.AF_INET6, socket.SOCK_DGRAM); DATA = b'x'"
"s.sendto(DATA, ('::1', 4242))"
10000 loops, best of 3: 32.1 usec per loop
after:
$ ./python -m timeit -s "import socket; s =
socket.socket(socket.AF_INET, socket.SOCK_DGRAM); DATA = b'x'"
"s.sendto(DATA, ('127.0.0.1', 4242))"
100000 loops, best of 3: 11.5 usec per loop
$ ./python -m timeit -s "import socket; s =
socket.socket(socket.AF_INET6, socket.SOCK_DGRAM); DATA = b'x'"
"s.sendto(DATA, ('::1', 4242))"
100000 loops, best of 3: 12.8 usec per loop

Note that if the IPv6 address contains a scope ID ('%' suffix), then
we fallback to getaddrinfo() which handles it properly (the scope ID
can be an interface index but also an interface name).

----------
Added file: http://bugs.python.org/file31506/parse_inet.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16201>
_______________________________________
-------------- next part --------------
diff -r 4b3238923b01 Lib/test/test_socket.py
--- a/Lib/test/test_socket.py	Fri May 10 19:57:44 2013 -0700
+++ b/Lib/test/test_socket.py	Thu Aug 29 16:10:40 2013 +0200
@@ -761,6 +761,31 @@
         if not fqhn in all_host_names:
             self.fail("Error testing host resolution mechanisms. (fqdn: %s, all: %s)" % (fqhn, repr(all_host_names)))
 
+    def test_hosts_resolution(self):
+        valid_hosts = [support.HOST]
+        valid_hosts_ipv6 = [support.HOSTv6]
+
+        invalid_hosts = ['0.1.1.1.', 'a1.1.1.1', '10.1a.1.1',
+                         '4294967306.4294967296.4294967296.1']
+        invalid_hosts_ipv6 = ['::1q', '::1::2', '1:1:1:1:1:1:1:1:1']
+
+        for host in valid_hosts:
+            self.assertEqual(socket.gethostbyname(host), host)
+
+        for host in invalid_hosts:
+            self.assertRaises(OSError, socket.gethostbyname, host)
+
+        # gethostbyaddr() support IPv6, contrarily to gethosbyname()
+        if support.IPV6_ENABLED:
+            valid_hosts.extend(valid_hosts_ipv6)
+            invalid_hosts.extend(invalid_hosts_ipv6)
+
+        for host in valid_hosts:
+            self.assertIn(host, socket.gethostbyaddr(host)[2])
+
+        for host in invalid_hosts:
+            self.assertRaises(OSError, socket.gethostbyaddr, host)
+
     @unittest.skipUnless(hasattr(socket, 'sethostname'), "test needs socket.sethostname()")
     @unittest.skipUnless(hasattr(socket, 'gethostname'), "test needs socket.gethostname()")
     def test_sethostname(self):
diff -r 4b3238923b01 Modules/socketmodule.c
--- a/Modules/socketmodule.c	Fri May 10 19:57:44 2013 -0700
+++ b/Modules/socketmodule.c	Thu Aug 29 16:10:40 2013 +0200
@@ -799,8 +799,6 @@
 {
     struct addrinfo hints, *res;
     int error;
-    int d1, d2, d3, d4;
-    char ch;
 
     memset((void *) addr_ret, '\0', sizeof(*addr_ret));
     if (name[0] == '\0') {
@@ -865,20 +863,49 @@
         sin->sin_addr.s_addr = INADDR_BROADCAST;
         return sizeof(sin->sin_addr);
     }
-    if (sscanf(name, "%d.%d.%d.%d%c", &d1, &d2, &d3, &d4, &ch) == 4 &&
-        0 <= d1 && d1 <= 255 && 0 <= d2 && d2 <= 255 &&
-        0 <= d3 && d3 <= 255 && 0 <= d4 && d4 <= 255) {
-        struct sockaddr_in *sin;
-        sin = (struct sockaddr_in *)addr_ret;
-        sin->sin_addr.s_addr = htonl(
-            ((long) d1 << 24) | ((long) d2 << 16) |
-            ((long) d3 << 8) | ((long) d4 << 0));
-        sin->sin_family = AF_INET;
+    /* avoid a name resolution in case of numeric address */
+#ifdef HAVE_INET_PTON
+    /* check for an IPv4 address */
+    if (af == AF_UNSPEC || af == AF_INET) {
+        struct sockaddr_in *sin = (struct sockaddr_in *)addr_ret;
+        if (inet_pton(AF_INET, name, &sin->sin_addr) > 0) {
+            sin->sin_family = AF_INET;
 #ifdef HAVE_SOCKADDR_SA_LEN
-        sin->sin_len = sizeof(*sin);
-#endif
-        return 4;
-    }
+            sin->sin_len = sizeof(*sin);
+#endif
+            return 4;
+        }
+    }
+#ifdef ENABLE_IPV6
+    /* check for an IPv6 address - if the address contains a scope ID, we
+     * fallback to getaddrinfo(), which can handle translation from interface
+     * name to interface index */
+    if ((af == AF_UNSPEC || af == AF_INET6) && !strchr(name, '%')) {
+        struct sockaddr_in6 *sin = (struct sockaddr_in6 *)addr_ret;
+        if (inet_pton(AF_INET6, name, &sin->sin6_addr) > 0) {
+            sin->sin6_family = AF_INET6;
+#ifdef HAVE_SOCKADDR_SA_LEN
+            sin->sin6_len = sizeof(*sin);
+#endif
+            return 16;
+        }
+    }
+#endif /* ENABLE_IPV6 */
+#elif defined(HAVE_INET_ATON)
+    /* check for an IPv4 address */
+     if (af == AF_INET || af == AF_UNSPEC) {
+        struct sockaddr_in *sin = (struct sockaddr_in *)addr_ret;
+        if (inet_aton(name, &sin->sin_addr) > 0) {
+            sin->sin_family = AF_INET;
+#ifdef HAVE_SOCKADDR_SA_LEN
+            sin->sin_len = sizeof(*sin);
+#endif
+            return 4;
+        }
+    }   
+#endif /* HAVE_INET_PTON */
+
+    /* perform a name resolution */
     memset(&hints, 0, sizeof(hints));
     hints.ai_family = af;
     Py_BEGIN_ALLOW_THREADS

From report at bugs.python.org  Thu Aug 29 17:23:05 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 29 Aug 2013 15:23:05 +0000
Subject: [issue14597] Cannot unload dll in ctypes until script exits
In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za>
Message-ID: <1377789785.45.0.355415883147.issue14597@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Did you consider creating a copy with a random suffix?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14597>
_______________________________________

From report at bugs.python.org  Thu Aug 29 17:30:38 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 29 Aug 2013 15:30:38 +0000
Subject: [issue16201] socket.gethostbyname incorrectly parses ip
In-Reply-To: <1349983863.01.0.255097510924.issue16201@psf.upfronthosting.co.za>
Message-ID: <1377790238.08.0.750442196424.issue16201@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

> For Windows >= Vista, inet_pton() is available.
> I'm not sure whether XP has one of them: if not, then we might keep
> the hand-parsing as a fallback.

Apparently, XP doesn't have inet_aton()...

So I changed the code to use inet_pton() if available, otherwise use inet_addr(), which is available everywhere (the only gotcha is that it doesn't handle "255.255.255.255", so we special-case it like "<broadcast>").

We thus get rid of the hand-parsing completely, and get a more efficient  handling of numeric IPv4 addresses, and a much more efficient handling for numeric IPv6 addresses (see above benchmarks).

----------
keywords: +needs review
stage:  -> patch review
Added file: http://bugs.python.org/file31507/parse_inet.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16201>
_______________________________________

From report at bugs.python.org  Thu Aug 29 17:30:45 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 29 Aug 2013 15:30:45 +0000
Subject: [issue16201] socket.gethostbyname incorrectly parses ip
In-Reply-To: <1349983863.01.0.255097510924.issue16201@psf.upfronthosting.co.za>
Message-ID: <1377790245.66.0.936785436875.issue16201@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


Removed file: http://bugs.python.org/file31506/parse_inet.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16201>
_______________________________________

From report at bugs.python.org  Thu Aug 29 19:04:18 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 29 Aug 2013 17:04:18 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377795858.72.0.494232462087.issue18851@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Rietveld's choking on git diffs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Thu Aug 29 19:07:33 2013
From: report at bugs.python.org (Erik Bray)
Date: Thu, 29 Aug 2013 17:07:33 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
Message-ID: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>


New submission from Erik Bray:

I've come across a few difficulties of late with the io module's handling of files opened in append mode (any variation on 'a', 'ab', 'a+', 'ab+', etc.

The biggest problem is that the io module does not in any way keep track of whether a file was opened in append mode, and it's essentially impossible to determine the original mode string that was provided by the user.  For example:

>>> f = open('test', mode='ab+', buffering=0)
>>> f
<_io.FileIO name='test' mode='rb+'>

The 'a' is gone.  That doesn't mean the file *isn't* in append mode.  If supported, in fileio_init this still causes the O_APPEND flag to be added to the open() call.  But the *only* way to find out after the fact that the file  was actually opened in append mode is with fcntl:

>>> fcntl.fcntl(f.fileno(), fnctl.F_GETFL) & os.O_APPEND
1024

but this is hardly easily accessible or portable.  So it's possible to have two files open in 'rb+' mode but that have wildly differing behaviors.

The only other thing fileio_init does differently with append mode is that it seeks to the end of the file by default.  But that does not make the append behavior "portable".  If, on a system where O_APPEND was not supported, I seek to a different part of the file and the call write() it will *not* append to the end of the file.  Whereas the behavior of O_APPEND causes an automatic seek to the end before any write().

The fact that no record of the request for 'append' mode is kept leads to further bugs, particularly in BufferedWriter.  It doesn't know the raw file was opened with O_APPEND so the writes it shows in the buffer differ from what will actually end up in the file.  For example:

>>> f = open('test', 'wb')
>>> f.write(b'testest')
7
>>> f.close()
>>> f = open('test', 'ab+')
>>> f.tell()
7
>>> f.write(b'A')
1
>>> f.seek(0)
0
>>> f.read()
b'testestA'
>>> f.seek(0)
0
>>> f.read(1)
b't'
>>> f.write(b'B')
1
>>> f.seek(0)
0
>>> f.read()
b'tBstestA'
>>> f.flush()
>>> f.seek(0)
0
>>> f.read()
b'testestAB'

In this example, I read 1 byte from the beginning of the file, then write one byte.  Because of O_APPEND, the effect of the write() call on the raw file is to append, regardless of where BufferedWriter seeks it to first.  But before the f.flush() call f.read() just shows what's in the buffer which is not what will actually be written to the file.  (Naturally, unbuffered io does not have this particular problem.)

So, I'm thinking maybe the fileio struct needs to grow an 'append' member.  This could be used to provide a more accurate mode string, and could for example in fileio_write to provide append-like support where it isn't natively supported (though perhaps without any guarantees as to atomicity).

----------
components: IO
messages: 196464
nosy: erik.bray
priority: normal
severity: normal
status: open
title: Problems with files opened in append mode with io module
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18876>
_______________________________________

From report at bugs.python.org  Thu Aug 29 19:13:31 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Thu, 29 Aug 2013 17:13:31 +0000
Subject: [issue16201] socket.gethostbyname incorrectly parses ip
In-Reply-To: <1349983863.01.0.255097510924.issue16201@psf.upfronthosting.co.za>
Message-ID: <1377796411.42.0.375701608516.issue16201@psf.upfronthosting.co.za>


Michele Orr? added the comment:

Cool, thanks for pointing the correct library function. 

Tested on my machine - Debian 3.9 x86_64 GNU/Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16201>
_______________________________________

From report at bugs.python.org  Thu Aug 29 19:14:30 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Aug 2013 17:14:30 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>
Message-ID: <1377796470.62.0.269541185119.issue18876@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +pitrou
versions: +Python 3.4 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18876>
_______________________________________

From report at bugs.python.org  Thu Aug 29 19:18:21 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Aug 2013 17:18:21 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>
Message-ID: <1377796701.32.0.913646578549.issue18876@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hi, Erik.  I changed the versions because we use versions in this tracker to indicate which versions we intend to *fix* the problem in.  I left 2.7 and 3.3 marked for the moment, but I have a feeling that this will need to be a feature-release-only change.  Not only does it require a new attribute, it also changes the semantics (albeit in a sensible way), and as such could break working code if applied to a maintenance release.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18876>
_______________________________________

From report at bugs.python.org  Thu Aug 29 19:27:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Aug 2013 17:27:34 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <1375531895.31.0.501848123953.issue18643@psf.upfronthosting.co.za>
Message-ID: <3cQrP131b1z7Ll3@mail.python.org>


Roundup Robot added the comment:

New changeset 2de7fc69d2d4 by Charles-Fran?ois Natali in branch '2.7':
Issue #18643: Fix some test_socket failures due to large default socket buffer
http://hg.python.org/cpython/rev/2de7fc69d2d4

New changeset 498957c97c2b by Charles-Fran?ois Natali in branch '3.3':
Issue #18643: Fix some test_socket failures due to large default socket buffer
http://hg.python.org/cpython/rev/498957c97c2b

New changeset 9b27cf72c79b by Charles-Fran?ois Natali in branch 'default':
Issue #18643: Fix some test_socket failures due to large default socket buffer
http://hg.python.org/cpython/rev/9b27cf72c79b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Thu Aug 29 19:29:53 2013
From: report at bugs.python.org (Erik Bray)
Date: Thu, 29 Aug 2013 17:29:53 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>
Message-ID: <1377797393.62.0.230701796434.issue18876@psf.upfronthosting.co.za>


Erik Bray added the comment:

Ah right, sorry about that. I just came over from the Trac site for one of my projects where the version field is used for affected versions :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18876>
_______________________________________

From report at bugs.python.org  Thu Aug 29 19:49:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Aug 2013 17:49:46 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>
Message-ID: <1377798586.43.0.0808078175897.issue18876@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

On which systems is O_APPEND not supported? It's part of the POSIX standard, and even Windows seems to have it.

> Whereas the behavior of O_APPEND causes an automatic seek to the end
> before any write().

True, but IIRC some systems seek on open() and some systems seek just before write().

Agreed about the "mode" attribute problem, though. And the BufferedWriter bug is truly embarassing, sorry :-(

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18876>
_______________________________________

From report at bugs.python.org  Thu Aug 29 19:51:41 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 29 Aug 2013 17:51:41 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1377798701.32.0.288619934409.issue8713@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> I've seen test_multiprocessing_forkserver giving warnings too, while 
> running the whole test suite, but can't reproduce them while running it 
> alone.  The warnings seems quite similar though, so a single fix might 
> resolve the problem with all the tests.

> The "Using start method '...'" should also be displayed only when the 
> tests are run in verbose mode.

Seems to be fixed now.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Thu Aug 29 19:53:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Aug 2013 17:53:18 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377798798.86.0.029697557585.issue18851@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ha, sorry. Here is a non-git patch.

----------
Added file: http://bugs.python.org/file31508/subprocess_issue18851_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Thu Aug 29 19:56:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Aug 2013 17:56:00 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377798960.21.0.156855636455.issue18851@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file31508/subprocess_issue18851_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Thu Aug 29 19:56:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Aug 2013 17:56:23 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377798983.21.0.861493051378.issue18851@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Sorry, wrong patch. Uploading again.

----------
Added file: http://bugs.python.org/file31509/subprocess_issue18851_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Thu Aug 29 19:58:07 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Aug 2013 17:58:07 +0000
Subject: [issue18810] Stop doing stat calls in importlib.machinery.FileFinder
 to see if something is a file or folder
In-Reply-To: <1377182986.55.0.892405433608.issue18810@psf.upfronthosting.co.za>
Message-ID: <1377799087.61.0.682390742234.issue18810@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I also just tried using os.listdir() for a package before searching for __init__ and it didn't speed anything up either (actually timeit suggests that os.listdir() is worse than an isdir + 3 * isfile checks). Nor did caching directory stuff at the class level so that they were shared when an os.listdir() was done for an __init__ so that didn't have to be done a second time if the cache wasn't stale already.

I have attached the patch with all of the changes to cut the number of stat calls down significantly, but benchmarking on my work machine shows no definitive benefit.

----------
keywords: +patch
Added file: http://bugs.python.org/file31510/less_stats.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18810>
_______________________________________

From report at bugs.python.org  Thu Aug 29 20:10:56 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 29 Aug 2013 18:10:56 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1377799856.12.0.470184905903.issue18874@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Is it really impossible to use a standard Python dict instead of cfuhash?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18874>
_______________________________________

From report at bugs.python.org  Thu Aug 29 20:24:15 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 29 Aug 2013 18:24:15 +0000
Subject: [issue18643] implement socketpair() on Windows
In-Reply-To: <3cQrP131b1z7Ll3@mail.python.org>
Message-ID: <CAH_1eM1w3q9rHGdjUBzvdMyx02eNv=NzzN2Hqu0VaUjNkqdMoA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Alright, I chose a 16MB size for SOCK_MAX_SIZE because nowadays, one
can encounter large buffers for Gigabit/10Gb Ethernet.

Regarding the original issue: is it OK to add it as
socket.socketpair(), or should it only be added to test.support?
Since I don't use Windows, I don't know if this deserves being expose
in socket module, but having socketpair() available in the test suite
would be really useful (for example, most select tests aren't run on
Windows because they use pipes).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18643>
_______________________________________

From report at bugs.python.org  Thu Aug 29 20:25:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 18:25:27 +0000
Subject: [issue1617161] Instance methods compare equal when their self's are
 equal
Message-ID: <1377800727.42.0.393650551939.issue1617161@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please update the patch for tip? I looks too desynchronized.

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1617161>
_______________________________________

From report at bugs.python.org  Thu Aug 29 20:29:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 18:29:33 +0000
Subject: =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0and_readline=28?=
 =?utf-8?q?=29_argument_names?=
In-Reply-To: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za>
Message-ID: <1377800973.11.0.937672810315.issue17003@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Are there any objections to the patch?

----------
assignee: docs at python -> serhiy.storchaka
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17003>
_______________________________________

From report at bugs.python.org  Thu Aug 29 20:46:37 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 29 Aug 2013 18:46:37 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377798586.43.0.0808078175897.issue18876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1ma77U=6UqOyjwHDmBa4kwxZVR_NuAYCJdPz52MPsY8g@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> On which systems is O_APPEND not supported? It's part of the POSIX standard, and even Windows seems to have it.

That would be surprising.
An easy way to find this out would be to remove the ifdef:
352 #ifdef O_APPEND
353 if (append)
354 flags |= O_APPEND;
355 #endif

>> Whereas the behavior of O_APPEND causes an automatic seek to the end
>> before any write().
>
> True, but IIRC some systems seek on open() and some systems seek just before write().

POSIX makes it clear that only the later behavior is legal:
O_APPENDIf set, the file offset shall be set to the end of the file
prior to each write.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18876>
_______________________________________

From report at bugs.python.org  Thu Aug 29 20:52:47 2013
From: report at bugs.python.org (tegavu)
Date: Thu, 29 Aug 2013 18:52:47 +0000
Subject: [issue18877] tkinter askopenfilenames does not work in Windows
 library folder
Message-ID: <1377802367.69.0.551472579776.issue18877@psf.upfronthosting.co.za>


New submission from tegavu:

Using Python 3.3 on W7x64 I wanted to create a file dialog that allows me to select multiple files.
The code below is an example of how to re-create the bug.

# -*- coding: iso-8859-15 -*-
# Python 3

import tkinter 
import tkinter.filedialog  

def callback():
    name = tkinter.filedialog.askopenfilenames() 
    print(name)
     
tkinter.Button(text='File Open', command=callback).pack()
tkinter.mainloop()


---------
THE PROBLEM:
When selecting any file in the windows library\* folders (those: http://beingpc.com/wp-content/uploads/2011/05/How-to-Change-the-Windows-7-Library-Icon.jpg ) the return value that will be printed is always {}.
tkinter.filedialog.askopenfilename() (without the 's') works fine also in those directories.

Can anyone reproduce this behavior?

----------
components: Tkinter, Windows
messages: 196479
nosy: tegavu
priority: normal
severity: normal
status: open
title: tkinter askopenfilenames does not work in Windows library folder
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18877>
_______________________________________

From report at bugs.python.org  Thu Aug 29 21:11:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 19:11:39 +0000
Subject: [issue17201] Use allowZip64=True by default
In-Reply-To: <1360775072.39.0.12779828627.issue17201@psf.upfronthosting.co.za>
Message-ID: <1377803499.73.0.78699298839.issue17201@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch LGTM. If anyone has objections, say them now.

----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17201>
_______________________________________

From report at bugs.python.org  Thu Aug 29 21:31:04 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 29 Aug 2013 19:31:04 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377804664.5.0.29532589032.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

I wanted to move away from the --with-pydebug to a normal python and I failed with:

# emerge dev-lang/python:2.7

 * IMPORTANT: 11 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

Calculating dependencies... done!
Debug memory block at address p=0xa7f5900: API 'o'
    80 bytes originally requested
    The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfb):
        at p-7: 0xfb
        at p-6: 0xfb
        at p-5: 0xfa *** OUCH
        at p-4: 0xfb
        at p-3: 0xfb
        at p-2: 0xfb
        at p-1: 0xfb
    Because memory is corrupted at the start, the count of bytes requested
       may be bogus, and checking the trailing pad bytes may segfault.
    The 8 pad bytes at tail=0xa7f5950 are FORBIDDENBYTE, as expected.
    The block was made by call #21242094 to debug malloc/realloc.
    Data at p: 73 00 00 00 79 00 00 00 ... 67 00 00 00 00 00 00 00
Fatal Python error: bad leading pad byte
Aborted (core dumped)
#

Great. So, what can we gather now from this? It got overwritten within few dozens of seconds at most since I started emerge. It is in a different memory region (so no memory module HW bug). I am attaching the resolved stacktrace just in case ...

----------
Added file: http://bugs.python.org/file31511/core.emerge.8425.gdb.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Thu Aug 29 21:48:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 19:48:58 +0000
Subject: [issue18878] Add support of the 'with' statement to sunau.open.
Message-ID: <1377805738.91.0.260228450439.issue18878@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds support of the 'with' statement to sunau.open (as it already was added for aifc.open and wave.open). It based on patches from issue17616.

----------
components: Library (Lib)
messages: 196482
nosy: r.david.murray, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add support of the 'with' statement to sunau.open.
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18878>
_______________________________________

From report at bugs.python.org  Thu Aug 29 21:49:08 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 29 Aug 2013 19:49:08 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377805748.82.0.415536481534.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

One more note. At that time I had running my application which at that time was parsing an XML file using xml.parsers.expat! That is being run in my pipeline before I render figures (the initially reported crash case). So, matplotlib/numpy is ruled out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Thu Aug 29 21:50:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 19:50:17 +0000
Subject: [issue18878] Add support of the 'with' statement to sunau.open.
In-Reply-To: <1377805738.91.0.260228450439.issue18878@psf.upfronthosting.co.za>
Message-ID: <1377805817.16.0.955535606638.issue18878@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file31512/sunau_context_manager.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18878>
_______________________________________

From report at bugs.python.org  Thu Aug 29 21:51:18 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Aug 2013 19:51:18 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1377805878.21.0.928319634969.issue18874@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Is it really impossible to use a standard Python dict instead of cfuhash?

I don't know if it is possible or not, I didn't try. Using PyDict has many requirements:

* the GIL must be held: I plan to hook also PyMem_Raw (which is called without the GIL being held)
* PyDict uses PyMem_Malloc() which would be a reentrant call
* the API uses PyObject* whereas tracemalloc uses C types and C structures
* PyDict can raises Python exceptions, which is not something expected from a memory allocator (especially PyMem_Malloc)
* etc.

The implementation is not done yet. I would like to be able to compute the size of memory allocated by the _tracemalloc module: size of hash tables.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18874>
_______________________________________

From report at bugs.python.org  Thu Aug 29 21:53:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 19:53:27 +0000
Subject: [issue8934] aifc should use str instead of bytes (wave,
 sunau compatibility)
In-Reply-To: <1275936965.71.0.27334704307.issue8934@psf.upfronthosting.co.za>
Message-ID: <1377806007.68.0.294489177446.issue8934@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka
versions: +Python 3.4 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8934>
_______________________________________

From report at bugs.python.org  Thu Aug 29 21:54:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 19:54:07 +0000
Subject: [issue8934] aifc should use str instead of bytes (wave,
 sunau compatibility)
In-Reply-To: <1275936965.71.0.27334704307.issue8934@psf.upfronthosting.co.za>
Message-ID: <1377806047.19.0.790038691356.issue8934@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8934>
_______________________________________

From report at bugs.python.org  Thu Aug 29 22:25:43 2013
From: report at bugs.python.org (jort bloem)
Date: Thu, 29 Aug 2013 20:25:43 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
Message-ID: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>


New submission from jort bloem:

Issue occurs in the following code: tempfile.NamedTemporaryFile(dir=".",delete=False).write("hello")

The NamedTemporaryFile is deleted before the write is complete; deleting the object closes the file, so the write fails.

----------
messages: 196485
nosy: jort.bloem
priority: normal
severity: normal
status: open
title: tempfile.NamedTemporaryFile can close the file too early, if not assigning to a variable
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Thu Aug 29 22:25:53 2013
From: report at bugs.python.org (Merlijn van Deen)
Date: Thu, 29 Aug 2013 20:25:53 +0000
Subject: [issue18870] eval() uses latin-1 to decode str
In-Reply-To: <1377713902.12.0.966249722349.issue18870@psf.upfronthosting.co.za>
Message-ID: <1377807953.52.0.536183205972.issue18870@psf.upfronthosting.co.za>


Merlijn van Deen added the comment:

On the lowest level, this affects exec, eval(), compile() and input() (!). On a higher level, more modules are affected:

modules ast, codeop, compiler, cProfile, dis, distutils (not sure), doctest, idlelib, ihooks, pdb, pkgutil, plat-mac, py_compile, rexec, runpy and timeit all call compile()

modules dbd, compiler, gettext, idlelib, lib2to3, lib-tk.turtle, logging, mhlib, pdb, plat-irix5, plat-mac, rexec, rlcompleter and warnings all call eval()

and modules Bastion, bdb, code, collections, cProfile, distutils, doctest, idlelib, ihooks, imputil, pdb, plat-irix5, plat-irix6, plat-mac, profile, rexec, site, timeit and trace all call exec.

Not all of them necessarily take user-supplied code - I haven't checked that.


After checking tests/test_pep263.py, it seems the behavior is a bit more complicated than I initially thought: a str parameter is considered latin-1 unless either
 a) an utf-8 bom is present, in which case it is considered utf-8
 b) an # encoding: XXX  line is present, in which case it is considered
    to be in that encoding

In any case, I have attached a doc patch for exec, eval(), compile(), and ast.literal_eval(), because I think these are the most widely used. I think input() does not need a doc change because it explicitly refers to eval().

I ignored the subtleties noted above for the doc patch, simplifying to 'pass either a Unicode or a latin-1 encoded string'.

----------
keywords: +patch
Added file: http://bugs.python.org/file31513/doc_18870.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18870>
_______________________________________

From report at bugs.python.org  Thu Aug 29 22:26:07 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 29 Aug 2013 20:26:07 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377807967.13.0.582389049634.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

Hmm.  I don't quite know what you're doing:  you said you're getting away from --with-pydebug, but these "bad leading pad byte" messages can't be generated unless Python is compiled with (at least) PYMALLOC_DEBUG defined.

That said, my advice remains the same:  whittle down the program (instead of fiddling with tools) to get a failing case as small & fast as possible.  In your "few dozens of seconds at most", many _millions_ of things happen, and there's scant chance of out-thinking them.

In the newest traceback (core.emerge.8425.gdb.txt), Python detected the corruption while running its cyclic-garbage collector.  Forcing gc to run more often may catch the corruption sooner (use Python's gc.set_threshold() to force more frequent collections).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Thu Aug 29 22:27:02 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Aug 2013 20:27:02 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1377808022.44.0.355712198615.issue18879@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Thu Aug 29 22:31:03 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Thu, 29 Aug 2013 20:31:03 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377808263.99.0.458832930439.issue18850@psf.upfronthosting.co.za>


Michele Orr? added the comment:

> Is that you actual use case? That you *want* to store binary data in XML, instead of getting it properly rejected as non well-formed content?
No, Stefan.

What I was saying in my last message was  just "you're right, the user shall always use repr() when printing an xml tree" (msg196313) because "xml does *not* guarantee to have only printable chars by itself" (msg196368, msg196379).

As an advice I hope you do not take as insult, saying
"in section {section} the spec says {argument}" 
is much more constructive than 
"read the spec on that", "{extremely_obvious_link}",
at least to people not familiar with the spec and asking for the source of your arguments (msg196360). Can shorten threads, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Thu Aug 29 22:40:04 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Aug 2013 20:40:04 +0000
Subject: [issue15507] test_subprocess assumes SIGINT is not being ignored.
In-Reply-To: <1343680541.23.0.308681373166.issue15507@psf.upfronthosting.co.za>
Message-ID: <3cQwg76N1jz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 9810844126e1 by Gregory P. Smith in branch '3.3':
Fixes issue #15507: test_subprocess's test_send_signal could fail if the test
http://hg.python.org/cpython/rev/9810844126e1

New changeset 6aa7ca40b100 by Gregory P. Smith in branch 'default':
Fixes Issue #15507: test_subprocess's test_send_signal could fail if the test
http://hg.python.org/cpython/rev/6aa7ca40b100

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15507>
_______________________________________

From report at bugs.python.org  Thu Aug 29 22:41:38 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 29 Aug 2013 20:41:38 +0000
Subject: [issue15507] test_subprocess assumes SIGINT is not being ignored.
In-Reply-To: <1343680541.23.0.308681373166.issue15507@psf.upfronthosting.co.za>
Message-ID: <1377808898.81.0.231277477336.issue15507@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15507>
_______________________________________

From report at bugs.python.org  Thu Aug 29 22:44:36 2013
From: report at bugs.python.org (Erik Bray)
Date: Thu, 29 Aug 2013 20:44:36 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>
Message-ID: <1377809076.13.0.927065383806.issue18876@psf.upfronthosting.co.za>


Erik Bray added the comment:

>> Whereas the behavior of O_APPEND causes an automatic seek to the end
>> before any write().

> True, but IIRC some systems seek on open() and some systems seek just before write().

I figured that workaround that seeks to the end on open was an attempt to normalize behavior between different systems, and seems to me like a reasonable compromise to support systems that somehow don't support append.

But a better compromise I think would be to seek to the beginning of the file and modify fileio_write and friends to always seek to the end before a write if the file was opened in append mode. This would be more in line with the POSIX behavior.

I have no idea on what systems O_APPEND isn't supported, but I figured they must exist because someone put an #ifdef in there once :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18876>
_______________________________________

From report at bugs.python.org  Thu Aug 29 22:47:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Aug 2013 20:47:01 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>
Message-ID: <1377809221.12.0.450018911872.issue18876@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18876>
_______________________________________

From report at bugs.python.org  Thu Aug 29 22:54:25 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 29 Aug 2013 20:54:25 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377809665.89.0.641408402214.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Sorry, I should explain a bit more. Gentoo Linux uses a tool named emerge to handle packages. It is written in python. So, by that command I initiated re-compilation of python itself but it crashed quickly. At that moment emerge called the python available on the system at that time which was configured using --with-pydebug.


Meanwhile I went to install DUMA http://duma.sourceforge.net/ and started to re-run emerge.

# emerge duma
# export LD_PRELOAD=/usr/lib64/libduma.so.0.0.0
# sysctl -w vm.max_map_count=1000000
# emerge dev-lang/python:2.7 


Thanks for your analysis, will try to stitch something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Thu Aug 29 22:56:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 20:56:00 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1377809760.75.0.714239366787.issue18879@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +IO, Library (Lib)
nosy: +georg.brandl, ncoghlan, serhiy.storchaka
versions: +Python 3.3, Python 3.4 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Thu Aug 29 23:03:27 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 29 Aug 2013 21:03:27 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377810207.04.0.480412257776.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

Yet Another Tool ;-)  Python's "small object" allocator grabs memory in chunks of 256KB from the system, and carves up the space itself.  Other memory tools (like Valgrind ...) only see that Python has grabbed 256KB chunks, so can't detect anything wrong _within_ those large blocks.  For that reason, compiling Python --without-pymalloc usually increases the usefulness of other tools.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Thu Aug 29 23:06:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 21:06:07 +0000
Subject: [issue18870] eval() uses latin-1 to decode str
In-Reply-To: <1377713902.12.0.966249722349.issue18870@psf.upfronthosting.co.za>
Message-ID: <1377810367.31.0.218585226449.issue18870@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue15809.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18870>
_______________________________________

From report at bugs.python.org  Thu Aug 29 23:36:58 2013
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBaaWVsacWEc2tp?=)
Date: Thu, 29 Aug 2013 21:36:58 +0000
Subject: [issue18880] ssl.SSLSocket shutdown doesn't behave like
 socket.shutdown
Message-ID: <1377812218.52.0.68669263864.issue18880@psf.upfronthosting.co.za>


New submission from Micha? Zieli?ski:

SSLSocket documentation mentions shutdown as analogue to socket.shutdown. However, instead of forbidding communication, it removes SSL wrapper from socket. For example, the following script doesn't work and returns garbage:

    import socket
    import ssl

    s = socket.socket()
    s.connect(('google.com', 443))
    client = ssl.wrap_socket(s)
    client.sendall(b'GET / HTTP/1.0\nConnection: close\n\n')
    client.shutdown(socket.SHUT_WR)

    print(repr(client.recv(40)))

Attached patch makes shutdown raise exception if how != SHUT_RDWR, as closing one side of socket over SSL doesn't make sense (unless I'm missing something).

----------
components: Library (Lib)
files: ssl-shutdown-fail.patch
keywords: patch
messages: 196494
nosy: zielmicha
priority: normal
severity: normal
status: open
title: ssl.SSLSocket shutdown doesn't behave like socket.shutdown
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31514/ssl-shutdown-fail.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18880>
_______________________________________

From report at bugs.python.org  Fri Aug 30 00:11:02 2013
From: report at bugs.python.org (Erik Bray)
Date: Thu, 29 Aug 2013 22:11:02 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>
Message-ID: <1377814262.19.0.989413216382.issue18876@psf.upfronthosting.co.za>


Erik Bray added the comment:

Here's an initial stab at a simple patch that just addresses the issue of 'append' not being in the mode string.  Amazingly this did not break a single existing test, though I added a new one to test how FileIO objects display their mode string after being initialized (normalizes modes like 'r+b' to 'rb+', etc.)  Most of what it tests is the existing behavior, but it also tests for the reintroduction of the 'a' mode.

This doesn't address the BufferedWriter issue, nor does it address cross-platform issues.

----------
keywords: +patch
Added file: http://bugs.python.org/file31515/issue_18876_patch_1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18876>
_______________________________________

From report at bugs.python.org  Fri Aug 30 00:36:18 2013
From: report at bugs.python.org (jort bloem)
Date: Thu, 29 Aug 2013 22:36:18 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1377815778.82.0.998285090393.issue18879@psf.upfronthosting.co.za>


jort bloem added the comment:

Sorry, my python-foo is not quite up to providing a solution. A partial solution would be for the file not to be closed at NamedTemporaryFile destruction, if delete==False. If delete==True, then there is no point writing to a file (though it shouldn't raise an exception, either).

Alternatively, on a unix based system, the file could be deleted, but left open. Read & write could continue as per normal, and the file would be closed automatically later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Fri Aug 30 00:42:54 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 29 Aug 2013 22:42:54 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377816174.3.0.899429171764.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Thanks, will recompile without pymalloc.

I don't understand why always is only 1 bit different. Could that be overwritten by another use process or do you believe it must be the python or some of the modules imported into it on runtime?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 01:14:49 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 29 Aug 2013 23:14:49 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377818089.19.0.641241054027.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

It would be a severely lame OS that allowed a process to overwrite another process's memory ;-)  "Bad C or C++ code", in the process you're running, is still the best guess.

A memory module that sometimes dropped the last bit _could_ be at fault, but I doubt it (0xfb changes to 0xfa if the last bit is cleared).

That the address is different across the two failure examples doesn't rule out bad memory, though:  the memory address an OS shows you is a "logical address", an _offset_ from the start of the physical memory the OS happened to assign to the process.  Across different runs, the same physical memory location may be shown as any number of different logical addresses.

We'll understand why it's off by 1 eventually ;-)  For example, it could be C code as simple as:

    char* p = (char *)allocate_some_memory(80);
    ...
    p -= 5;
    ...
    if (something)
        --*p;

It's extremely easy for C code to do insane stores; indeed, that's why there are so many sophisticated tools for trying to find the source of memory corruption in C/C++ code.

Question:  did the last failure come from your code, or from merely running `emerge`?  You said your code "was parsing an XML file" at the time, but there's no trace of expat (or any other xml parsing code) in the traceback, and the traceback "bottoms out" at `emerge`.  Maybe this has nothing at all to do with your code????

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 01:25:37 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 29 Aug 2013 23:25:37 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377818737.18.0.881707399683.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

That is why I asked if other process can interfere. So, they are isolated on Linux, good. ;-) The crash in #msg196481 is just the emerge written in python, at the start it is resolving some graph of package dependencies ... once it resolves order of packages and prints a lot of output. so, it did not get to that before it crashed. In sum with what you said, my application running as another process should not interfere with the emerge process, so it turns out that was irrelevant comment from my side. ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 01:30:38 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 29 Aug 2013 23:30:38 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377819038.81.0.0748008427121.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

http://www.gentoo.org/proj/en/portage/index.xml
http://dev.gentoo.org/~zmedico/portage/archives

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 01:33:40 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Aug 2013 23:33:40 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1377819220.04.0.273951546962.issue18879@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The method call should keep the file object alive until it completes (due to the self reference). What behaviour prompted the conclusion that it is being closed early?

If the symptom is that the data isn't being written to disk, we may have a missing flush() call somewhere causing a race condition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Fri Aug 30 01:43:29 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 29 Aug 2013 23:43:29 +0000
Subject: [issue18881] Can someone try to duplicate corruption on Gentoo?
Message-ID: <CAExdVN=6SMyxLMPi+KiFTH5ophjM1kz9St8jYqNm38hANujUZg@mail.gmail.com>


New submission from Tim Peters:

In

    http://bugs.python.org/issue18843

a user reported a debug PyMalloc "bad leading pad byte" memory
corruption death while running their code.  After some thrashing, they
decided to rebuild Python, and got the same kind of error while
rebuilding Python.  See

    http://bugs.python.org/msg196481

in that bug report:

"""
# emerge dev-lang/python:2.7

 * IMPORTANT: 11 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

Calculating dependencies... done!
Debug memory block at address p=0xa7f5900: API 'o'
    80 bytes originally requested
    The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfb):
        at p-7: 0xfb
        at p-6: 0xfb
        at p-5: 0xfa *** OUCH
        at p-4: 0xfb
        at p-3: 0xfb
        at p-2: 0xfb
        at p-1: 0xfb
    Because memory is corrupted at the start, the count of bytes requested
       may be bogus, and checking the trailing pad bytes may segfault.
    The 8 pad bytes at tail=0xa7f5950 are FORBIDDENBYTE, as expected.
    The block was made by call #21242094 to debug malloc/realloc.
    Data at p: 73 00 00 00 79 00 00 00 ... 67 00 00 00 00 00 00 00
Fatal Python error: bad leading pad byte
Aborted (core dumped)
#
"""

I don't have access to Gentoo, and don't know squat about its
`emerge`, but if someone else can do this it might help ;-)  The
Python used to run `emerge` here was a --with-pydebug Python the bug
reporter built earlier.

----------
messages: 196502
nosy: tim.peters
priority: normal
severity: normal
status: open
title: Can someone try to duplicate corruption on Gentoo?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18881>
_______________________________________

From report at bugs.python.org  Fri Aug 30 01:45:34 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 29 Aug 2013 23:45:34 +0000
Subject: [issue18881] Can someone try to duplicate corruption on Gentoo?
In-Reply-To: <CAExdVN=6SMyxLMPi+KiFTH5ophjM1kz9St8jYqNm38hANujUZg@mail.gmail.com>
Message-ID: <1377819934.67.0.955910255339.issue18881@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18881>
_______________________________________

From report at bugs.python.org  Fri Aug 30 01:46:04 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 29 Aug 2013 23:46:04 +0000
Subject: [issue18881] Can someone try to duplicate corruption on Gentoo?
In-Reply-To: <CAExdVN=6SMyxLMPi+KiFTH5ophjM1kz9St8jYqNm38hANujUZg@mail.gmail.com>
Message-ID: <1377819964.94.0.567466660059.issue18881@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18881>
_______________________________________

From report at bugs.python.org  Fri Aug 30 01:46:33 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 29 Aug 2013 23:46:33 +0000
Subject: [issue18881] Can someone try to duplicate corruption on Gentoo?
In-Reply-To: <CAExdVN=6SMyxLMPi+KiFTH5ophjM1kz9St8jYqNm38hANujUZg@mail.gmail.com>
Message-ID: <1377819993.1.0.405070275721.issue18881@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18881>
_______________________________________

From report at bugs.python.org  Fri Aug 30 01:48:07 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 29 Aug 2013 23:48:07 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377820087.18.0.686665355974.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

I sent a msg to Python-Dev, asking for a Gentoo user to try to reproduce this.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 01:56:42 2013
From: report at bugs.python.org (Meador Inge)
Date: Thu, 29 Aug 2013 23:56:42 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1377820602.85.0.268565297195.issue18879@psf.upfronthosting.co.za>


Meador Inge added the comment:

Confirmed in trunk:

>>> tempfile.NamedTemporaryFile(dir=".",delete=False).write(b"hello")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: write to closed file

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Fri Aug 30 02:36:12 2013
From: report at bugs.python.org (Trent Nelson)
Date: Fri, 30 Aug 2013 00:36:12 +0000
Subject: [issue16296] Patch to fix building on Win32/64 under VS 2010
In-Reply-To: <1350842175.59.0.919553926658.issue16296@psf.upfronthosting.co.za>
Message-ID: <1377822972.15.0.350250410392.issue16296@psf.upfronthosting.co.za>


Changes by Trent Nelson <trent at snakebite.org>:


----------
nosy: +trent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16296>
_______________________________________

From report at bugs.python.org  Fri Aug 30 02:52:28 2013
From: report at bugs.python.org (Trent Nelson)
Date: Fri, 30 Aug 2013 00:52:28 +0000
Subject: [issue16296] Patch to fix building on Win32/64 under VS 2010
In-Reply-To: <1350842175.59.0.919553926658.issue16296@psf.upfronthosting.co.za>
Message-ID: <1377823948.84.0.462602638258.issue16296@psf.upfronthosting.co.za>


Changes by Trent Nelson <trent at snakebite.org>:


----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16296>
_______________________________________

From report at bugs.python.org  Fri Aug 30 04:48:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Aug 2013 02:48:47 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1377830927.58.0.245034529972.issue18879@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Fri Aug 30 04:52:15 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Aug 2013 02:52:15 +0000
Subject: [issue18489] IDLE Unit test for SearchEngine.py
In-Reply-To: <1374118219.91.0.797974191988.issue18489@psf.upfronthosting.co.za>
Message-ID: <1377831134.99.0.263025960462.issue18489@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The attached patch works on 3.3 and just need a small addition for 100$ coverage. After that, I intend to commit after porting to 2.7 (only two lines to change, I think) and testing it there.

I split the search test case into three, one for each method. The tests for search_text repeated the tests for search_forward/backward. Simple mocks for the latter two allow to test for what search_text actually does: pick the right function to call and right starting point.

The effect of the ok parameter is complicated because it has different effects in search_text and the other two (and less effect in search_backward than in search_forward because they are not symmetric).

'\w+' never matches an empty string; so there was no test of 'ok=true' in search_forward. '\w*' can have empty matches and there now is a test. I discovered what seems to me a bug. If an initial null match is ignored, the search skips the rest of the line and skips to the next. This seems wrong but I am not sure what the proper behavior should be. I want to investigate the use of ok in the dialogs, especially the replace dialog before deciding

The test of search_forward uses the mock Text. The remaining gui uses here (and many in other tests) could be eliminated with just a partial implementation of marks and selections, one that kept them fixed rather than moving them with insert and delete. So far we have been inserting text just once and then setting and getting things on a fixed text.

----------
stage: patch review -> commit review
Added file: http://bugs.python.org/file31516/18489-test_searchengine6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18489>
_______________________________________

From report at bugs.python.org  Fri Aug 30 05:11:21 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Aug 2013 03:11:21 +0000
Subject: [issue18489] IDLE Unit test for SearchEngine.py
In-Reply-To: <1374118219.91.0.797974191988.issue18489@psf.upfronthosting.co.za>
Message-ID: <1377832281.76.0.0433472611759.issue18489@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Adding
        engine.patvar.set(None)
        Equal(search(text), None)

to test_search completed the coverage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18489>
_______________________________________

From report at bugs.python.org  Fri Aug 30 05:21:58 2013
From: report at bugs.python.org (Meador Inge)
Date: Fri, 30 Aug 2013 03:21:58 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1377832918.98.0.865596493779.issue18879@psf.upfronthosting.co.za>


Meador Inge added the comment:

'tempfile.NamedTemporaryFile' returns an instance of '_TemporaryFileWrapper' that wraps the created file object.  The wrapper object implements '__getattr__' and we end up with a situation like the following simplified example where the wrapper gets destroyed before the looked up method is called:

$ cat test.py 
class S(object):
   def __init__(self):
      print("S.__init__")   def __del__(self):      print("S.__del__")
   def foo(self):
      print("S.foo")

class T(object):
   def __init__(self, s):
      self.s = s
      print("T.__init__")
   def __getattr__(self, name):
        s = self.__dict__['s']
        a = getattr(s, name)
        print("__getattr__('%s')" % name)
        if not isinstance(a, int):
            setattr(self, name, a)
        return a
   def __del__(self):
      print("T.__del__")
T(S()).foo()
$ ./python test.py 
S.__init__
T.__init__
__getattr__('foo')
T.__del__
S.foo
S.__del__

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Fri Aug 30 05:56:16 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 30 Aug 2013 03:56:16 +0000
Subject: [issue18550] internal_setblocking() doesn't check return value of
 fcntl()
In-Reply-To: <1374694779.19.0.0902694218162.issue18550@psf.upfronthosting.co.za>
Message-ID: <1377834976.5.0.931213400083.issue18550@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18550>
_______________________________________

From report at bugs.python.org  Fri Aug 30 06:23:26 2013
From: report at bugs.python.org (Madison May)
Date: Fri, 30 Aug 2013 04:23:26 +0000
Subject: [issue18550] internal_setblocking() doesn't check return value of
 fcntl()
In-Reply-To: <1374694779.19.0.0902694218162.issue18550@psf.upfronthosting.co.za>
Message-ID: <1377836606.05.0.368763725655.issue18550@psf.upfronthosting.co.za>


Madison May added the comment:

The attached patch?  :)

----------
nosy: +madison.may

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18550>
_______________________________________

From report at bugs.python.org  Fri Aug 30 06:25:53 2013
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Fri, 30 Aug 2013 04:25:53 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377836753.97.0.396519702614.issue18843@psf.upfronthosting.co.za>


Stephen J. Turnbull added the comment:

I have a gentoo host, but I'd like to know how did the OP get a debug Python in the first place?  The ebuild for python 2.7.5-r1 doesn't say anything about debug options.  "How" would preferably include information about the C compiler used, etc.  If there's no information, I can probably just hack --with-pydebug into a local ebuild, but I have something like 7 C compilers installed, I'd really like a good guess at the right one.  Also, did he add any optimization flags etc when building the debug Python?

(ebuild = the emerge configuration file that describes the build and install process for a package.  In "2.7.5-r1" the "r1" indicates the first revised ebuild for the same upstream version.)

----------
nosy: +sjt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 06:27:16 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 30 Aug 2013 04:27:16 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1377836836.96.0.324869432674.issue18850@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> As an advice I hope you do not take as insult, saying
> "in section {section} the spec says {argument}" 
> is much more constructive than 
> "read the spec on that", "{extremely_obvious_link}",
> at least to people not familiar with the spec and asking for the source > of your arguments (msg196360). Can shorten threads, too.

No harm done. The reason why I just posted the spec URL is that it's actually the entire spec that backs the argument. XML is (essentially) specified as a mapping from a sequence of bytes to a hierarchical structure (and back again). That's why there is an XML declaration header that names the encoding, for example. It wouldn't be needed if XML was defined as Unicode data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18850>
_______________________________________

From report at bugs.python.org  Fri Aug 30 06:28:35 2013
From: report at bugs.python.org (Madison May)
Date: Fri, 30 Aug 2013 04:28:35 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1377836915.33.0.408894273354.issue18828@psf.upfronthosting.co.za>


Changes by Madison May <madison.may at students.olin.edu>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________

From report at bugs.python.org  Fri Aug 30 06:35:36 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 30 Aug 2013 04:35:36 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377837336.04.0.629633144944.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

Thanks for chiming in, Stephen!  I can't answer your questions, but agree the original poster needs to tell you exactly what he did -- else we'd just be thrashing at random.  There's been enough of that already ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 06:46:57 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 30 Aug 2013 04:46:57 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377838017.19.0.986670677889.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

Martin, can you please supply exact commands Stephen can use to try to reproduce the problem you saw running `emerge`?  And try them yourself first, to make sure you can reproduce the problem too.

Any detail may be important.  For example, it's possible this is due to a bug in the C compiler used to compile Python, or due to some flag passed to the compiler.  That's why "exact commands" are important.

The good news:  if Stephen can reproduce it, he'll probably figure out all the rest, and you'll be free to resume enjoying your life ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 08:08:19 2013
From: report at bugs.python.org (Martin Panter)
Date: Fri, 30 Aug 2013 06:08:19 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1377842899.55.0.747295284631.issue18828@psf.upfronthosting.co.za>


Martin Panter added the comment:

Similarly, I expected this to return "rtmp://host/app?auth=token":

urljoin("rtmp://host/app", "?auth=token")

I'm not sure adding everybody's custom scheme to a hard-coded whitelist is the best way to do solve this.

Below I have identified some other schemes not in the "uses_relative" list. Is there any reason why one would use urljoin() with them, but want the base URL to be ignored (as is the current behaviour)? I looked at test_urlparse.py and there doesn't seem to be any test cases for these schemes.

>>> all = set().union(uses_relative, uses_netloc, uses_params, non_hierarchical, uses_query, uses_fragment)
>>> sorted(all.difference(uses_relative))
['git', 'git+ssh', 'hdl', 'mailto', 'news', 'nfs', 'rsync', 'sip', 'sips', 'snews', 'tel', 'telnet']

Even if the behaviour can't be changed, could the documentation for urljoin() say something like this:

Only the following [uses_relative] schemes are allowed in the base URL; any other schemes result in the relative URL being returned without being joined to the base.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________

From report at bugs.python.org  Fri Aug 30 08:10:13 2013
From: report at bugs.python.org (Martin Panter)
Date: Fri, 30 Aug 2013 06:10:13 +0000
Subject: [issue1500504] Alternate RFC 3986 compliant URI parsing module
Message-ID: <1377843013.92.0.678879378693.issue1500504@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1500504>
_______________________________________

From report at bugs.python.org  Fri Aug 30 08:35:30 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Fri, 30 Aug 2013 06:35:30 +0000
Subject: [issue13951] Document that Seg Fault in .so called by ctypes causes
 the interpreter to Seg Fault
In-Reply-To: <1328535030.63.0.73417525944.issue13951@psf.upfronthosting.co.za>
Message-ID: <1377844530.41.0.72651589715.issue13951@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

Can we have this committed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13951>
_______________________________________

From report at bugs.python.org  Fri Aug 30 08:46:08 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Fri, 30 Aug 2013 06:46:08 +0000
Subject: [issue14937] IDLE's deficiency in the completion of file names
 (Python 32, Windows XP)
In-Reply-To: <1349993165.09.0.875208302206.issue14937@psf.upfronthosting.co.za>
Message-ID: <CADao8eSmWCMBSVLPzx+mSt2AKYvpmF=O-wdLg+gpgEAGV4wV2w@mail.gmail.com>


Westley Mart?nez added the comment:

On Thu, Oct 11, 2012 at 3:06 PM, Terry J. Reedy <report at bugs.python.org> wrote:
>
> Terry J. Reedy added the comment:
>
> This patch (I suspect it is this one) disabled the use of '/' in filenames on windows when using filename completion.
>
> 'c:\   <wait, tab, ^space bring up box> in 3.2.3 and 3.3.0>
> (If there is no 'r' prefix, it really should require '\\' to be safe.)

+1 for requiring \\.

I'll test this tomorrow and report back the behaviour.  On Linux it
seems that the window only pops up when you press tab.  I think
behaviour should be as identical on all platforms as possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14937>
_______________________________________

From report at bugs.python.org  Fri Aug 30 08:47:32 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Aug 2013 06:47:32 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377845252.98.0.658874990795.issue18843@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Just two things:
- running under valgrind with the suppression file would help pinpoint this
- usually, stack/heap overflows or invalid pointer dereference affect a contiguous chunk of memory: here, there's a *single bit* flipped, not even a byte
0xfb == 0b11111011
0xfa == 0b11111010

This looks like an hardware issue to me.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 09:07:00 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Fri, 30 Aug 2013 07:07:00 +0000
Subject: [issue14974] rename packaging.pypi to packaging.index
In-Reply-To: <1338502462.41.0.230255399861.issue14974@psf.upfronthosting.co.za>
Message-ID: <1377846420.58.0.448091989874.issue14974@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

I think I like the term catalog myself, but I'm not wholly opposed to index.  I think it is certainly better than pypi.

Although the namespace does reduce the genericness of index, a lot of programmers (including me) like to use the from namespace import x method.  I think that's considerable.  That said, programmers could use from packaging import index as pindex or some sort to alleviate this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14974>
_______________________________________

From report at bugs.python.org  Fri Aug 30 11:53:27 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Fri, 30 Aug 2013 09:53:27 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377856407.33.0.585951271385.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Hi Stephen,
  I discussed the USE=debug here (https://bugs.gentoo.org/show_bug.cgi?id=482348) and it is denied by portage maintainers because it is not only a debug addition but a whole API change. We have to live with:

mkdir -p /etc/portage/env
echo 'EXTRA_ECONF="--with-pydebug"' > /etc/portage/env/pydebug.conf
echo dev-lang/python pydebug.conf >> /etc/portage/package.env


The above what I had originally. Yesterday I tried even:

# cat /etc/portage/env/pydebug.conf 
EXTRA_ECONF="--with-pydebug --without-pymalloc --with-valgrind"
#

but I don't know what the valgrind option really does and, whether that means:
a) python will run itself under valgrind, don't both doing it yourself
b) you don't have to bother with uncommenting the lines in valgrind.supp
c) "make install" will install the valgrind.supp but you have to edit it on your own
d) you may use valgrind but don't use other tool replacing malloc(), like electric fence, DUMA, etc.

Or some combination of them? :( The Readme.valgrind does not answer this at all.

I let DUMA inspect "emerge boost" run overnight but my computer stopped responding (16GB RAM).

I tried only gcc-4.7.3 and python-2.7.5-r2.

CFLAGS="-ggdb -pipe -msse  -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -mavx -maes -mpclmul -mpopcnt -march=corei7-avx"
CXXFLAGS="${CFLAGS}"


Per comment from Charles-Fran?ois, so you mean that this single-bit change won't be caught by valgrind, right? Why does not memtest86+ detect that? Could python when compiled with the --with-pydebug print also physical, hardware address of the wrong value? That would be really helpful here! Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 12:26:46 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 30 Aug 2013 10:26:46 +0000
Subject: [issue18882] Add threading.main_thread() function
Message-ID: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

We need public API for getting main thread object.
See also http://comments.gmane.org/gmane.comp.python.devel/141370

----------
messages: 196521
nosy: asvetlov, haypo, pitrou
priority: normal
severity: normal
status: open
title: Add threading.main_thread() function
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18882>
_______________________________________

From report at bugs.python.org  Fri Aug 30 12:51:20 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 30 Aug 2013 10:51:20 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377859880.95.0.282028990334.issue18843@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I uderstand that you are building Python using "emerge". I would try to get a release from python.org, do a normal build ...

make distclean
./configure --prefix=/tmp --with-pydebug --with-valgrind
make
make install

...

then install matplotlib using

/tmp/bin/python setup.py

...

then run (assuming you are in the build directory):

valgrind --suppressions=Misc/valgrind-python.supp /tmp/bin/python your_program

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:00:28 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 30 Aug 2013 12:00:28 +0000
Subject: [issue14130] memoryview: add multi-dimensional indexing and slicing
In-Reply-To: <1330259007.41.0.197339877072.issue14130@psf.upfronthosting.co.za>
Message-ID: <1377864028.86.0.982170730304.issue14130@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I would probably work on it (it's basically implemented in _testbuffer.c),
but I'm not sure if the NumPy community will actually use the feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14130>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:03:09 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 30 Aug 2013 12:03:09 +0000
Subject: [issue17145] memoryview(array.array)
In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>
Message-ID: <1377864189.03.0.203750363951.issue17145@psf.upfronthosting.co.za>


Stefan Krah added the comment:

The request is certainly valid, but the patch is tricky to review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17145>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:07:38 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Aug 2013 12:07:38 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1377864458.41.0.830740247437.issue18874@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, let's start with a first patch. It works in the common cases, because they are some corner cases like subinterpreter which might still crash.

The hook on PyMem_RawMalloc() takes the GIL. It is disabled because it has still bugs (it introduces a deadlock in some corner cases!)

----------
keywords: +patch
Added file: http://bugs.python.org/file31517/tracemalloc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18874>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:14:58 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Fri, 30 Aug 2013 12:14:58 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1377864898.02.0.902569536913.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31518/fix_for_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18849>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:18:37 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 30 Aug 2013 12:18:37 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <1377865117.34.0.587095702252.issue18882@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18882>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:29:27 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 30 Aug 2013 12:29:27 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <1377865767.35.0.127332548745.issue18882@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The function must take care of fork() in worker threads, too. The isinstance(current_thread(), _MainThread) trick may not work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18882>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:30:49 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 30 Aug 2013 12:30:49 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1377865849.93.0.0483429571021.issue16853@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Follows a couple of minor concerns.

- What about Solaris' /dev/poll?

- I'm not sure why in case of EINTR you retry with a different timeout; can't you just return []? 

- this is probably because I'm paranoid about performances but given that select() method will be called repeatedly I would not use a decorator. Also, similarly to what has been done elsewhere in the stdlib, for "critical" parts I would recommend localizing variable access in order to minimize overhead as in:

    def select(self, timeout=None):
        ... 
        key_from_fd = self._key_from_fd
        ready_append = ready.append
        for fd in r | w:
            ...
            key = key_from_fd(fd)
            if key:
                ready_append((key, events & key.events))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:44:37 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 30 Aug 2013 12:44:37 +0000
Subject: [issue18780] SystemError when formatting int subclass
In-Reply-To: <1376921434.69.0.557024484243.issue18780@psf.upfronthosting.co.za>
Message-ID: <1377866677.38.0.0681571554537.issue18780@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

lgtm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18780>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:45:07 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 30 Aug 2013 12:45:07 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <1377866707.44.0.997811219722.issue18882@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18882>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:47:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Aug 2013 12:47:11 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377865767.35.0.127332548745.issue18882@psf.upfronthosting.co.za>
Message-ID: <1412699048.25054518.1377866825205.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> The function must take care of fork() in worker threads, too. The
> isinstance(current_thread(), _MainThread) trick may not work.

Well, there are two possibilities:
- main_thread() returns the original _MainThread instance, even if it's
  dead in the child process
- main_thread() returns the main thread of the current process

Both are reasonable, but we must settle for one :-)

(also, the use case of forking from a thread is really obscure, I don't
think we should worry too much about it)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18882>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:48:17 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 30 Aug 2013 12:48:17 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <1377866897.22.0.203302994449.issue18882@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Patch with code and tests is attached.
Test fails when program forks from thread other than the main one.

----------
keywords: +patch
Added file: http://bugs.python.org/file31519/issue18882.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18882>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:49:15 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 30 Aug 2013 12:49:15 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <1377866955.03.0.864842514598.issue18882@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

signal module reinitializes main_thread variable in PyOS_AfterFork, threading does nothing with forking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18882>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:51:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Aug 2013 12:51:41 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <3cRLDF0FZmz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 8fd72b1bb262 by Eli Bendersky in branch 'default':
Issue #17741: Rename IncrementalParser and its methods.
http://hg.python.org/cpython/rev/8fd72b1bb262

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:51:56 2013
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 30 Aug 2013 12:51:56 +0000
Subject: [issue18852] site.py does not handle readline.__doc__ being None
In-Reply-To: <1377609308.01.0.92318264163.issue18852@psf.upfronthosting.co.za>
Message-ID: <1377867116.51.0.652743473555.issue18852@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18852>
_______________________________________

From report at bugs.python.org  Fri Aug 30 14:53:50 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 30 Aug 2013 12:53:50 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1377867230.2.0.300005988783.issue17741@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

This issue has become too large and discusses a few different things; hence I'm inclined to close it as fixed and open a new one as a placeholder for discussing the new design of the internals.

I'll do this in a couple of days if there are no objections.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Aug 30 15:27:32 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Fri, 30 Aug 2013 13:27:32 +0000
Subject: [issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error
 Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS,
 and Py_REF_DEBUG
Message-ID: <1377869252.37.0.462052472279.issue18883@psf.upfronthosting.co.za>


New submission from Martin Mokrejs:

Looks I cannot compile when python-3.3 was configured with --with-pydebug. I use Gentoo Linux, the -r2 shows they added some patches but should not matter I think.

building 'xxlimited' extension
x86_64-pc-linux-gnu-gcc -pthread -fPIC -Wno-unused-result -DDYNAMIC_ANNOTATIONS_ENABLED=1 -O2 -pipe -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -mavx -maes -mpclmul -mpopcnt -march=corei7-avx -fstack-protector-all -fwrapv -DPy_LIMITED_API=1 -IInclude -I. -I/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Include -I/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/x86_64-pc-linux-gnu -c /mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Modules/xxlimited.c -o build/temp.linux-x86_64-3.3-pydebug/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Modules/xxlimited.o
In file included from /mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Include/Python.h:68:0,
                 from /mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Modules/xxlimited.c:17:
/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Include/object.h:65:2: error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG


I think make should ignore this error unless you fix xxlimited.c sources.

----------
files: build.log
messages: 196534
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file31520/build.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18883>
_______________________________________

From report at bugs.python.org  Fri Aug 30 15:30:05 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 30 Aug 2013 13:30:05 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <1377869405.9.0.552472612228.issue18882@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

http://bugs.python.org/issue16500 is required to make work after fork from thread other than the main one.

----------
dependencies: +Add an 'atfork' module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18882>
_______________________________________

From report at bugs.python.org  Fri Aug 30 15:34:09 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Aug 2013 13:34:09 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1377865849.93.0.0483429571021.issue16853@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0-Hf9E2zwV8sk50V7dbZ79GxJR39UvJh6qvkj89T6Mdg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Hello,

> - What about Solaris' /dev/poll?

That should be pretty easy to add by someone who has access to a
Solaris box: I could use the buildbots, but it'd take a couple
iterations to get it right.

> - I'm not sure why in case of EINTR you retry with a different timeout; can't you just return []?

Because when I do:
selector.select(10)

I expect the selector to wait 10 seconds if no event occurs: the fact
that a signal comes in shouldn't break the contract made by the API,
i.e. that it will return when a FD is ready or the timeout expires.
Early return can lead to spurious errors: just imagine you send a
request to a busy server: it would be bad to raise a timeout error
just because the user put the client in the background with CTRL-Z
(which results in SIGSTOP).

> - this is probably because I'm paranoid about performances but given that select() method will be called repeatedly I would not use a decorator. Also, similarly to what has been done elsewhere in the stdlib, for "critical" parts I would recommend localizing variable access in order to minimize overhead as in:
>
>     def select(self, timeout=None):
>         ...
>         key_from_fd = self._key_from_fd
>         ready_append = ready.append
>         for fd in r | w:
>             ...
>             key = key_from_fd(fd)
>             if key:
>                 ready_append((key, events & key.events))

I find that localizing variables leads to unreadable code, and is tied
to the current CPython interpreter implementation: such optimizations
belong to the interpreter, not user code.

As for the decorator performance overhead, I don't think it weights
much compared to the cost of a syscall (+ GIL acquire/release):
with decorator:
$ ./python -m timeit -s "from selectors import DefaultSelector,
EVENT_WRITE; import os; s = DefaultSelector();
s.register(os.pipe()[1], EVENT_WRITE)" "s.select()"
100000 loops, best of 3: 3.69 usec per loop
without decorator:
$ ./python -m timeit -s "from selectors import DefaultSelector,
EVENT_WRITE; import os; s = DefaultSelector();
s.register(os.pipe()[1], EVENT_WRITE)" "s.select()"
100000 loops, best of 3: 3.52 usec per loop

That's a 4% overhead, with a single FD that's always ready (and I
suspect that most of the overhead is due to the call to time(), not
the decorator per se).

Also, I'll shortly propose a patch to handle EINTR within C code, so
those EINTR wrappers won't  be needed anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Fri Aug 30 15:39:46 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 30 Aug 2013 13:39:46 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1377869986.88.0.724591278826.issue16853@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

> That should be pretty easy to add by someone who has access to a
> Solaris box: I could use the buildbots, but it'd take a couple
> iterations to get it right.

I can probably help with that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Fri Aug 30 15:45:47 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Fri, 30 Aug 2013 13:45:47 +0000
Subject: [issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
Message-ID: <1377870347.55.0.997907560608.issue18884@psf.upfronthosting.co.za>


New submission from Martin Mokrejs:

It is not important why I had in this moment matplotlib not in sync with python itself whcih was configure using --with-pydebug ... but here I just want to show that maybe you do not test for memleaks using valgrind on import errors (maybe include such testcase into you tests).
Anyway, here is what I got:


==14007== Memcheck, a memory error detector
==14007== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==14007== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==14007== Command: /usr/bin/python2.7 blah.py
==14007== 
Traceback (most recent call last):
  File "blah.py", line 288, in <module>
    import pylab
  File "/usr/lib64/python2.7/site-packages/pylab.py", line 1, in <module>
    from matplotlib.pylab import *
  File "/usr/lib64/python2.7/site-packages/matplotlib/pylab.py", line 222, in <module>
    from matplotlib import mpl  # pulls in most modules
  File "/usr/lib64/python2.7/site-packages/matplotlib/mpl.py", line 1, in <module>
    from matplotlib import artist
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 7, in <module>
    from transforms import Bbox, IdentityTransform, TransformedBbox, \
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 35, in <module>
    from matplotlib._path import (affine_transform, count_bboxes_overlapping_bbox,
ImportError: /usr/lib64/python2.7/site-packages/matplotlib/_path.so: undefined symbol: _PyMem_DebugFree
[100070 refs]
==14007== 
==14007== HEAP SUMMARY:
==14007==     in use at exit: 6,303,492 bytes in 31,921 blocks
==14007==   total heap usage: 1,266,299 allocs, 1,234,378 frees, 179,304,947 bytes allocated
==14007== 
==14007== 40 bytes in 1 blocks are definitely lost in loss record 167 of 3,515
==14007==    at 0x4C2C63B: malloc (vg_replace_malloc.c:270)
==14007==    by 0x4EF1E8C: PyMem_Malloc (object.c:2343)
==14007==    by 0x10064848: initialize_builtin_datetime_metadata (arraytypes.c.src:3953)
==14007==    by 0x100719E2: set_typeinfo (arraytypes.c.src:4047)
==14007==    by 0x1016354E: initmultiarray (multiarraymodule.c:4057)
==14007==    by 0x4FB2661: _PyImport_LoadDynamicModule (importdl.c:53)
==14007==    by 0x4FAE3A7: load_module (import.c:1915)
==14007==    by 0x4FB07C1: import_submodule (import.c:2700)
==14007==    by 0x4FAFCC6: load_next (import.c:2515)
==14007==    by 0x4FAED8B: import_module_level (import.c:2224)
==14007==    by 0x4FAF320: PyImport_ImportModuleLevel (import.c:2288)
==14007==    by 0x4F78862: builtin___import__ (bltinmodule.c:49)

----------
components: Interpreter Core
messages: 196538
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18884>
_______________________________________

From report at bugs.python.org  Fri Aug 30 15:55:42 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 30 Aug 2013 13:55:42 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <1377870942.88.0.889170323179.issue18720@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

[Thanks, Guido]

Attaching patch with SOCK_* constants converted as well. The module globals are currently walked twice, once to extract AF_* and once SOCK_*. This is not a real performance problem, but should we fold it into a single loop that collects two dicts? The code will be less pretty but more efficient.

Another issue is _intenum_converter. Ethan - do you think it belongs in the enum module as a helper function or something of the sort?

----------
Added file: http://bugs.python.org/file31521/socket-intenum-af-type.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Fri Aug 30 15:56:03 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Aug 2013 13:56:03 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <1377870963.3.0.529678186848.issue18882@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> http://bugs.python.org/issue16500 is required to make work after
> fork from thread other than the main one.

No it isn't. Please take a look at _after_fork() in threading.py.

----------
dependencies:  -Add an 'atfork' module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18882>
_______________________________________

From report at bugs.python.org  Fri Aug 30 15:56:45 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Aug 2013 13:56:45 +0000
Subject: [issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
In-Reply-To: <1377870347.55.0.997907560608.issue18884@psf.upfronthosting.co.za>
Message-ID: <1377871005.88.0.748550989023.issue18884@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +haypo, pitrou, skrah
type:  -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18884>
_______________________________________

From report at bugs.python.org  Fri Aug 30 15:57:35 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 30 Aug 2013 13:57:35 +0000
Subject: [issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error
 Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS,
 and Py_REF_DEBUG
In-Reply-To: <1377869252.37.0.462052472279.issue18883@psf.upfronthosting.co.za>
Message-ID: <1377871055.34.0.623653704803.issue18883@psf.upfronthosting.co.za>


Stefan Krah added the comment:

A similar issue was closed, see msg157249. The error looks deliberate
to me, so let's close this, too.

----------
nosy: +skrah
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18883>
_______________________________________

From report at bugs.python.org  Fri Aug 30 15:58:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Aug 2013 13:58:34 +0000
Subject: [issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
In-Reply-To: <1377870347.55.0.997907560608.issue18884@psf.upfronthosting.co.za>
Message-ID: <1377871114.12.0.764772865619.issue18884@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18884>
_______________________________________

From report at bugs.python.org  Fri Aug 30 16:06:15 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Fri, 30 Aug 2013 14:06:15 +0000
Subject: [issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error
 Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS,
 and Py_REF_DEBUG
In-Reply-To: <1377869252.37.0.462052472279.issue18883@psf.upfronthosting.co.za>
Message-ID: <1377871575.15.0.518975723107.issue18883@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Uh. I don't understand. So did you want to say I should not run configure --with-pydebug in python 3.3 or what? I am fine if you fix the Makefile not to exit on this particular file. I am missing something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18883>
_______________________________________

From report at bugs.python.org  Fri Aug 30 16:08:23 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Aug 2013 14:08:23 +0000
Subject: [issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error
 Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS,
 and Py_REF_DEBUG
In-Reply-To: <1377869252.37.0.462052472279.issue18883@psf.upfronthosting.co.za>
Message-ID: <1377871703.11.0.0873941195994.issue18883@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm curious how this error gets triggered.  I build python --with-pydebug on Gentoo all the time, albeit from a checkout, and I've never seen it.  I'm imagining that means it is a Gentoo bug.  Well, not even really a bug, since Gentoo doesn't itself support emerging python in debug mode.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18883>
_______________________________________

From report at bugs.python.org  Fri Aug 30 16:10:31 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Fri, 30 Aug 2013 14:10:31 +0000
Subject: [issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error
 Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS,
 and Py_REF_DEBUG
In-Reply-To: <1377869252.37.0.462052472279.issue18883@psf.upfronthosting.co.za>
Message-ID: <1377871831.97.0.82985237099.issue18883@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

See for what I did to Gentoo: http://bugs.python.org/issue18843#msg196520

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18883>
_______________________________________

From report at bugs.python.org  Fri Aug 30 16:17:03 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Aug 2013 14:17:03 +0000
Subject: [issue14974] rename packaging.pypi to packaging.index
In-Reply-To: <1338502462.41.0.230255399861.issue14974@psf.upfronthosting.co.za>
Message-ID: <1377872223.54.0.466316124489.issue14974@psf.upfronthosting.co.za>


?ric Araujo added the comment:

The issue is moot now that packaging/distutils2 is stopped.

----------
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14974>
_______________________________________

From report at bugs.python.org  Fri Aug 30 16:18:02 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Aug 2013 14:18:02 +0000
Subject: [issue14914] pysetup installed distribute despite dry run option
 being specified
In-Reply-To: <1337957545.29.0.422035789743.issue14914@psf.upfronthosting.co.za>
Message-ID: <1377872282.33.0.0454787036654.issue14914@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Contrary to other issues that are relevant to distlib/pip/others, this one can be closed.

----------
resolution:  -> out of date
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14914>
_______________________________________

From report at bugs.python.org  Fri Aug 30 16:19:07 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 30 Aug 2013 14:19:07 +0000
Subject: [issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error
 Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS,
 and Py_REF_DEBUG
In-Reply-To: <1377869252.37.0.462052472279.issue18883@psf.upfronthosting.co.za>
Message-ID: <1377872347.25.0.569490233323.issue18883@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Martin, msg196534 shows that you are building with -DPy_LIMITED_API=1.
You can either use the limited API or --with-pydebug, but not both.

[As I said in the other issue, IMHO it is better to use a minimal set
of build options when reporting bugs.]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18883>
_______________________________________

From report at bugs.python.org  Fri Aug 30 16:23:22 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Fri, 30 Aug 2013 14:23:22 +0000
Subject: [issue18859] README.valgrind should mention --with-valgrind
In-Reply-To: <1377649189.0.0.381916551624.issue18859@psf.upfronthosting.co.za>
Message-ID: <1377872602.83.0.804233908636.issue18859@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Moreover, it should explain what that really does. One could think of several answers or even their combinations what this configure flag will really do:

a) python will run itself under valgrind, don't bother ever doing it yourself
b) you don't have to bother with uncommenting the lines in valgrind.supp
c) "make install" will install the valgrind.supp but you have to edit it on your own
d) you may use valgrind but don't use other tool replacing malloc(), like electric fence, DUMA, etc. You should be quite verbose how (in)compatible is this with other tools.

Or some combination of them?

valgrind docs say it won't work if a binary lacks debug symbols (wasn't compiled with -g). Initially I got mislead I though I have to convert my blah.py to blah.c using cython, compile that with "gcc -ggdb blah.c" and then I may run valgrind on the binary.

In the end, I don't understand why everybody has to remove the comment symbols from the valgrind-python.supp file at all. Why isn't that by default enabled?



I also suggest you mention right in the file other handy information because people quite likely get on this path while chasing memory corruption issues, maybe broken hardware:

1. Mention that python uses 256kB chunks by default.
2. Mention there exists --without-pymalloc as Tim explained me in http://bugs.python.org/issue18843#msg196492
3. Explain how to interpret those stacktraces one could get: http://bugs.python.org/issue18843#msg196481

Thank you!

----------
nosy: +mmokrejs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18859>
_______________________________________

From report at bugs.python.org  Fri Aug 30 16:34:04 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Fri, 30 Aug 2013 14:34:04 +0000
Subject: [issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error
 Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS,
 and Py_REF_DEBUG
In-Reply-To: <1377869252.37.0.462052472279.issue18883@psf.upfronthosting.co.za>
Message-ID: <1377873244.96.0.699438877851.issue18883@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Hmm, but I did not add -DPy_LIMITED_API=1. Python 2.7.5 can be compiled using same configuration. Going back to the build.log file I see:

configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --with-fpectl --enable-shared --disable-ipv6 --with-threads --infodir=${prefix}/share/info --mandir=${prefix}/share/man --with-computed-gotos --with-dbmliborder=gdbm --with-libc= --enable-loadable-sqlite-extensions --with-system-expat --with-system-ffi --with-pydebug --without-pymalloc --with-valgrind


I specified only "--with-pydebug --without-pymalloc --with-valgrind". So where does the limited API come from? Bug in configure.ac?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18883>
_______________________________________

From report at bugs.python.org  Fri Aug 30 16:39:59 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 30 Aug 2013 14:39:59 +0000
Subject: [issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error
 Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS,
 and Py_REF_DEBUG
In-Reply-To: <1377869252.37.0.462052472279.issue18883@psf.upfronthosting.co.za>
Message-ID: <1377873599.75.0.445872389991.issue18883@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Well, these look like Gentoo build flags. Did you or "emerge" or
anything else export CFLAGS in the shell?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18883>
_______________________________________

From report at bugs.python.org  Fri Aug 30 16:43:41 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 30 Aug 2013 14:43:41 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1377873821.13.0.0492128516385.issue18844@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

[Madison May]
>  - Should negative weights cause a ValueError to be raised, or should they be converted to 0s?
>  - Should passing a list full of zeros as the weights arg raise a ValueError or be treated as if no weights arg was passed?

Both those seem like clear error conditions to me, though I think it would be fine if the second condition produced a ZeroDivisionError rather than a ValueError.

I'm not 100% sold on the feature request.  For one thing, the direct implementation is going to be inefficient for repeated sampling, building the table of cumulative sums each time random.choice is called.  A more efficient approach for many use-cases would do the precomputation once, returning some kind of 'distribution' object from which samples can be generated.  (Walker's aliasing method is one route for doing this efficiently, though there are others.)  I agree that this is a commonly needed and commonly requested operation;  I'm just not convinced either that an efficient implementation fits well into the random module, or that it makes sense to add an inefficient implementation.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Fri Aug 30 16:49:52 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 30 Aug 2013 14:49:52 +0000
Subject: [issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error
 Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS,
 and Py_REF_DEBUG
In-Reply-To: <1377869252.37.0.462052472279.issue18883@psf.upfronthosting.co.za>
Message-ID: <1377874192.34.0.753250921605.issue18883@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I think I understand now: If you used the strategy from msg196520,
of course you get the Gentoo flags.

What you really should do is download a release or get a checkout
from hg.python.org and build that _without_ using "emerge".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18883>
_______________________________________

From report at bugs.python.org  Fri Aug 30 16:54:55 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Fri, 30 Aug 2013 14:54:55 +0000
Subject: [issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error
 Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS,
 and Py_REF_DEBUG
In-Reply-To: <1377869252.37.0.462052472279.issue18883@psf.upfronthosting.co.za>
Message-ID: <1377874495.47.0.0939188732586.issue18883@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

So I conclude that you want to say that some of the configure flags is wrong? Which? I can surely report that at Gentoo. I still think Makefile should be changed so that it make does not even try to compile xxlimited.c if -DPy_LIMITED_API=1 is in CFLAGS regardless how that happened.

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/python/

Look into the python-3.3.2-r2.ebuild file for what it does, and how does differ from 3.7.5-r2.ebuild which can be compiled fine through emerge abd thsoe 3 configure arguments I requested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18883>
_______________________________________

From report at bugs.python.org  Fri Aug 30 16:58:46 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 30 Aug 2013 14:58:46 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1377870942.88.0.889170323179.issue18720@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJojnPCVkrpGcyEezVHf9hnO+5U2Xv+7CsB9eqBQ5uXcA@mail.gmail.com>


Guido van Rossum added the comment:

I prefer two prettier loops over one less pretty one in this case. No
opinion about _intenum_converter yet. (IMO refactoring can always be lazy,
i.e. after you have multiple copies of the same code there's time to
consider whether you should unify them and what the pros and cons are.)

On Fri, Aug 30, 2013 at 6:55 AM, Eli Bendersky <report at bugs.python.org>wrote:

>
> Eli Bendersky added the comment:
>
> [Thanks, Guido]
>
> Attaching patch with SOCK_* constants converted as well. The module
> globals are currently walked twice, once to extract AF_* and once SOCK_*.
> This is not a real performance problem, but should we fold it into a single
> loop that collects two dicts? The code will be less pretty but more
> efficient.
>
> Another issue is _intenum_converter. Ethan - do you think it belongs in
> the enum module as a helper function or something of the sort?
>
> ----------
> Added file:
> http://bugs.python.org/file31521/socket-intenum-af-type.6.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue18720>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18720>
_______________________________________

From report at bugs.python.org  Fri Aug 30 17:02:35 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Aug 2013 15:02:35 +0000
Subject: [issue18885] handle EINTR in the stdlib
Message-ID: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

As discussed in http://mail.python.org/pipermail/python-dev/2013-August/128204.html, I think that we shouldn't let EINTR leak to Python code: it should be handled properly by the C code, so that users (and the Python part of the stdlib) don't have to worry about this low-level historical nuisance.

For code that doesn't release the GIL, we could simply use this glibc macro:
# define TEMP_FAILURE_RETRY(expression) \
  (__extension__                                                              \
    ({ long int __result;                                                     \
       do __result = (long int) (expression);                                 \
       while (__result == -1L && errno == EINTR);                             \
       __result; }))
#endif

Now, I'm not sure about how to best handle this for code that releases the GIL.

Basically:

    Py_BEGIN_ALLOW_THREADS
    pid = waitpid(pid, &status, options);
    Py_END_ALLOW_THREADS

should become

begin_handle_eintr:
        Py_BEGIN_ALLOW_THREADS
        pid = waitpid(pid, &status, options);
        Py_END_ALLOW_THREADS

        if (pid < 0 && errno == EINTR) {
            if (PyErr_CheckSignals())
                return NULL;
            goto begin_handle_eintr;
        }

Should we do this with a macro?

If yes, should it be a new one that should be placed around Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS (like BEGIN_SELECT_LOOP in selectmodule.c) or could we have a single macro that would do both (i.e. release the GIL / reacquire the GIL, and try again in case of EINTR, unless a signal handler raised an exception)?

>From a cursory look, the main files affected would be:
Modules/fcntlmodule.c
Modules/ossaudiodev.c
Modules/posixmodule.c
Modules/selectmodule.c
Modules/selectmodule.c
Modules/signalmodule.c
Modules/socketmodule.c
Modules/syslogmodule.c

----------
messages: 196555
nosy: neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: handle EINTR in the stdlib
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18885>
_______________________________________

From report at bugs.python.org  Fri Aug 30 17:02:58 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Aug 2013 15:02:58 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1377874978.49.0.800114831768.issue18885@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
nosy: +haypo, pitrou, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18885>
_______________________________________

From report at bugs.python.org  Fri Aug 30 17:07:01 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Aug 2013 15:07:01 +0000
Subject: [issue18883] python-3.3.2-r2: Modules/xxlimited.c:17:error: #error
 Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS,
 and Py_REF_DEBUG
In-Reply-To: <1377869252.37.0.462052472279.issue18883@psf.upfronthosting.co.za>
Message-ID: <1377875221.15.0.670937631339.issue18883@psf.upfronthosting.co.za>


R. David Murray added the comment:

Python2 doesn't support the limited ABI, so that flag is a noop for 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18883>
_______________________________________

From report at bugs.python.org  Fri Aug 30 17:13:53 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Aug 2013 15:13:53 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377856407.33.0.585951271385.issue18843@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM219f7PZBoALm=5U1+d_A_ZmVMc7NpWedS47AJ-2xEeVg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

2013/8/30 Martin Mokrejs <report at bugs.python.org>:
> Per comment from Charles-Fran?ois, so you mean that this single-bit change won't be caught by valgrind, right? Why does not memtest86+ detect that? Could python when compiled with the --with-pydebug print also physical, hardware address of the wrong value? That would be really helpful here! Thanks.

I mean that in the vast majority of cases, a single bit flip is due to
a hardware error.
That can be due to faulty RAM, electric noise, cosmic rays...

Software-induced memory corruptions generally corrupt at least a byte.

Do you reproduce the crash systematically, or is it random?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 18:03:30 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Aug 2013 16:03:30 +0000
Subject: [issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
In-Reply-To: <1377870347.55.0.997907560608.issue18884@psf.upfronthosting.co.za>
Message-ID: <1377878610.53.0.292325648092.issue18884@psf.upfronthosting.co.za>


STINNER Victor added the comment:

According to traces, the leak does not come from Python but matplotlib. Please report the issue to matplotlib bug tracker.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18884>
_______________________________________

From report at bugs.python.org  Fri Aug 30 18:08:54 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 30 Aug 2013 16:08:54 +0000
Subject: [issue8786] Add support for IEEE 754 contexts to decimal module.
In-Reply-To: <1274524113.24.0.215320207255.issue8786@psf.upfronthosting.co.za>
Message-ID: <1377878934.78.0.919167153593.issue8786@psf.upfronthosting.co.za>


Stefan Krah added the comment:

BTW, in _decimal the feature can already be enabled with:

./configure CFLAGS=-DEXTRA_FUNCTIONALITY


>>> IEEEContext(DECIMAL128)
Context(prec=34, rounding=ROUND_HALF_EVEN, Emin=-6143, Emax=6144, capitals=1, clamp=1, flags=[], traps=[])
>>> IEEEContext(DECIMAL64)
Context(prec=16, rounding=ROUND_HALF_EVEN, Emin=-383, Emax=384, capitals=1, clamp=1, flags=[], traps=[])
>>> IEEEContext(DECIMAL32)
Context(prec=7, rounding=ROUND_HALF_EVEN, Emin=-95, Emax=96, capitals=1, clamp=1, flags=[], traps=[])
>>>


>>> IEEEContext(512)
Context(prec=142, rounding=ROUND_HALF_EVEN, Emin=-103079215103, Emax=103079215104, capitals=1, clamp=1, flags=[], traps=[])
>>> IEEEContext(1024)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: argument must be a multiple of 32, with a maximum of 512
>>>

Of course this isn't the official API yet, but I think it's
reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8786>
_______________________________________

From report at bugs.python.org  Fri Aug 30 18:21:54 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Fri, 30 Aug 2013 16:21:54 +0000
Subject: [issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
In-Reply-To: <1377870347.55.0.997907560608.issue18884@psf.upfronthosting.co.za>
Message-ID: <1377879714.35.0.90669734796.issue18884@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Why do you think so? My point is that this happens when import fails. But python is at fault and should handle import errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18884>
_______________________________________

From report at bugs.python.org  Fri Aug 30 18:32:53 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 30 Aug 2013 16:32:53 +0000
Subject: [issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
In-Reply-To: <1377870347.55.0.997907560608.issue18884@psf.upfronthosting.co.za>
Message-ID: <1377880373.63.0.0952386975101.issue18884@psf.upfronthosting.co.za>


Tim Peters added the comment:

The matplotlib people won't care about this one either.  matplotlib allocated the memory, and the error message at the end says it's _trying_ to call _PyMem_DebugFree (which may well be trying to release the memory), but the binaries aren't compatible:  _PyMem_DebugFree doesn't exist.  That's on you, not on matplotlib or on Python - you're mixing together binaries that can't possibly work together.

So if this bug is re-opened, it should be assigned to you to fix it ;-)

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18884>
_______________________________________

From report at bugs.python.org  Fri Aug 30 18:34:20 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Aug 2013 16:34:20 +0000
Subject: [issue18418] Thread.isAlive() sometimes True after fork
In-Reply-To: <1373408030.66.0.77258289483.issue18418@psf.upfronthosting.co.za>
Message-ID: <1377880460.56.0.949772477632.issue18418@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
nosy: +pitrou
stage: patch review -> commit review
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18418>
_______________________________________

From report at bugs.python.org  Fri Aug 30 18:57:53 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 30 Aug 2013 16:57:53 +0000
Subject: [issue18438] Obsolete url in comment inside decimal module
In-Reply-To: <1373686911.48.0.750703855786.issue18438@psf.upfronthosting.co.za>
Message-ID: <1377881873.99.0.0450593393628.issue18438@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Wikipedia sounds good. Let's avoid linking directly to "free" versions. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18438>
_______________________________________

From report at bugs.python.org  Fri Aug 30 19:28:11 2013
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 30 Aug 2013 17:28:11 +0000
Subject: [issue18852] site.py does not handle readline.__doc__ being None
In-Reply-To: <1377609308.01.0.92318264163.issue18852@psf.upfronthosting.co.za>
Message-ID: <1377883691.35.0.806508001479.issue18852@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Here's a patch with a comment about using pyreadline on Windows.

Should the note in the readline documentation[1] be updated?

[1] http://docs.python.org/3.4/library/readline.html

(See also issue 5845 and msg123703)

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31522/issue18852.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18852>
_______________________________________

From report at bugs.python.org  Fri Aug 30 19:33:51 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Aug 2013 17:33:51 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1377884031.22.0.866794353502.issue18709@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Fri Aug 30 19:41:01 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Fri, 30 Aug 2013 17:41:01 +0000
Subject: [issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
In-Reply-To: <1377870347.55.0.997907560608.issue18884@psf.upfronthosting.co.za>
Message-ID: <1377884461.19.0.321093266103.issue18884@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Of course I did recompile matplotlib to use the recompiled python with debug ABI. I just don't understand why if something is not leaded why a memleak has to happen.

Anyway, now my application using the recompiled matplotlib baffled this through valgrind as well. An there was no ImportError: ;-)


==17489== 40 bytes in 1 blocks are definitely lost in loss record 718 of 5,487
==17489==    at 0x4C2C63B: malloc (vg_replace_malloc.c:270)
==17489==    by 0x4EF1E8C: PyMem_Malloc (object.c:2343)
==17489==    by 0x10064848: initialize_builtin_datetime_metadata (arraytypes.c.src:3953)
==17489==    by 0x100719E2: set_typeinfo (arraytypes.c.src:4047)
==17489==    by 0x1016354E: initmultiarray (multiarraymodule.c:4057)
==17489==    by 0x4FB2661: _PyImport_LoadDynamicModule (importdl.c:53)
==17489==    by 0x4FAE3A7: load_module (import.c:1915)
==17489==    by 0x4FB07C1: import_submodule (import.c:2700)
==17489==    by 0x4FAFCC6: load_next (import.c:2515)
==17489==    by 0x4FAED8B: import_module_level (import.c:2224)
==17489==    by 0x4FAF320: PyImport_ImportModuleLevel (import.c:2288)
==17489==    by 0x4F78862: builtin___import__ (bltinmodule.c:49)


This is probably because I also added --without-pymalloc as you wanted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18884>
_______________________________________

From report at bugs.python.org  Fri Aug 30 19:43:31 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 30 Aug 2013 17:43:31 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes
 inside	subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1377884031.27.0.55130099353.issue18709@psf.upfronthosting.co.za>
Message-ID: <a2eb6e93-72de-491c-9564-5fff786f0881@email.android.com>


Christian Heimes added the comment:

It's not fixed in 3.1 and 3.2 yet. Please re-open the issue. I can't do it because I'm not at home.

"Charles-Fran?ois Natali" <report at bugs.python.org> schrieb:
>
>Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:
>
>
>----------
>resolution:  -> fixed
>stage: patch review -> committed/rejected
>status: open -> closed
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue18709>
>_______________________________________

----------
title: SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238) -> SSL module fails to handle NULL bytes inside	subjectAltNames general names (CVE-2013-4238)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Fri Aug 30 19:44:42 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Aug 2013 17:44:42 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes
 inside	subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1377884682.56.0.885665049552.issue18709@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Oops.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Fri Aug 30 19:45:38 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Fri, 30 Aug 2013 17:45:38 +0000
Subject: [issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
In-Reply-To: <1377870347.55.0.997907560608.issue18884@psf.upfronthosting.co.za>
Message-ID: <1377884738.28.0.371231913461.issue18884@psf.upfronthosting.co.za>


Changes by Martin Mokrejs <mmokrejs at users.sourceforge.net>:


Added file: http://bugs.python.org/file31523/valgrind_python275_without-pymalloc.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18884>
_______________________________________

From report at bugs.python.org  Fri Aug 30 20:16:30 2013
From: report at bugs.python.org (Madison May)
Date: Fri, 30 Aug 2013 18:16:30 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1377886590.31.0.127357175614.issue18844@psf.upfronthosting.co.za>


Madison May added the comment:

[Mark Dickinson]
> Both those seem like clear error conditions to me, though I think it would be fine if the second condition produced a ZeroDivisionError rather than a ValueError.

Yeah, in hindsight it makes sense that both of those conditions should raise errors.  After all: "Explicit is better than implicit".

As far as optimization goes, could we potentially use functools.lru_cache to cache the cumulative distribution produced by the weights argument and optimize repeated sampling? 

Without @lru_cache:
>>> timeit.timeit("x = choice(list(range(100)), list(range(100)))", setup="from random import choice", number=100000)
36.7109281539997

With @lru_cache(max=128):
>>> timeit.timeit("x = choice(list(range(100)), list(range(100)))", setup="from random import choice", number=100000)
6.6788657720007905

Of course it's a contrived example, but you get the idea.

Walker's aliasing method looks intriguing.  I'll have to give it a closer look.  

I agree that an efficient implementation would be preferable but would feel out of place in random because of the return type.  I still believe a relatively inefficient addition to random.choice would be valuable, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Fri Aug 30 20:20:44 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 30 Aug 2013 18:20:44 +0000
Subject: [issue18852] site.py does not handle readline.__doc__ being None
In-Reply-To: <1377609308.01.0.92318264163.issue18852@psf.upfronthosting.co.za>
Message-ID: <1377886844.17.0.721951508384.issue18852@psf.upfronthosting.co.za>


Ned Deily added the comment:

The use of libedit is not restricted to OS X; in particular, some other BSD-derived distributions use it.  There are some other open issues regarding generalization of support for libedit.  So I don't think the proposed comments should be added to site.py.  The docs for the readline module do not give a detailed code example (yet) so there's nothing to update there (yet).

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18852>
_______________________________________

From report at bugs.python.org  Fri Aug 30 20:44:06 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 30 Aug 2013 18:44:06 +0000
Subject: [issue18884] python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
In-Reply-To: <1377870347.55.0.997907560608.issue18884@psf.upfronthosting.co.za>
Message-ID: <1377888246.48.0.902331487535.issue18884@psf.upfronthosting.co.za>


Tim Peters added the comment:

Now you have something to show the matplotlib folks - although they're not likely to get excited about leaking 40 bytes.

There is nothing Python can do about this.  matplotlib is responsible for free'ing the memory matplotlib allocates, just as Python is responsible for free'ing the memory Python allocates.  If _you_ wrote a C extension module, and did

char *p = (char *)malloc(40);

and never did a free(p) later, it would be the same kind of thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18884>
_______________________________________

From report at bugs.python.org  Fri Aug 30 21:05:39 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 30 Aug 2013 19:05:39 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377889539.57.0.907335687887.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

Martin, would it be possible to borrow someone else's machine and try to reproduce this?  If you can, that would greatly reduce the probability of this being a HW error.  It would also leave us with an exact set of commands to share so others can try it on their boxes.

It's true that SW memory corruption usually affects several contiguous bytes, but "usually" != "always" ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 21:28:07 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Fri, 30 Aug 2013 19:28:07 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377890887.98.0.0959367704998.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

I think it would be of tremendous help if python reported the physical memory address though do not know how much work is that for you. I already said that, I wonder why memtest86+ could not find an error, I even tried other tools for that. Could --with-pydebug immediately after writing those pad bytes try to read them back, just to make sure they are readable? Theoretically one could catch the wrong bit of memory immediately.

It is random, I think CPU must be fully loaded for a long while, plus something unknown has to kick in. Maybe that has to heat up the memory modules to cause the failure. My motherboard is already 3rd but doubt it is at fault, except that the SandyBridge chip is bad by design. Was replaced few days ago with CPU cooler (was the main reason for technician to come). I take that replacing motherboard was a nice offer from Dell. I would instead think that maybe CPU is heating too much.

BIOS is weird. ACPI and PCIe ASPM are exploiting Linux kernel hotplug support and PCI developers are puzzled. I experience that SandyBridge resets e.g. its USB2.0 controller if there was a hotplug even on some of its other root ports (express card was inserted/ejected). But in overall I don't think it is a bad deal and it works. These exceptional glitches are I think a software error or BIOS error. It just wouldn't be running all the days and nights. No, it is not overheated, at least not now with the replaced cooler.

I can put in other memory module (with which I bought the laptop from Dell). Other than that, hmm ... I could take out the hard drive and attach it to some other computer, boot from Live-DVD ... the problem is I need a lot of RAM for some of my stuff and it would have to be relatively same CPU type (I compiled binaries with avx). Yes, the emerge crash definitely was another case, I could hope to get that happen on even 1GB RAM machine, sure. I just don't have a testcase for that to trigger. I tried to stitch something but no, I probably coded something not going in the right direction. If you would have the time to stitch down some test for me to execute with the garbage collector calls, it would be probably the best.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 22:37:30 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Aug 2013 20:37:30 +0000
Subject: [issue18886] BytesGenerator does not handle 'binary' CTE correctly
Message-ID: <1377895050.78.0.441930672492.issue18886@psf.upfronthosting.co.za>


New submission from R. David Murray:

ByteGenerator will assume that it can change any linesep characters to the linesep being used for the general message serialization, even if the content transfer encoding is 'binary'.  This is incorrect, as existing \r and \n characters in binary parts must be retained exactly as is.

----------
components: email
messages: 196572
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: BytesGenerator does not handle 'binary' CTE correctly
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18886>
_______________________________________

From report at bugs.python.org  Fri Aug 30 22:52:25 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Aug 2013 20:52:25 +0000
Subject: [issue18826] reversed() requires a sequence - Could work on any
 iterator?
In-Reply-To: <1377371302.25.0.787358043575.issue18826@psf.upfronthosting.co.za>
Message-ID: <1377895945.31.0.366216635706.issue18826@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The two cases are not parallel.
  a = sorted(b)
abbreviates
  a = list(b)
  a.sorted()
which occurred often enough to be a nuisance. With this proposal,
  a = reversed(b)
would abbreviate
  a = reversed(list(b))
which is probably less common and certainly less obnoxious than the two lines condensed by sorted.

A second problem: reversed already has a fallback default if (a presumably more efficient or effective) b.__reversed__ does not exit:

n = len(b)
a = [None]*n
for i,j in enumerate(range(n-1, -1, -1)): # reversed(range(n))
  a[i] = b[j]

(I believe this is more efficient, at least in C, than
  a = []
  for i in range(len(b)-1, -1, -1):
    a.append(b[i])
but it is hard to know.)

At what point, and under what conditions, would you introduce the second fallback?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18826>
_______________________________________

From report at bugs.python.org  Fri Aug 30 23:00:47 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Aug 2013 21:00:47 +0000
Subject: [issue18831] importlib.import_module() bypasses builtins.__import__
In-Reply-To: <1377443801.78.0.926402532335.issue18831@psf.upfronthosting.co.za>
Message-ID: <1377896447.11.0.86952117694.issue18831@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The discrepancy between doc and code should be eliminated. In this case, it seems the doc should be changed (in 3.3 as well). Would 'not' in the right place suffice?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18831>
_______________________________________

From report at bugs.python.org  Fri Aug 30 23:04:13 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 30 Aug 2013 21:04:13 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1377896653.19.0.752400161032.issue16853@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

I'm playing with devpoll on Open Solaris and it seems it works exactly as poll(). Basically a copy & paste of PollSelector class with a different self._poll attribute will suffice.
With dev/poll support you now have 3 classes (PollSelector, EpollSelector, DevpollSelector) which look basically the same except for very little details. It looks like there's space for some code reuse / refactoring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Fri Aug 30 23:14:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Aug 2013 21:14:53 +0000
Subject: [issue18418] Thread.isAlive() sometimes True after fork
In-Reply-To: <1373408030.66.0.77258289483.issue18418@psf.upfronthosting.co.za>
Message-ID: <1377897293.35.0.818799142085.issue18418@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Well... I can't say anything except that the patch looks harmless.
It's a pity the test failure is hard to trigger, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18418>
_______________________________________

From report at bugs.python.org  Fri Aug 30 23:14:54 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Aug 2013 21:14:54 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1377897294.76.0.771571778444.issue18840@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

For the tutorial, I agree with presenting json rather than pickle for all the reasons given, with pickle mentioned in a paragraph at the end (more powerful, more dangerous, see warning in manual before using).

----------
nosy: +terry.reedy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Fri Aug 30 23:22:08 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 30 Aug 2013 21:22:08 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377897728.39.0.585196238039.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

OK, it sounds to me like you do not have a reproducible test case, of any kind.  It that's true, this bug report isn't going anywhere :-(

Python isn't a memory-testing program, so it would be insanely inefficient for it to (for example) read up every byte it writes, just to make sure the memory isn't bad.  If you want to alter the source of _your_ Python to do that, fine!  It won't go into the official distribution, but it might help you.

For the same reason, core Python won't go into the business of sorting out various kinds of memory addresses.  User-level code (including Python) works with the virtual (logical) addresses the operating system gives it.  For a hint of some of the difficulties in going deeper than that, here's a note from Linus Torvalds:

    http://www.tldp.org/LDP/khg/HyperNews/get/devices/addrxlate.html

About "If you would have the time to stitch down some test for me to execute with the garbage collector calls, it would be probably the best."  I'm not sure what you're suggesting there.  That we write a Python program that tries to trigger errors in your BIOS?  LOL - not likely ;-)

If you want to force a lot of allocations, deallocations, and gc runs, something like this will do it:

"""
def stress():
    import gc

    class C(object):
        def __init__(self):
            self.loop = self

    N = 500000
    d = dict((C(), C()) for i in xrange(N))
    j = 0
    while 1:
        for i in xrange(N // 2):
            d.popitem()
        for i in xrange(N // 2):
            d[C()] = C()
        j += 1
        if j % 10 == 0:
            print j
            gc.set_debug(gc.DEBUG_STATS)
            gc.collect()
            gc.set_debug(0)

stress()
"""

Setting N larger will make it consume more RAM.  The output is essentially meaningless, produced just so you know it's still running.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Fri Aug 30 23:27:16 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Aug 2013 21:27:16 +0000
Subject: [issue18845] 2.7.5-r2: Fatal Python error: Segmentation fault
In-Reply-To: <1377546426.38.0.266867499434.issue18845@psf.upfronthosting.co.za>
Message-ID: <1377898036.63.0.0654413447891.issue18845@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think this should be closed as extremely likely to be a matplotlib error.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18845>
_______________________________________

From report at bugs.python.org  Fri Aug 30 23:34:28 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Aug 2013 21:34:28 +0000
Subject: [issue18855] Inconsistent README filenames
In-Reply-To: <1377616570.1.0.108273179071.issue18855@psf.upfronthosting.co.za>
Message-ID: <1377898468.3.0.228623187288.issue18855@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

README.txt is also used in lib/idlelib and lib/idlelib/idle_test. In the latter case, I was told to use this.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18855>
_______________________________________

From report at bugs.python.org  Fri Aug 30 23:34:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Aug 2013 21:34:38 +0000
Subject: [issue18418] Thread.isAlive() sometimes True after fork
In-Reply-To: <1373408030.66.0.77258289483.issue18418@psf.upfronthosting.co.za>
Message-ID: <3cRYqf1050z7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset ba54011aa295 by Charles-Fran?ois Natali in branch '2.7':
Issue #18418: After fork(), reinit all threads states, not only active ones.
http://hg.python.org/cpython/rev/ba54011aa295

New changeset 29fce7f31539 by Charles-Fran?ois Natali in branch '3.3':
Issue #18418: After fork(), reinit all threads states, not only active ones.
http://hg.python.org/cpython/rev/29fce7f31539

New changeset 8f39e2f987fb by Charles-Fran?ois Natali in branch 'default':
Issue #18418: After fork(), reinit all threads states, not only active ones.
http://hg.python.org/cpython/rev/8f39e2f987fb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18418>
_______________________________________

From report at bugs.python.org  Fri Aug 30 23:45:58 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Aug 2013 21:45:58 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <3cRZ4j2wD4z7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 43749cb6bdbd by Antoine Pitrou in branch '2.7':
Issue #18851: Avoid a double close of subprocess pipes when the child process fails starting.
http://hg.python.org/cpython/rev/43749cb6bdbd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Fri Aug 30 23:55:35 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Aug 2013 21:55:35 +0000
Subject: [issue18853] Got ResourceWarning unclosed file when running
 Lib/shlex.py demo
In-Reply-To: <1377612267.45.0.680080135941.issue18853@psf.upfronthosting.co.za>
Message-ID: <1377899735.13.0.236971715346.issue18853@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think the warning should be silenced on all versions where it occurs. There is no real problem here, but there can be with multiple opens without close on non-refcounted interpreters. Patch looks good but I have not tried it.

----------
nosy: +terry.reedy
stage:  -> patch review
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18853>
_______________________________________

From report at bugs.python.org  Fri Aug 30 23:56:13 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 30 Aug 2013 21:56:13 +0000
Subject: [issue18845] 2.7.5-r2: Fatal Python error: Segmentation fault
In-Reply-To: <1377546426.38.0.266867499434.issue18845@psf.upfronthosting.co.za>
Message-ID: <1377899773.51.0.13303483531.issue18845@psf.upfronthosting.co.za>


Tim Peters added the comment:

As issue 18843 has evolved, seems more likely now that it's flaky HW, but agreed in any case there's really no evidence of a Python problem here.  So closing it.  Martin, we can revisit this if there's real progress on the other issue.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18845>
_______________________________________

From report at bugs.python.org  Fri Aug 30 23:58:57 2013
From: report at bugs.python.org (Madison May)
Date: Fri, 30 Aug 2013 21:58:57 +0000
Subject: [issue18853] Got ResourceWarning unclosed file when running
 Lib/shlex.py demo
In-Reply-To: <1377612267.45.0.680080135941.issue18853@psf.upfronthosting.co.za>
Message-ID: <1377899937.87.0.742235154108.issue18853@psf.upfronthosting.co.za>


Madison May added the comment:

The patch LGTM as well.

ResourceWarning was silenced after applying patch when tested on my machine.

----------
nosy: +madison.may

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18853>
_______________________________________

From report at bugs.python.org  Sat Aug 31 00:12:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Aug 2013 22:12:48 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <3cRZgg4sFQz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset c11754defe1c by Antoine Pitrou in branch '3.3':
Forward port new tests from Issue #18851.
http://hg.python.org/cpython/rev/c11754defe1c

New changeset 290ca31d4cfe by Antoine Pitrou in branch 'default':
Forward port new tests from Issue #18851.
http://hg.python.org/cpython/rev/290ca31d4cfe

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Sat Aug 31 00:13:10 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 30 Aug 2013 22:13:10 +0000
Subject: [issue18831] importlib.import_module() bypasses builtins.__import__
In-Reply-To: <1377443801.78.0.926402532335.issue18831@psf.upfronthosting.co.za>
Message-ID: <1377900790.27.0.0256577387598.issue18831@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Not sure what doc discrepancy you are talking about, Terry. The docs for importlib are totally accurate which means no one has been accidentally mislead by them. This bug is about whether importlib.import_module() bypassing builtins.__import__ is a big enough deal to change or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18831>
_______________________________________

From report at bugs.python.org  Sat Aug 31 00:13:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Aug 2013 22:13:48 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1377900828.79.0.0946585304731.issue18851@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Committed after applying Charles-Fran?ois's suggested fixes. Thanks!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18851>
_______________________________________

From report at bugs.python.org  Sat Aug 31 00:16:59 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Aug 2013 22:16:59 +0000
Subject: [issue17224] can not open idle in python 2.7.3
In-Reply-To: <1361176830.93.0.935966223453.issue17224@psf.upfronthosting.co.za>
Message-ID: <1377901019.32.0.0705288403934.issue17224@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17224>
_______________________________________

From report at bugs.python.org  Sat Aug 31 00:23:12 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 30 Aug 2013 22:23:12 +0000
Subject: [issue18823] Idle: use pipes instead of sockets to talk with user
 subprocess
In-Reply-To: <1377300904.13.0.124289838176.issue18823@psf.upfronthosting.co.za>
Message-ID: <1377901392.19.0.964087839214.issue18823@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18823>
_______________________________________

From report at bugs.python.org  Sat Aug 31 00:25:00 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 30 Aug 2013 22:25:00 +0000
Subject: [issue18855] Inconsistent README filenames
In-Reply-To: <1377616570.1.0.108273179071.issue18855@psf.upfronthosting.co.za>
Message-ID: <1377901500.27.0.768675263228.issue18855@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18855>
_______________________________________

From report at bugs.python.org  Sat Aug 31 00:26:49 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Aug 2013 22:26:49 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <3cRZzs0gppz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset acc7439b1406 by Antoine Pitrou in branch 'default':
Issue #18756: os.urandom() now uses a lazily-opened persistent file descriptor, so as to avoid using many file descriptors when run in parallel from multiple threads.
http://hg.python.org/cpython/rev/acc7439b1406

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Sat Aug 31 00:27:01 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Aug 2013 22:27:01 +0000
Subject: [issue18877] tkinter askopenfilenames does not work in Windows
 library folder
In-Reply-To: <1377802367.69.0.551472579776.issue18877@psf.upfronthosting.co.za>
Message-ID: <1377901621.18.0.523051272859.issue18877@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

There was a issue about people not being able to open windows 'library' files from Idle, but it was determined not to be an Idle problem. I cannot find it now. The outcome may have been that this was presumed to be a tk bug, but your report about the alternate dialog is interesting. it.

----------
nosy: +terry.reedy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18877>
_______________________________________

From report at bugs.python.org  Sat Aug 31 00:27:24 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Aug 2013 22:27:24 +0000
Subject: [issue18887] test_multiprocessing.test_connection failure
Message-ID: <1377901644.63.0.505553589029.issue18887@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

http://buildbot.python.org/all/builders/x86%20Windows7%202.7/builds/2211/steps/test/logs/stdio

"""
test_ignore_listener (test.test_multiprocessing.TestIgnoreEINTR) ... test test_multiprocessing failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\test\test_multiprocessing.py", line 1524, in test_connection
    conn.send_bytes(really_big_msg)
ValueError: Cannnot send 16777216 bytes over connection
"""

----------
components: Tests
messages: 196591
nosy: neologix, sbt
priority: normal
severity: normal
status: open
title: test_multiprocessing.test_connection failure
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18887>
_______________________________________

From report at bugs.python.org  Sat Aug 31 00:27:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Aug 2013 22:27:37 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1377901657.27.0.583500675444.issue18756@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, I've committed the patch for the lazy opening approach.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Sat Aug 31 00:30:07 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Aug 2013 22:30:07 +0000
Subject: [issue18875] Automatic insertion of the closing parentheses, brackets,
 and braces
In-Reply-To: <1377777498.6.0.468253349222.issue18875@psf.upfronthosting.co.za>
Message-ID: <1377901807.56.0.995309139015.issue18875@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I have thought about such a feature also. I would at least like to have patch to try it out. Possible? I suspect so.

----------
nosy: +terry.reedy
versions: +Python 3.4 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18875>
_______________________________________

From report at bugs.python.org  Sat Aug 31 01:04:50 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Aug 2013 23:04:50 +0000
Subject: [issue18831] importlib.import_module() bypasses builtins.__import__
In-Reply-To: <1377443801.78.0.926402532335.issue18831@psf.upfronthosting.co.za>
Message-ID: <1377903890.8.0.592678900504.issue18831@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Perhaps I am confused because I did not notice the switch between builtins.__import__ and importlib.__import__ -- and I do not know the relation between the two, if indeed they are two and not one. What I read and understood is
* importlib.import_module doc say it calls ???.__import__;
* importlib.import_module code does not call ???.__import__;
it instead calls _gcd_import (for good reasons).

If the claim and reality disagree, because ??? is effectively the same in both statements, then either code or doc could be changed.

If importlib.__import__ and builtins.__import__ are different objects, and the doc is clear about that, then no one should expect that 'calls importlib.__import__' means 'calls builtins.__import__'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18831>
_______________________________________

From report at bugs.python.org  Sat Aug 31 01:07:27 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Fri, 30 Aug 2013 23:07:27 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1377904047.08.0.366787760561.issue18840@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

How about we simply add the warning from http://docs.python.org/3/library/pickle.html#module-pickle to the beginning (or end) of the section?  The Official Python Tutorial has always assumed a certain programmer's competence.  It's up to them if they want to use the module or not.

----------
nosy: +anikom15

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Sat Aug 31 01:22:21 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 30 Aug 2013 23:22:21 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <CAH_1eM0-Hf9E2zwV8sk50V7dbZ79GxJR39UvJh6qvkj89T6Mdg@mail.gmail.com>
Message-ID: <CAP7+vJKkezU8Nmu458PhNGcQTctU1oS7VyU2KTpksfmy6SBazQ@mail.gmail.com>


Guido van Rossum added the comment:

On Fri, Aug 30, 2013 at 6:34 AM, Charles-Fran?ois Natali
<report at bugs.python.org> wrote:
[Giampaolo Rodola']
> > - I'm not sure why in case of EINTR you retry with a different timeout; can't you just return []?
>
> Because when I do:
> selector.select(10)
>
> I expect the selector to wait 10 seconds if no event occurs: the fact
> that a signal comes in shouldn't break the contract made by the API,
> i.e. that it will return when a FD is ready or the timeout expires.

I disagree. In this case it is almost certain that there is already
some kind of retry loop around the Selector.select() call, so there is
no need for the retry. (Certainly this is how it happens in Tulip.) In
the case of select() the contract is actually quite clear, and there
shouldn't be any problem with returning an empty list early. (This is
quite different from e.g. an interrupted read() or recv() call, where
there is no existing return value that you can return safely, since
their users don't expect None and will usually treat an empty string
as an EOF indicator.)

> Early return can lead to spurious errors: just imagine you send a
> request to a busy server: it would be bad to raise a timeout error
> just because the user put the client in the background with CTRL-Z
> (which results in SIGSTOP).

Yeah, and Tulip's retry handles this just fine.

I also noticed that you are hardcoding a dependency on
time.monotonic() if it exists. If it weren't for your desire to "fix"
this issue you wouldn't have needed a time function at all!

> > - this is probably because I'm paranoid about performances but given that select() method will be called repeatedly I would not use a decorator. Also, similarly to what has been done elsewhere in the stdlib, for "critical" parts I would recommend localizing variable access in order to minimize overhead as in:
> >
> >     def select(self, timeout=None):
> >         ...
> >         key_from_fd = self._key_from_fd
> >         ready_append = ready.append
> >         for fd in r | w:
> >             ...
> >             key = key_from_fd(fd)
> >             if key:
> >                 ready_append((key, events & key.events))
>
> I find that localizing variables leads to unreadable code, and is tied
> to the current CPython interpreter implementation: such optimizations
> belong to the interpreter, not user code.
>
> As for the decorator performance overhead, I don't think it weights
> much compared to the cost of a syscall (+ GIL acquire/release):
> with decorator:
> $ ./python -m timeit -s "from selectors import DefaultSelector,
> EVENT_WRITE; import os; s = DefaultSelector();
> s.register(os.pipe()[1], EVENT_WRITE)" "s.select()"
> 100000 loops, best of 3: 3.69 usec per loop
> without decorator:
> $ ./python -m timeit -s "from selectors import DefaultSelector,
> EVENT_WRITE; import os; s = DefaultSelector();
> s.register(os.pipe()[1], EVENT_WRITE)" "s.select()"
> 100000 loops, best of 3: 3.52 usec per loop
>
> That's a 4% overhead, with a single FD that's always ready (and I
> suspect that most of the overhead is due to the call to time(), not
> the decorator per se).

But still I agree with Giampaolo that the decorator doesn't feel
right. It's like a try/except around the entire body of your function,
which is usually a code smell (even though I realize the exception it
catches can only be raised by the syscall). Please go back to the
explicit try/except returning [].

> Also, I'll shortly propose a patch to handle EINTR within C code, so
> those EINTR wrappers won't  be needed anymore.

Hm, it may be a while before everyone is comfortable with that change.
Who knows what might break?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Sat Aug 31 01:26:27 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 30 Aug 2013 23:26:27 +0000
Subject: [issue18825] Making msg optional on logging.exception() and similar
 variants
In-Reply-To: <1377343990.79.0.586156704832.issue18825@psf.upfronthosting.co.za>
Message-ID: <1377905187.76.0.479950588009.issue18825@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

No, because in the general case, it would be useful to provide a message. If you don't want to, you can specify '', but there's no reason to make that the default.

----------
nosy: +vinay.sajip
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18825>
_______________________________________

From report at bugs.python.org  Sat Aug 31 01:27:03 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Aug 2013 23:27:03 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377904047.08.0.366787760561.issue18840@psf.upfronthosting.co.za>
Message-ID: <52212A2C.9090104@udel.edu>


Terry J. Reedy added the comment:

> How about we simply add the warning from http://docs.python.org/3/library/pickle.html#module-pickle to the beginning (or end) of the section?

That is one possibility.

> The Official Python Tutorial has always assumed a certain programmer's competence.

Such a person is much more likely to know about and find use for 
language independent json than Python-specific pickle. The tutorial was 
written before json existed, but if it were written today, json would 
seem to me to be the better choice for first exposure to serialization. 
If someone cares enough to write a patch, I think it should be considered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Sat Aug 31 01:30:57 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Fri, 30 Aug 2013 23:30:57 +0000
Subject: [issue14937] IDLE's deficiency in the completion of file names
 (Python 32, Windows XP)
In-Reply-To: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za>
Message-ID: <1377905457.94.0.884280102397.issue14937@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

On 3.4.0a1 on Windows it seems to come up automatically with \ or \\.  A single \ will only pop up with the tab key; I think it's good that way.  Special characters (i.e. ?) work normally.  All this said, I think this issue is fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14937>
_______________________________________

From report at bugs.python.org  Sat Aug 31 01:36:57 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Fri, 30 Aug 2013 23:36:57 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1377905817.79.0.0471258928625.issue18840@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

I won't question the usefulness of JSON.  I'm not a web programmer and have never used it.  From my interpretation of the tutorial, it seems that the section's purpose is for storing python objects.  If pickle is going to stay in the tutorial, I think a warning is imperative.  Either way, I think a section on JSON would be a welcome addition to the tutorial.

+1 adding a warning
+0 keeping pickle in the tutorial

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Sat Aug 31 02:01:14 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Sat, 31 Aug 2013 00:01:14 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1377907274.04.0.721598518724.issue18840@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

Here's a patch that adds the warning, if we so choose to keep pickle in the tutorial.  It's taken verbatim from the pickle module's documentation.

----------
keywords: +patch
Added file: http://bugs.python.org/file31524/pickle-add-warning_18840.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Sat Aug 31 02:12:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 00:12:41 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1377907961.03.0.18774194079.issue18840@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The very fact that we would add a warning makes pickle unfit for the tutorial, IMHO. The tutorial should stick to simple enough stuff that doesn't need any warnings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18840>
_______________________________________

From report at bugs.python.org  Sat Aug 31 02:23:49 2013
From: report at bugs.python.org (Madison May)
Date: Sat, 31 Aug 2013 00:23:49 +0000
Subject: [issue18888] Add stdlib support for random sampling with replacement
Message-ID: <1377908629.62.0.534510987475.issue18888@psf.upfronthosting.co.za>


New submission from Madison May:

Although the random module supports random sampling without replacement, there is no support for random sampling with replacement.  Efficient random sampling with replacement is trivial using random.choice() (see below), but supporting it as an optional 'replace' arg to random.sample() might be nice for symmetry. 

array = range(100)
random_sample = [random.choice(array) for i in range(10)]

----------
components: Library (Lib)
messages: 196603
nosy: madison.may
priority: normal
severity: normal
status: open
title: Add stdlib support for random sampling with replacement
type: enhancement
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18888>
_______________________________________

From report at bugs.python.org  Sat Aug 31 02:25:50 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 31 Aug 2013 00:25:50 +0000
Subject: [issue18858] dummy_threading lacks threading.get_ident() equivalent
In-Reply-To: <1377638843.21.0.0472654933915.issue18858@psf.upfronthosting.co.za>
Message-ID: <1377908750.46.0.583145681443.issue18858@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18858>
_______________________________________

From report at bugs.python.org  Sat Aug 31 02:29:35 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Aug 2013 00:29:35 +0000
Subject: [issue12037] test_email failures under Windows with the eol extension
 activated
In-Reply-To: <1304958829.88.0.465488458456.issue12037@psf.upfronthosting.co.za>
Message-ID: <1377908975.23.0.730767295852.issue12037@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Two years later, I get the exact same failure in both repository 3.3.2+ and installed 3.3.2. So eol extension and .hgignore seem irrelevant.

I sometime think Python should stop generating files with \r\n. In other words, change os.linesep to '\n' even on windows. Or maybe just do it for test files that will be read in binary mode and compared with generated data. The only program I know of that does not recognize \n alone is Notepad, and that hardly worth bothering with.

Repository 3.4.0a1+ has the same error + essentially the same in
test_as_bytes. (Repository 2.7.5+ passes.) For one test, \r only appears in the file; in the other, it also sporadically appeared in the generated bytes. I don't know why the test works on buildbots, but the attached patch fixes it for my desktop. Any objections to committing it?

----------
keywords: +patch
nosy: +terry.reedy
stage:  -> commit review
versions: +Python 3.4
Added file: http://bugs.python.org/file31525/12037_test_email.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12037>
_______________________________________

From report at bugs.python.org  Sat Aug 31 03:10:31 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Aug 2013 01:10:31 +0000
Subject: [issue12037] test_email failures under Windows with the eol extension
 activated
In-Reply-To: <1304958829.88.0.465488458456.issue12037@psf.upfronthosting.co.za>
Message-ID: <1377911431.07.0.112887601601.issue12037@psf.upfronthosting.co.za>


R. David Murray added the comment:

We have to be careful, since while Windows may no longer care about \r\n, the RFCs certainly do, and the email package is very concerned with the RFC.

However, neither of these tests are testing linesep discipline, so it is fine to fix them.  I've made review comments indicating what I think is a better fix (reading in universal newline mode and encoding the result to bytes to get the comparison bytes data in standard form).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12037>
_______________________________________

From report at bugs.python.org  Sat Aug 31 03:33:31 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Aug 2013 01:33:31 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
Message-ID: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

These are due to \r in line endings, as with #12037.
  File "F:\Python\dev\py34\lib\test\test_sax.py", line 634, in test_expat_file
    self.assertEqual(result.getvalue(), xml_test_out)

Assert fails because off many \rs in xml_text_out. Same in

line 649, in test_expat_file_nonascii
line 778, in test_expat_inpsource_filename
line 788, in test_expat_inpsource_sysid
line 803, in test_expat_inpsource_sysid_nonascii
line 816, in test_expat_inpsource_stream

A fix that works is essentially the same as for #12037:
  xml_test_out = xml_test_out.replace(b'r', b'')
just after xml_test_out is read from the file.
(.translate(None, b'\r') also works, seems slightly slower)

Another would be to not put \r in the file in the first place;-).

Any objection to this?

----------
files: 188xx_text_sax.diff
keywords: patch
messages: 196606
nosy: christian.heimes, terry.reedy
priority: normal
severity: normal
stage: commit review
status: open
title: test_sax: multiple failures on Windows desktop
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31526/188xx_text_sax.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18889>
_______________________________________

From report at bugs.python.org  Sat Aug 31 03:55:58 2013
From: report at bugs.python.org (Meador Inge)
Date: Sat, 31 Aug 2013 01:55:58 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1377914158.04.0.66935075449.issue11798@psf.upfronthosting.co.za>


Meador Inge added the comment:

I see some regressions when reference leak hunting with -j './python -j8 -R :'

test test_ast crashed -- Traceback (most recent call last):
  File "/home/meadori/src/cpython/Lib/test/regrtest.py", line 1265, in runtest_inne
r
    huntrleaks)  File "/home/meadori/src/cpython/Lib/test/regrtest.py", line 1381, in dash_R
    indirect_test()
  File "/home/meadori/src/cpython/Lib/test/regrtest.py", line 1261, in <lambda>    test_runner = lambda: support.run_unittest(tests)
  File "/home/meadori/src/cpython/Lib/test/support/__init__.py", line 1683, in run_
unittest
    _run_suite(suite)
  File "/home/meadori/src/cpython/Lib/test/support/__init__.py", line 1649, in _run
_suite
    result = runner.run(suite)
  File "/home/meadori/src/cpython/Lib/test/support/__init__.py", line 1548, in run
    test(result)
  File "/home/meadori/src/cpython/Lib/unittest/suite.py", line 76, in __call__
    return self.run(*args, **kwds)
  File "/home/meadori/src/cpython/Lib/unittest/suite.py", line 114, in run
    test(result)
  File "/home/meadori/src/cpython/Lib/unittest/suite.py", line 76, in __call__
    return self.run(*args, **kwds)
  File "/home/meadori/src/cpython/Lib/unittest/suite.py", line 114, in run
    test(result)
TypeError: 'NoneType' object is not callable

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sat Aug 31 04:00:06 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Aug 2013 02:00:06 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1377914406.51.0.264085830013.issue18889@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

On #12037, David suggests instead the equivalent of this:

with open(TEST_XMLFILE_OUT) as f:
    xml_test_out = f.read().encode('ascii')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18889>
_______________________________________

From report at bugs.python.org  Sat Aug 31 04:13:15 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Aug 2013 02:13:15 +0000
Subject: [issue12037] test_email failures under Windows with the eol extension
 activated
In-Reply-To: <1304958829.88.0.465488458456.issue12037@psf.upfronthosting.co.za>
Message-ID: <1377915195.93.0.0431568836255.issue12037@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Attached patch works here too. Only the test...rfc822 part applies to 3.3, both to 3.4. The same idea works for #18889 too.

----------
Added file: http://bugs.python.org/file31527/12037_test_email2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12037>
_______________________________________

From report at bugs.python.org  Sat Aug 31 04:35:52 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Aug 2013 02:35:52 +0000
Subject: [issue18890] Add a raw_data_manager content manager to the email
 package.
Message-ID: <1377916552.26.0.723801852284.issue18890@psf.upfronthosting.co.za>


New submission from R. David Murray:

This is the third of three layered patches that introduce a new content management API to the email package.  This patch is layered on top of the patch in issue 18860.  Unfortunately the fact that these patches are layered (which I did in hopes of making them into more reviewable chunks) means that only the first one gets a rietveld link.

This patch provides the raw_data_manager, and makes it the default content_manager.  The raw_data_manager doesn't provide any facilities beyond that provided by the base API of email package, but it does provide those facilities in a much more convenient and consistent API.

----------
components: email
files: raw_data_manager.patch
keywords: patch
messages: 196610
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Add a raw_data_manager content manager to the email package.
versions: Python 3.4
Added file: http://bugs.python.org/file31528/raw_data_manager.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18890>
_______________________________________

From report at bugs.python.org  Sat Aug 31 04:36:46 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Aug 2013 02:36:46 +0000
Subject: [issue18890] Add a raw_data_manager content manager to the email
 package.
In-Reply-To: <1377916552.26.0.723801852284.issue18890@psf.upfronthosting.co.za>
Message-ID: <1377916606.51.0.993101716782.issue18890@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
dependencies: +Add content manager API to email package

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18890>
_______________________________________

From report at bugs.python.org  Sat Aug 31 04:41:02 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 31 Aug 2013 02:41:02 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377916862.77.0.243194024823.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

Nasty problem ;-)

I don't understand the need for all the indirections in the second patch.  Like, why use a weakref?  It's not like we have to worry about an immortal tstate keeping a measly little lock object alive forever, right?  Seems to me that if the tstate object held the new lock directly, the tstate destructor could release the lock directly (and so also skip the new tstate->on_delete and tstate->on_delete_data indirections too).

Then again, I'd settle for Py_EndInterpreter simply sleeping for a second and trying again when it finds "another thread" hanging around (effectively moving Tamas's sleep() into Py_EndInterpreter, but only sleeping if needed).  Yes, that's theoretically insecure.

But if we're worried about wildly improbable timing problems, then the patched code can appear not to honor a non-None Thread.join() `timeout` argument too.  That is, the first call to the new `pred()` can theoretically consume any amount of time, due to its self._tstate_lock.acquire().  The same kinds of timing implausibilities that could cause a short sleep to fail could also cause that acquire() to take "a long time" (maybe even 2 seconds - LOL).

But, ya, it's better to really fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Aug 31 04:49:17 2013
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Sat, 31 Aug 2013 02:49:17 +0000
Subject: [issue18418] Thread.isAlive() sometimes True after fork
In-Reply-To: <1373408030.66.0.77258289483.issue18418@psf.upfronthosting.co.za>
Message-ID: <1377917357.8.0.238241914891.issue18418@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

Thanks for accepting this patch!

Antoine, I initially had trouble writing a test that reliably reproduced the bug, especially in Python 3.3. But I read other threading tests and got smarter. The final patch includes tests that are very reliable at revealing the bug in 2.7 and 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18418>
_______________________________________

From report at bugs.python.org  Sat Aug 31 05:10:04 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Aug 2013 03:10:04 +0000
Subject: [issue18891] Master patch for content manager addtion to email
 package.
Message-ID: <1377918603.72.0.362957249668.issue18891@psf.upfronthosting.co.za>


New submission from R. David Murray:

Since the only way to get a rietveld review link for all the changes is to post a single complete patch, I'm doing so in this issue.  Feel free to review based on either this or the separate patches posted in issue 18785, issue 18860, and issue 18890.

There are a couple of bug fixes in this code, but for the most part it is the addition of a new sub-modulej, and a new subclass to the message.py code, plus the accompanying documentation.

Note that this pretty much completes the proposed API additions to the email module.  There may be some additional small tweaks, and there will certainly be some additional support code for specific message header and message types later, but checking this in will mark the completion of the email6 implementation from my point of view.  (The project won't be complete, of course, until the code becomes non-provisional, hopefully in 3.5.)

----------
components: email
files: master_content_manager.patch
keywords: patch
messages: 196613
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Master patch for content manager addtion to email package.
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31529/master_content_manager.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18891>
_______________________________________

From report at bugs.python.org  Sat Aug 31 05:14:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Aug 2013 03:14:22 +0000
Subject: [issue12037] test_email failures under Windows with the eol extension
 activated
In-Reply-To: <1304958829.88.0.465488458456.issue12037@psf.upfronthosting.co.za>
Message-ID: <1377918862.96.0.632002246146.issue12037@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks good to me, go ahead and push it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12037>
_______________________________________

From report at bugs.python.org  Sat Aug 31 05:49:16 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 31 Aug 2013 03:49:16 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <1377920956.09.0.0338832212911.issue18882@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

There is updated patch.
All tests pass.
I've added docs for threading.main_thread() function also.

----------
Added file: http://bugs.python.org/file31530/issue18882-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18882>
_______________________________________

From report at bugs.python.org  Sat Aug 31 06:26:20 2013
From: report at bugs.python.org (Madison May)
Date: Sat, 31 Aug 2013 04:26:20 +0000
Subject: [issue14075] argparse: unused method?
In-Reply-To: <1329848199.77.0.390599674253.issue14075@psf.upfronthosting.co.za>
Message-ID: <1377923180.04.0.107142686781.issue14075@psf.upfronthosting.co.za>


Madison May added the comment:

Any chance this issue could be reopened?  I ran across this bit of code today when working on coverage for argparse.  I'd like to again propose the removal or modification of _get_args.  I understand that it's there primarily to be overridden, but even that's not useful.  Because _get_kwargs uses obj.__dict__.items(), overriding _get_args to return an iterable of positional args results in those arguments being output twice when repr() is called (once formatted as a positional arg and once formatted as a keyword arg).  You end up with strings like the below.  I just can't think of any situation where this behavior would be desirable.

Action(['--foo', '-a', '-b'], 'b', option_strings=['--foo', '-a', '-b'], dest='b', nargs='+', const=None, default=42, type='int', choices=[1, 2, 3], help='HELP', metavar='METAVAR')

----------
nosy: +madison.may

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14075>
_______________________________________

From report at bugs.python.org  Sat Aug 31 09:10:38 2013
From: report at bugs.python.org (Heijink)
Date: Sat, 31 Aug 2013 07:10:38 +0000
Subject: [issue18892] sqlite3, valued records not persisted, default ones are
Message-ID: <1377933038.86.0.811831713393.issue18892@psf.upfronthosting.co.za>


New submission from Heijink:

In the end I tracked down the behaviour with the attached program
behaviour with an initially empty table:

7 : insert two records with values in the columns
two records show up, # 1,2
as expected
9 : show al records
none
whereas two are to be expected
8 : add records with default values
two records show up # 1,2
as expected in an empty table
7
two records # 3,4
record numbers as expected, but where are records 1,2?  (ABC)
9
the default records are present #1,2
the previous valued records 3,4 not
  unexpected, but identical to first behaviour issuing 7
8
4 records show up # 1-4
record numbers as expected when valued records are not present
0  :  I quit

to summarize:
It is not possible to store records in the database with valued columns.
Records with default values can be stored and retrieved, they are the ones that are persistent
Additional strange behaviour is that after adding valued records (3,4) also the already present records with default values (1,2) should have shown show up, remark (ABC).

----------
components: Demos and Tools
files: dump.py
messages: 196617
nosy: debewerker
priority: normal
severity: normal
status: open
title: sqlite3, valued records not persisted, default ones are
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file31531/dump.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18892>
_______________________________________

From report at bugs.python.org  Sat Aug 31 09:17:13 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 31 Aug 2013 07:17:13 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1377933433.0.0.182173901331.issue11798@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Good catch!
That's because -R run the same test suite several times.
I'm working on patch.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sat Aug 31 09:21:09 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Aug 2013 07:21:09 +0000
Subject: [issue18892] sqlite3, valued records not persisted, default ones are
In-Reply-To: <1377933038.86.0.811831713393.issue18892@psf.upfronthosting.co.za>
Message-ID: <1377933669.88.0.225094748815.issue18892@psf.upfronthosting.co.za>


R. David Murray added the comment:

What happens if you actually call commit()?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18892>
_______________________________________

From report at bugs.python.org  Sat Aug 31 09:32:07 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 31 Aug 2013 07:32:07 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <CAP7+vJKkezU8Nmu458PhNGcQTctU1oS7VyU2KTpksfmy6SBazQ@mail.gmail.com>
Message-ID: <CAH_1eM2+Okd4XwEyBxybFqZe_QDgf3Ras8ykH0PVOahAjFAPbA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

2013/8/31 Guido van Rossum <report at bugs.python.org>:
> But still I agree with Giampaolo that the decorator doesn't feel
> right. It's like a try/except around the entire body of your function,
> which is usually a code smell (even though I realize the exception it
> catches can only be raised by the syscall). Please go back to the
> explicit try/except returning [].

Well, I'll change it, but:
We have to change the select() docstring to "Wait until some
registered file objects become ready, or for *at most* timeout
seconds"

All user code that wants to handle EINTR or correct timeout (which
should be "all user code" in a perfect world) will have to wrap the
call to select() inside a loop equivalent to this decorator, and I
personally like the a rule of "never let the user do what the library
can do for him".
This includes for example multiprocessing and telnetlib which
currently implement this EINTR handling loop with timeout computation,
see e.g.:
http://hg.python.org/cpython/file/acc7439b1406/Lib/telnetlib.py#l297

And other places in the stdlib either don't handle EINTR properly, or
don't re-compute timeout (see e.g. http://bugs.python.org/issue12338).

Also, I don't really see the problem with retrying upon EINTR, since:
- the signal handler will be called right away anyway
- in case where the select() is a part of an event loop, the event
loop registers a wakup file descriptor with the selector, which means
that upon interesting signal delivery, the select() call will return
to the schedulor

So in short, I don't see how that could be a nuisance, but I can
certainly see how this could trick user code into raising spurious
timeout-related errors, or be much more complicated than it ought to
be (the above telnetlib example is IMO a great example of why EINTR
and timeout computation should be handled at the selector level).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Sat Aug 31 09:32:18 2013
From: report at bugs.python.org (Heijink)
Date: Sat, 31 Aug 2013 07:32:18 +0000
Subject: [issue18892] sqlite3, valued records not persisted, default ones are
In-Reply-To: <1377933038.86.0.811831713393.issue18892@psf.upfronthosting.co.za>
Message-ID: <1377934338.39.0.155856796049.issue18892@psf.upfronthosting.co.za>


Heijink added the comment:

your suggestion is a bit to cryptic for me
- you mean intermediate messages from Python: there are none
- you mean to change a command in another format
  newbie with programming experience
  drop me a program line / show three records where one is your alternative

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18892>
_______________________________________

From report at bugs.python.org  Sat Aug 31 09:37:57 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 31 Aug 2013 07:37:57 +0000
Subject: [issue18418] Thread.isAlive() sometimes True after fork
In-Reply-To: <1373408030.66.0.77258289483.issue18418@psf.upfronthosting.co.za>
Message-ID: <1377934677.81.0.334448395935.issue18418@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

> The final patch includes tests that are very reliable at
> revealing the bug in 2.7 and 3.3.

Indeed, I could reproduce it systematically without the patch.

> Thanks for accepting this patch!

Well, thanks for the patch!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18418>
_______________________________________

From report at bugs.python.org  Sat Aug 31 09:48:29 2013
From: report at bugs.python.org (Peter Otten)
Date: Sat, 31 Aug 2013 07:48:29 +0000
Subject: [issue18892] sqlite3, valued records not persisted, default ones are
In-Reply-To: <1377933038.86.0.811831713393.issue18892@psf.upfronthosting.co.za>
Message-ID: <1377935309.76.0.482206875213.issue18892@psf.upfronthosting.co.za>


Peter Otten added the comment:

David means you should replace the line

conn.commit

in your script which does not invoke the method with

conn.commit()

Side note: as long as you are a newbie it is a good idea to ask on the python mailing list first before adding a report to the bug tracker.

----------
nosy: +peter.otten

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18892>
_______________________________________

From report at bugs.python.org  Sat Aug 31 09:52:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Aug 2013 07:52:20 +0000
Subject: [issue18892] sqlite3, valued records not persisted, default ones are
In-Reply-To: <1377933038.86.0.811831713393.issue18892@psf.upfronthosting.co.za>
Message-ID: <1377935540.44.0.344110270582.issue18892@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sorry, I didn't mean to be cryptic.  Yes, Peter has figured out what I was trying to say.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18892>
_______________________________________

From report at bugs.python.org  Sat Aug 31 09:54:36 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 31 Aug 2013 07:54:36 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <CAH_1eM2+Okd4XwEyBxybFqZe_QDgf3Ras8ykH0PVOahAjFAPbA@mail.gmail.com>
Message-ID: <CAH_1eM0LMmeFiFewFuPqcTvRbq6wx+zSUF75OG2c76jS2rdDLw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Oh, and FWIW, that's also what Java does:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5100121
http://hg.openjdk.java.net/jdk6/jdk6-gate/jdk/file/6daa81bdfd18/src/solaris/native/sun/nio/ch/PollArrayWrapper.c

(I know some people don't like Java, but I've found that they have
some really competent people and an extensive real-life exposure and
feedback).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Sat Aug 31 11:24:21 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 31 Aug 2013 09:24:21 +0000
Subject: [issue18888] Add stdlib support for random sampling with replacement
In-Reply-To: <1377908629.62.0.534510987475.issue18888@psf.upfronthosting.co.za>
Message-ID: <1377941061.09.0.533464059538.issue18888@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

This was already considered and rejected in issue18414.

----------
nosy: +mark.dickinson, rhettinger
resolution:  -> duplicate
status: open -> closed
superseder:  -> random.choices(seq, k)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18888>
_______________________________________

From report at bugs.python.org  Sat Aug 31 12:13:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 10:13:48 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377916862.77.0.243194024823.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377944017.2478.6.camel@fsol>


Antoine Pitrou added the comment:

> I don't understand the need for all the indirections in the second
> patch.  Like, why use a weakref?  It's not like we have to worry about
> an immortal tstate keeping a measly little lock object alive forever,
> right?  Seems to me that if the tstate object held the new lock
> directly, the tstate destructor could release the lock directly (and
> so also skip the new tstate->on_delete and tstate->on_delete_data
> indirections too).

The problem is if the tstate holds the last reference to the lock. It
will destroy the lock at the end, but the lock could have weakrefs
attached to it with arbitrary callbacks. Those callbacks will run
without a current thread state and may crash. OTOH, this can't happen
with a private weakref.

You may suggest we only keep the Py_thread_lock in the tstate, rather
than the enclosing PyObject. But it has lifetime problems of its owns
(the Py_thread_lock doesn't have a refcount, and it is shared with a
PyObject who thinks it owns it and will destroy it on dealloc... adding
the necessary logic to circumvent this would make the final solution
more complicated than the weakref one).

> Then again, I'd settle for Py_EndInterpreter simply sleeping for a
> second and trying again when it finds "another thread" hanging around
> (effectively moving Tamas's sleep() into Py_EndInterpreter, but only
> sleeping if needed).  Yes, that's theoretically insecure.

Well, that sounds less predictable. Depending on machine load,
Py_EndInterpreter might succeed or crash with a fatal error. Users may
not like this :-)

> But if we're worried about wildly improbable timing problems, then the
> patched code can appear not to honor a non-None Thread.join()
> `timeout` argument too.  That is, the first call to the new `pred()`
> can theoretically consume any amount of time, due to its
> self._tstate_lock.acquire().

Ah, well, good point. It's weird it didn't get caught by the unit
tests... I'll take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Aug 31 12:33:56 2013
From: report at bugs.python.org (Heijink)
Date: Sat, 31 Aug 2013 10:33:56 +0000
Subject: [issue18892] sqlite3, valued records not persisted, default ones are
In-Reply-To: <1377933038.86.0.811831713393.issue18892@psf.upfronthosting.co.za>
Message-ID: <1377945236.22.0.819331266117.issue18892@psf.upfronthosting.co.za>


Heijink added the comment:

that did the trick, my confidence is restored.

sorry to have bothered you, I could have found in myself, by comparing differences. Just staring blind after many attempts. 
I did look in the list, but could not find an issue that matched my description of the problem.

I closed the subject

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18892>
_______________________________________

From report at bugs.python.org  Sat Aug 31 12:56:26 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 31 Aug 2013 10:56:26 +0000
Subject: [issue18893] typo in Lib/ctypes/macholib/dyld.py
Message-ID: <1377946586.23.0.205823706154.issue18893@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The exception handling clauses in framework_find() are weird.


def framework_find(fn, executable_path=None, env=None):
    """
    Find a framework using dyld semantics in a very loose manner.

    Will take input such as:
        Python
        Python.framework
        Python.framework/Versions/Current
    """
    try:
        return dyld_find(fn, executable_path=executable_path, env=env)
    except ValueError as e:
        pass
    fmwk_index = fn.rfind('.framework')
    if fmwk_index == -1:
        fmwk_index = len(fn)
        fn += '.framework'
    fn = os.path.join(fn, os.path.basename(fn[:fmwk_index]))
    try:
        return dyld_find(fn, executable_path=executable_path, env=env)
    except ValueError:
        raise e


My guess is that this is left-over code from Py2.x. Since it doesn't make sense to catch an exception in the second clause just to re-raise it, I think the intention was really to re-raise the original exception caught in the first clause, which no longer works that way in Py3.

The fix would then be to assign the exception to a new variable in the first except clause and re-raise that in the second.

I found this problem because Cython rejected the module with a compile error about "e" being undefined in the last line.

----------
components: Library (Lib), ctypes
messages: 196629
nosy: scoder
priority: normal
severity: normal
status: open
title: typo in Lib/ctypes/macholib/dyld.py
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18893>
_______________________________________

From report at bugs.python.org  Sat Aug 31 13:04:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 11:04:22 +0000
Subject: [issue18893] typo in Lib/ctypes/macholib/dyld.py
In-Reply-To: <1377946586.23.0.205823706154.issue18893@psf.upfronthosting.co.za>
Message-ID: <1377947062.11.0.128302437157.issue18893@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18893>
_______________________________________

From report at bugs.python.org  Sat Aug 31 13:21:00 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 31 Aug 2013 11:21:00 +0000
Subject: [issue18893] invalid exception handling in Lib/ctypes/macholib/dyld.py
In-Reply-To: <1377946586.23.0.205823706154.issue18893@psf.upfronthosting.co.za>
Message-ID: <1377948060.94.0.350160349735.issue18893@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

changing title as it doesn't really look like a typo, more a "converto"

----------
title: typo in Lib/ctypes/macholib/dyld.py -> invalid exception handling in Lib/ctypes/macholib/dyld.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18893>
_______________________________________

From report at bugs.python.org  Sat Aug 31 13:30:56 2013
From: report at bugs.python.org (Madison May)
Date: Sat, 31 Aug 2013 11:30:56 +0000
Subject: [issue18888] Add stdlib support for random sampling with replacement
In-Reply-To: <1377908629.62.0.534510987475.issue18888@psf.upfronthosting.co.za>
Message-ID: <1377948656.38.0.12573721436.issue18888@psf.upfronthosting.co.za>


Madison May added the comment:

Whoops, my apologies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18888>
_______________________________________

From report at bugs.python.org  Sat Aug 31 14:09:35 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 31 Aug 2013 12:09:35 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1377950975.17.0.551432910768.issue16853@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

I may be missing something here but isn't the whole point of EINTR to interrupt a potentially long running syscall?
Why protract function return time as a consequence?
All the event loops I'm familiar with (twisted, tornado and asyncore) just 'return' on EINTR, supposedly because that was the best compromise to support syscall interruption without forcing users to handle EINTR themselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Sat Aug 31 14:23:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 12:23:07 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1377950975.17.0.551432910768.issue16853@psf.upfronthosting.co.za>
Message-ID: <1377951776.2478.10.camel@fsol>


Antoine Pitrou added the comment:

> I may be missing something here but isn't the whole point of EINTR to
> interrupt a potentially long running syscall?

Not exactly. The point is to signal (!) that a signal was received.
The received signal is not necessarily expected.

Also, from what I understand, it is more reliable to use a wakeup fd
(using e.g. signal.set_wakeup_fd) rather than expect EINTR to be
returned:
http://mail.python.org/pipermail/python-dev/2013-August/128204.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Sat Aug 31 14:26:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 12:26:00 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1377950975.17.0.551432910768.issue16853@psf.upfronthosting.co.za>
Message-ID: <1377951952.2478.11.camel@fsol>


Antoine Pitrou added the comment:

> All the event loops I'm familiar with (twisted, tornado and asyncore)
> just 'return' on EINTR, supposedly because that was the best
> compromise to support syscall interruption without forcing users to
> handle EINTR themselves.

What do you mean? Tornado simply retries on EINTR:
https://github.com/facebook/tornado/blob/master/tornado/ioloop.py#L652

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Sat Aug 31 14:28:39 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 31 Aug 2013 12:28:39 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1377950975.17.0.551432910768.issue16853@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM02NwuStivgk6=nvE_X+7gzbY+1PJkikWr8YmaO-FPPoA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> I may be missing something here but isn't the whole point of EINTR to interrupt a potentially long running syscall?

No.
EINTR is an artifact of the early Unix design, because failing when a
signal was delivered was simpler than restarting the syscall.
Nowadays, most syscalls are restarted by default (that's was true on
BSD, and nowadays Linux also follows this trend).
See e.g. http://lkml.indiana.edu/hypermail/linux/kernel/0104.0/0743.html
and http://man7.org/linux/man-pages/man7/signal.7.html

One reason why EINTR can occur so often in CPython is because we set
up signal handlers without SA_RESTART (which is set by default by
signal(3)). The reason is likely that we want the syscall to return to
be able to call PyCheckSignals() (since we cannot run Python code from
a signal handler).
But since in this case, PyCheckSignals() is called anyway from the
main eval loop, signal handlers will still be run in a timely manner
(and as noted, the proper way to handle signals is to use a wakeup
file descriptor which can be used by select()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Sat Aug 31 14:32:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 12:32:22 +0000
Subject: [issue12304] expose signalfd(2) in the signal module
In-Reply-To: <1307660456.9.0.497118052372.issue12304@psf.upfronthosting.co.za>
Message-ID: <1377952342.49.0.603999233171.issue12304@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12304>
_______________________________________

From report at bugs.python.org  Sat Aug 31 14:58:47 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Sat, 31 Aug 2013 12:58:47 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377953927.59.0.0908592843035.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

So with your test program I did not yet hit the error. It used in the end 1.3GB of RAM, maybe in the good region. while this was python-2.7.5 configures as --without-pymalloc maybe the output from valgrind becomes more useful.

----------
Added file: http://bugs.python.org/file31532/stress.valgrind.stderr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Sat Aug 31 15:14:55 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 31 Aug 2013 13:14:55 +0000
Subject: [issue18831] importlib.import_module() bypasses builtins.__import__
In-Reply-To: <1377443801.78.0.926402532335.issue18831@psf.upfronthosting.co.za>
Message-ID: <1377954895.88.0.954687357994.issue18831@psf.upfronthosting.co.za>


Brett Cannon added the comment:

builtins.__import__ and importlib.__import__ are different objects.

This isn't about whether this is whole situation is a bug per-se, but whether users expect that overriding builtins.__import__ will affect all import-related code in the stdlib and if that's reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18831>
_______________________________________

From report at bugs.python.org  Sat Aug 31 15:34:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 13:34:39 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377956079.86.0.145797767033.issue18843@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Hardware failures or glitches can involve any number of parameters.
Instead of trying to reproduce the memory corruption with other Python programs, I would suggest you run the exact same workload (including Python version and build options) on another computer (preferably with different hardware characteristics) and see if you can still trigger it.

(bonus points if you can try on a setup with ECC RAM)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Sat Aug 31 16:37:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Aug 2013 14:37:47 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <3cS0XB71ddzRWX@mail.python.org>


Roundup Robot added the comment:

New changeset 1faaec66c73d by Eli Bendersky in branch 'default':
Fix XMLPullParser documentation to say "non-blocking" instead of "asynchronous".
http://hg.python.org/cpython/rev/1faaec66c73d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sat Aug 31 16:50:24 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 31 Aug 2013 14:50:24 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1377960624.34.0.72347534498.issue18738@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

The idea looks reasonable. Posted a code review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Sat Aug 31 17:14:18 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 31 Aug 2013 15:14:18 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <CAH_1eM2+Okd4XwEyBxybFqZe_QDgf3Ras8ykH0PVOahAjFAPbA@mail.gmail.com>
Message-ID: <CAP7+vJK9_XM=AoJj8x8mNg5vxRPhjVmE=u_NFic0xhbU6TRTDw@mail.gmail.com>


Guido van Rossum added the comment:

> Charles-Fran?ois Natali added the comment:

> Well, I'll change it, but:
> We have to change the select() docstring to "Wait until some
> registered file objects become ready, or for *at most* timeout
> seconds"

Doesn't sound so bad to me. It's about the same guarantee as sleep().

> All user code that wants to handle EINTR or correct timeout (which
> should be "all user code" in a perfect world) will have to wrap the
> call to select() inside a loop equivalent to this decorator, and I
> personally like the a rule of "never let the user do what the library
> can do for him".

No, they'll use a framework with an event loop like Tulip that takes
care of all of this for them. Such frameworks all have logic in them
to handle early returns from the low-level select/poll operation.

I find it easier to reason about the correctness of the framework's
code without your decorator:

(1) I have to convince myself that the code wrapped by your decorator
doesn't change any global state, *or* that there is a guarantee that
the exception caught is only raised by the select()/poll()/etc.
syscall, not anywhere else in the wrapped method.

(2) I have to remember that if a signal handler is called that
modifies the event loop's deadline, the selector will return
immediately anyway (so the event loop can recalculate its deadline)
because of the self-pipe.

(3) I have to prove that your decorator uses the same clock as my framework.

(4) I have to prove that your code does the same thing if the process
is suspended for a really long time and the system clock changes in
the meantime.

> This includes for example multiprocessing and telnetlib which
> currently implement this EINTR handling loop with timeout computation,
> see e.g.:
> http://hg.python.org/cpython/file/acc7439b1406/Lib/telnetlib.py#l297
>
> And other places in the stdlib either don't handle EINTR properly, or
> don't re-compute timeout (see e.g. http://bugs.python.org/issue12338).
>
> Also, I don't really see the problem with retrying upon EINTR, since:
> - the signal handler will be called right away anyway
> - in case where the select() is a part of an event loop, the event
> loop registers a wakup file descriptor with the selector, which means
> that upon interesting signal delivery, the select() call will return
> to the schedulor
>
> So in short, I don't see how that could be a nuisance, but I can
> certainly see how this could trick user code into raising spurious
> timeout-related errors, or be much more complicated than it ought to
> be (the above telnetlib example is IMO a great example of why EINTR
> and timeout computation should be handled at the selector level).

The selector is a helper for higher-level frameworks. I think the
EINTR handling belongs in the framework.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Sat Aug 31 17:50:33 2013
From: report at bugs.python.org (Valerie Lambert)
Date: Sat, 31 Aug 2013 15:50:33 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>
Message-ID: <1377964233.47.0.537103165.issue18623@psf.upfronthosting.co.za>


Valerie Lambert added the comment:

Running through both your scripts on my machine (using Ubuntu) WCOREDUMP is always True (though I'll only be able to find a core file when ulimit is set to unlimited, as expected).

Because there doesn't seem to be a good way to test this, I've cut the test from the patch. Is there anything else that this patch should address?

----------
Added file: http://bugs.python.org/file31533/issue-18623_v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18623>
_______________________________________

From report at bugs.python.org  Sat Aug 31 17:54:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 15:54:05 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1377964445.14.0.766203943957.issue18889@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18889>
_______________________________________

From report at bugs.python.org  Sat Aug 31 17:54:13 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 15:54:13 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1377964453.17.0.402785266732.issue18889@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Tests
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18889>
_______________________________________

From report at bugs.python.org  Sat Aug 31 17:56:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 15:56:29 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1377964589.85.0.315709743868.issue18889@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18889>
_______________________________________

From report at bugs.python.org  Sat Aug 31 18:12:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Aug 2013 16:12:01 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1377965521.26.0.5686705414.issue18889@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Why Lib/test/xmltestdata/test.xml.out contains '\r'? AFAIK Windows buildbots are happy with current tests.

A nitpick for first proposed solution: you can append ".replace(b'\r', b'')" just to "f.read()".

A nitpick for second proposed solution: encoding should be "iso-8859-1" (for both open() and encode()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18889>
_______________________________________

From report at bugs.python.org  Sat Aug 31 18:17:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Aug 2013 16:17:16 +0000
Subject: [issue18891] Master patch for content manager addtion to email
 package.
In-Reply-To: <1377918603.72.0.362957249668.issue18891@psf.upfronthosting.co.za>
Message-ID: <1377965836.1.0.825276210835.issue18891@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18891>
_______________________________________

From report at bugs.python.org  Sat Aug 31 18:19:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Aug 2013 16:19:15 +0000
Subject: [issue18823] Idle: use pipes instead of sockets to talk with user
 subprocess
In-Reply-To: <1377300904.13.0.124289838176.issue18823@psf.upfronthosting.co.za>
Message-ID: <1377965955.29.0.895215808747.issue18823@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18823>
_______________________________________

From report at bugs.python.org  Sat Aug 31 18:22:54 2013
From: report at bugs.python.org (py.user)
Date: Sat, 31 Aug 2013 16:22:54 +0000
Subject: [issue18894] In unittest.TestResult.failures remove deprecated fail*
 methods
Message-ID: <1377966174.08.0.355322542495.issue18894@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/library/unittest.html#unittest.TestResult.failures

----------
assignee: docs at python
components: Documentation
files: issue.diff
keywords: patch
messages: 196644
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In unittest.TestResult.failures remove deprecated fail* methods
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31534/issue.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18894>
_______________________________________

From report at bugs.python.org  Sat Aug 31 18:26:06 2013
From: report at bugs.python.org (py.user)
Date: Sat, 31 Aug 2013 16:26:06 +0000
Subject: [issue18895] In unittest.TestResult.addError split the sentence
Message-ID: <1377966366.86.0.69110585984.issue18895@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/library/unittest.html#unittest.TestResult.addError

----------
assignee: docs at python
components: Documentation
files: issue.diff
keywords: patch
messages: 196645
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In unittest.TestResult.addError split the sentence
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31535/issue.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18895>
_______________________________________

From report at bugs.python.org  Sat Aug 31 18:37:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Aug 2013 16:37:26 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <1377967046.56.0.0550492243513.issue18882@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Library (Lib)
nosy: +serhiy.storchaka
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18882>
_______________________________________

From report at bugs.python.org  Sat Aug 31 18:44:13 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 31 Aug 2013 16:44:13 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1377967453.52.0.267894749348.issue18885@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

FYI - use the changes made in http://bugs.python.org/issue12268 as a guide for how to deal with EINTR properly at the C level.  See the _PyIO_trap_eintr() function for example.

See also _eintr_retry_call() in Lib/subprocess.py.

FWIW, there are times when we *want* the interrupted system call to return control to Python rather than retrying the call.  If someone is making a Python equivalent of the low level system call such as select() or poll(), the EINTR should be exposed for Python code to handle.

Things like time.sleep() are documented as sleeping for less time when a signal has arrived even though an exception may not be raised. People have written code which depends on this behavior so adding an EINTR retry for the remaining sleep time would break some programs.

Getting an EINTR errno does *not* mean you can simply retry the system calls with the exact same arguments.  ie: If you did that with the select() call within time.sleep it'd be trivial to make the process sleep forever by sending it signals with a frequency less than the sleep time.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18885>
_______________________________________

From report at bugs.python.org  Sat Aug 31 18:48:30 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 31 Aug 2013 16:48:30 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1377967710.17.0.0948358148898.issue18885@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18885>
_______________________________________

From report at bugs.python.org  Sat Aug 31 18:56:29 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 31 Aug 2013 16:56:29 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1377968189.2.0.575176543025.issue18885@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Gregory, thanks, that's what I was planning to do.

But since the recent discussions (mainly on selectors), there are points I obviously don't - and won't - agree with (such as select() returning EINTR or returning early, same for sleep()), I'm not interested in this anymore.
Anyone interested can pick this up, though.

(BTW, as for applications relying on EINTR being returned, I'm positive *way more applications* will break because of the recent change making file descriptors close-on-exec by default).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18885>
_______________________________________

From report at bugs.python.org  Sat Aug 31 18:57:57 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 31 Aug 2013 16:57:57 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1377968277.23.0.665825033216.issue18885@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
nosy:  -neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18885>
_______________________________________

From report at bugs.python.org  Sat Aug 31 19:00:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 17:00:14 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377967453.52.0.267894749348.issue18885@psf.upfronthosting.co.za>
Message-ID: <1377968398.2478.37.camel@fsol>


Antoine Pitrou added the comment:

> FWIW, there are times when we *want* the interrupted system call to
> return control to Python rather than retrying the call.

I'm a bit curious, do you know of any use cases?

> If someone is making a Python equivalent of the low level system call
> such as select() or poll(), the EINTR should be exposed for Python
> code to handle.

As mentioned in another issue, you would use a special wakeup fd to
wakeup select() or poll() calls.

> Getting an EINTR errno does *not* mean you can simply retry the system
> calls with the exact same arguments.  ie: If you did that with the
> select() call within time.sleep it'd be trivial to make the process
> sleep forever by sending it signals with a frequency less than the
> sleep time.

Indeed. That's already done in e.g. socketmodule.c : take a look at the
BEGIN_SELECT_LOOP / END_SELECT_LOOP macros.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18885>
_______________________________________

From report at bugs.python.org  Sat Aug 31 19:06:54 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 31 Aug 2013 17:06:54 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <CAP7+vJK9_XM=AoJj8x8mNg5vxRPhjVmE=u_NFic0xhbU6TRTDw@mail.gmail.com>
Message-ID: <CAH_1eM3t5W6ArQj2_4YqPaP_8GqfO49yk-kt-=ajNYJfp6zzYA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Here's a patch returning [] on EINTR.

I've tested it on Linux, Windows, FreeBSD, OpenSolaris and OS-X.

----------
Added file: http://bugs.python.org/file31536/selectors-15.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________
-------------- next part --------------
diff -r 78f3c32a92ce Doc/library/selectors.rst
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Doc/library/selectors.rst	Sat Aug 31 17:47:17 2013 +0200
@@ -0,0 +1,229 @@
+:mod:`selectors` -- High-level I/O multiplexing
+===============================================
+
+.. module:: selectors
+   :synopsis: High-level I/O multiplexing.
+
+.. versionadded:: 3.4
+
+
+Introduction
+------------
+
+This module allows high-level and efficient I/O multiplexing, built upon the
+:mod:`select` module primitives. Users are encouraged to use this module
+instead, unless they want precise control over the OS-level primitives used.
+
+It defines a :class:`BaseSelector` abstract base class, along with several
+concrete implementations (:class:`KqueueSelector`, :class:`EpollSelector`...),
+that can be used to wait for I/O readiness notification on multiple file
+objects. In the following, "file object" refers to any object with a
+:meth:`fileno()` method, or a raw file descriptor. See :term:`file object`.
+
+:class:`DefaultSelector` is an alias to the most efficient implementation
+available on the current platform: this should be the default choice for most
+users.
+
+.. note::
+   The type of file objects supported depends on the platform: on Windows,
+   sockets are supported, but not pipes, whereas on Unix, both are supported
+   (some other types may be supported as well, such as fifos or special
+   devices).
+
+.. seealso::
+
+   :mod:`select`
+       Low-level I/O multiplexing module.
+
+
+Classes
+-------
+
+Classes hierarchy::
+
+   BaseSelector
+   +-- SelectSelector
+   +-- PollSelector
+   +-- EpollSelector
+   +-- KqueueSelector
+
+
+In the following, *events* is a bitwise mask indicating which I/O events should
+be waited for on a given file object. It can be a combination of the constants
+below:
+
+   +-----------------------+-----------------------------------------------+
+   | Constant              | Meaning                                       |
+   +=======================+===============================================+
+   | :const:`EVENT_READ`   | Available for read                            |
+   +-----------------------+-----------------------------------------------+
+   | :const:`EVENT_WRITE`  | Available for write                           |
+   +-----------------------+-----------------------------------------------+
+
+
+.. class:: SelectorKey
+
+   A :class:`SelectorKey` is a :class:`~collections.namedtuple` used to
+   associate a file object to its underlying file decriptor, selected event
+   mask and attached data. It is returned by several :class:`BaseSelector`
+   methods.
+
+   .. attribute:: fileobj
+
+      File object registered.
+
+   .. attribute:: fd
+
+      Underlying file descriptor.
+
+   .. attribute:: events
+
+      Events that must be waited for this file object.
+
+   .. attribute:: data
+
+      Optional opaque data associated to this file object: for example, this
+      could be used to store per-client session.
+
+
+.. class:: BaseSelector
+
+   A :class:`BaseSelector` is used to wait for I/O event readiness on multiple
+   file objects. It supports file stream registration, unregistration, and a
+   method to wait for I/O events on those streams, with an optional timeout.
+   It's an abstract base class, so cannot be instanciated. Use
+   :class:`DefaultSelector` instead, or one of :class:`SelectSelector`,
+   :class:`KqueueSelector` etc. if you want to specifically use an
+   implementation, and your platform supports it.
+   :class:`BaseSelector` and its concrete implementations support the context
+   manager protocol.
+
+   .. method:: register(fileobj, events, data=None)
+
+      Register a file object for selection, monitoring it for I/O events.
+
+      *fileobj* is the file object to monitor
+      *events* is a bitwise mask of events to monitor
+      *data* is an opaque object
+
+      This returns a new :class:`SelectorKey` instance, or raises a
+      :exc:`ValueError` in case of invalid event mask or file descriptor, or
+      :exc:`KeyError` if the file object is already registered.
+
+   .. method:: unregister(fileobj)
+
+      Unregister a file object from selection, removing it from monitoring.
+
+      *fileobj* must be a file object previously registered.
+
+      This returns the associated :class:`SelectorKey` instance, or raises a
+      :exc:`KeyError` if the file object is not registered.
+
+   .. method:: modify(fileobj, events, data=None)
+
+      Change a registered file object monitored events or attached data.
+
+      This is equivalent to :meth:`BaseSelector.unregister(fileobj)` followed by
+      :meth:`BaseSelector.register(fileobj, events, data)`, except that it can be
+      implemented more efficiently.
+
+      This returns a new :class:`SelectorKey` instance, or raises a
+      :exc:`ValueError` in case of invalid event mask or file descriptor, or
+      :exc:`KeyError` if the file object is not registered.
+
+   .. method:: select(timeout=None)
+
+      Wait until some registered file objects become ready, or the timeout
+      expires.
+
+      if ``timeout > 0``, this specifies the maximum wait time, in seconds
+      if ``timeout <= 0``, the call won't block, and will report the currently
+      ready file objects
+      if *timeout* is ``None``, the call will block until a monitored file object
+      becomes ready
+
+      This returns a list of ``(key, events)`` tuple, one for each ready file
+      object.
+
+      *key* is the :class:`SelectorKey` instance corresponding to a ready file
+      object
+      *events* is a bitmask of events ready on this file object
+
+   .. method:: close()
+
+      Close the selector.
+
+      This must be called to make sure that any underlying resource is freed.
+
+   .. method:: get_key(fileobj)
+
+      Return the key associated to a registered file object.
+
+      This returns the :class:`SelectorKey` instance associated to this file
+      object, or raises :exc:`KeyError` if the file object is not registered.
+
+
+.. class:: DefaultSelector()
+
+   The default selector class, using the most efficient implementation
+   available on the current platform. This should be the default choice for
+   most users.
+
+
+.. class:: SelectSelector()
+
+   :func:`~select.select`-based selector.
+
+
+.. class:: PollSelector()
+
+   :func:`~select.poll`-based selector.
+
+
+.. class:: EpollSelector()
+
+   :func:`~select.epoll`-based selector.
+
+   .. method:: fileno()
+
+      This returns the file descriptor used by the underlying
+      :func:`~select.epoll` object.
+
+
+.. class:: KqueueSelector()
+
+   :func:`~select.kqueue`-based selector.
+
+   .. method:: fileno()
+
+      This returns the file descriptor used by the underlying
+      :func:`~select.kqueue` object.
+
+
+Examples of selector usage::
+
+   >>> import selectors
+   >>> import socket
+   >>>
+   >>> s = selectors.DefaultSelector()
+   >>> r, w = socket.socketpair()
+   >>>
+   >>> s.register(r, selectors.EVENT_READ)
+   SelectorKey(fileobj=<socket.socket fd=4, family=1, type=1, proto=0>, fd=4, events=1, data=None)
+   >>> s.register(w, selectors.EVENT_WRITE)
+   SelectorKey(fileobj=<socket.socket fd=5, family=1, type=1, proto=0>, fd=5, events=2, data=None)
+   >>>
+   >>> print(s.select())
+   [(SelectorKey(fileobj=<socket.socket fd=5, family=1, type=1, proto=0>, fd=5, events=2, data=None), 2)]
+   >>>
+   >>> for key, events in s.select():
+   ...     if events & selectors.EVENT_WRITE:
+   ...         key.fileobj.send(b'spam')
+   ...
+   4
+   >>> for key, events in s.select():
+   ...     if events & selectors.EVENT_READ:
+   ...         print(key.fileobj.recv(1024))
+   ...
+   b'spam'
+   >>> s.close()
diff -r 78f3c32a92ce Doc/whatsnew/3.4.rst
--- a/Doc/whatsnew/3.4.rst	Sat Aug 31 17:32:30 2013 +0200
+++ b/Doc/whatsnew/3.4.rst	Sat Aug 31 17:47:17 2013 +0200
@@ -174,10 +174,11 @@
 New Modules
 ===========
 
-.. module name
-.. -----------
+selectors
+---------
 
-* None yet.
+The new :mod:`selectors` module allows high-level and efficient I/O
+multiplexing, built upon the :mod:`select` module primitives.
 
 
 Improved Modules
diff -r 78f3c32a92ce Lib/selectors.py
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Lib/selectors.py	Sat Aug 31 17:47:17 2013 +0200
@@ -0,0 +1,410 @@
+"""Selectors module.
+
+This module allows high-level and efficient I/O multiplexing, built upon the
+`select` module primitives.
+"""
+
+
+from abc import ABCMeta, abstractmethod
+from collections import namedtuple
+import functools
+import select
+import sys
+
+
+# generic events, that must be mapped to implementation-specific ones
+EVENT_READ = (1 << 0)
+EVENT_WRITE = (1 << 1)
+
+
+def _fileobj_to_fd(fileobj):
+    """Return a file descriptor from a file object.
+
+    Parameters:
+    fileobj -- file object or file descriptor
+
+    Returns:
+    corresponding file descriptor
+    """
+    if isinstance(fileobj, int):
+        fd = fileobj
+    else:
+        try:
+            fd = int(fileobj.fileno())
+        except (AttributeError, ValueError):
+            raise ValueError("Invalid file object: "
+                             "{!r}".format(fileobj)) from None
+    if fd < 0:
+        raise ValueError("Invalid file descriptor: {}".format(fd))
+    return fd
+
+
+SelectorKey = namedtuple('SelectorKey', ['fileobj', 'fd', 'events', 'data'])
+"""Object used to associate a file object to its backing file descriptor,
+selected event mask and attached data."""
+
+
+class BaseSelector(metaclass=ABCMeta):
+    """Base selector class.
+
+    A selector supports registering file objects to be monitored for specific
+    I/O events.
+
+    A file object is a file descriptor or any object with a `fileno()` method.
+    An arbitrary object can be attached to the file object, which can be used
+    for example to store context information, a callback, etc.
+
+    A selector can use various implementations (select(), poll(), epoll()...)
+    depending on the platform. The default `Selector` class uses the most
+    performant implementation on the current platform.
+    """
+
+    def __init__(self):
+        # this maps file descriptors to keys
+        self._fd_to_key = {}
+        # this maps file objects to keys - for fast (un)registering
+        self._fileobj_to_key = {}
+
+    def register(self, fileobj, events, data=None):
+        """Register a file object.
+
+        Parameters:
+        fileobj -- file object or file descriptor
+        events  -- events to monitor (bitwise mask of EVENT_READ|EVENT_WRITE)
+        data    -- attached data
+
+        Returns:
+        SelectorKey instance
+        """
+        if (not events) or (events & ~(EVENT_READ | EVENT_WRITE)):
+            raise ValueError("Invalid events: {}".format(events))
+
+        key = SelectorKey(fileobj, _fileobj_to_fd(fileobj), events, data)
+
+        if key.fd in self._fd_to_key:
+            raise KeyError("{!r} (FD {}) is already "
+                           "registered".format(fileobj, key.fd))
+
+        self._fd_to_key[key.fd] = key
+        self._fileobj_to_key[fileobj] = key
+        return key
+
+    def unregister(self, fileobj):
+        """Unregister a file object.
+
+        Parameters:
+        fileobj -- file object or file descriptor
+
+        Returns:
+        SelectorKey instance
+        """
+        try:
+            key = self._fileobj_to_key.pop(fileobj)
+            del self._fd_to_key[key.fd]
+        except KeyError:
+            raise KeyError("{!r} is not registered".format(fileobj)) from None
+        return key
+
+    def modify(self, fileobj, events, data=None):
+        """Change a registered file object monitored events or attached data.
+
+        Parameters:
+        fileobj -- file object or file descriptor
+        events  -- events to monitor (bitwise mask of EVENT_READ|EVENT_WRITE)
+        data    -- attached data
+
+        Returns:
+        SelectorKey instance
+        """
+        # TODO: Subclasses can probably optimize this even further.
+        try:
+            key = self._fileobj_to_key[fileobj]
+        except KeyError:
+            raise KeyError("{!r} is not registered".format(fileobj)) from None
+        if events != key.events or data != key.data:
+            # TODO: If only the data changed, use a shortcut that only
+            # updates the data.
+            self.unregister(fileobj)
+            return self.register(fileobj, events, data)
+        else:
+            return key
+
+    @abstractmethod
+    def select(self, timeout=None):
+        """Perform the actual selection, until some monitored file objects are
+        ready or a timeout expires.
+
+        Parameters:
+        timeout -- if timeout > 0, this specifies the maximum wait time, in
+                   seconds
+                   if timeout <= 0, the select() call won't block, and will
+                   report the currently ready file objects
+                   if timeout is None, select() will block until a monitored
+                   file object becomes ready
+
+        Returns:
+        list of (key, events) for ready file objects
+        `events` is a bitwise mask of EVENT_READ|EVENT_WRITE
+        """
+        raise NotImplementedError()
+
+    def close(self):
+        """Close the selector.
+
+        This must be called to make sure that any underlying resource is freed.
+        """
+        self._fd_to_key.clear()
+        self._fileobj_to_key.clear()
+
+    def get_key(self, fileobj):
+        """Return the key associated to a registered file object.
+
+        Returns:
+        SelectorKey for this file object
+        """
+        try:
+            return self._fileobj_to_key[fileobj]
+        except KeyError:
+            raise KeyError("{} is not registered".format(fileobj)) from None
+
+    def __enter__(self):
+        return self
+
+    def __exit__(self, *args):
+        self.close()
+
+    def _key_from_fd(self, fd):
+        """Return the key associated to a given file descriptor.
+
+        Parameters:
+        fd -- file descriptor
+
+        Returns:
+        corresponding key, or None if not found
+        """
+        try:
+            return self._fd_to_key[fd]
+        except KeyError:
+            return None
+
+
+class SelectSelector(BaseSelector):
+    """Select-based selector."""
+
+    def __init__(self):
+        super().__init__()
+        self._readers = set()
+        self._writers = set()
+
+    def register(self, fileobj, events, data=None):
+        key = super().register(fileobj, events, data)
+        if events & EVENT_READ:
+            self._readers.add(key.fd)
+        if events & EVENT_WRITE:
+            self._writers.add(key.fd)
+        return key
+
+    def unregister(self, fileobj):
+        key = super().unregister(fileobj)
+        self._readers.discard(key.fd)
+        self._writers.discard(key.fd)
+        return key
+
+    if sys.platform == 'win32':
+        def _select(self, r, w, _, timeout=None):
+            r, w, x = select.select(r, w, w, timeout)
+            return r, w + x, []
+    else:
+        _select = select.select
+
+    def select(self, timeout=None):
+        timeout = None if timeout is None else max(timeout, 0)
+        ready = []
+        try:
+            r, w, _ = self._select(self._readers, self._writers, [], timeout)
+        except InterruptedError:
+            return ready
+        r = set(r)
+        w = set(w)
+        for fd in r | w:
+            events = 0
+            if fd in r:
+                events |= EVENT_READ
+            if fd in w:
+                events |= EVENT_WRITE
+
+            key = self._key_from_fd(fd)
+            if key:
+                ready.append((key, events & key.events))
+        return ready
+
+
+if hasattr(select, 'poll'):
+
+    class PollSelector(BaseSelector):
+        """Poll-based selector."""
+
+        def __init__(self):
+            super().__init__()
+            self._poll = select.poll()
+
+        def register(self, fileobj, events, data=None):
+            key = super().register(fileobj, events, data)
+            poll_events = 0
+            if events & EVENT_READ:
+                poll_events |= select.POLLIN
+            if events & EVENT_WRITE:
+                poll_events |= select.POLLOUT
+            self._poll.register(key.fd, poll_events)
+            return key
+
+        def unregister(self, fileobj):
+            key = super().unregister(fileobj)
+            self._poll.unregister(key.fd)
+            return key
+
+        def select(self, timeout=None):
+            timeout = None if timeout is None else max(int(1000 * timeout), 0)
+            ready = []
+            try:
+                fd_event_list = self._poll.poll(timeout)
+            except InterruptedError:
+                return ready
+            for fd, event in fd_event_list:
+                events = 0
+                if event & ~select.POLLIN:
+                    events |= EVENT_WRITE
+                if event & ~select.POLLOUT:
+                    events |= EVENT_READ
+
+                key = self._key_from_fd(fd)
+                if key:
+                    ready.append((key, events & key.events))
+            return ready
+
+
+if hasattr(select, 'epoll'):
+
+    class EpollSelector(BaseSelector):
+        """Epoll-based selector."""
+
+        def __init__(self):
+            super().__init__()
+            self._epoll = select.epoll()
+
+        def fileno(self):
+            return self._epoll.fileno()
+
+        def register(self, fileobj, events, data=None):
+            key = super().register(fileobj, events, data)
+            epoll_events = 0
+            if events & EVENT_READ:
+                epoll_events |= select.EPOLLIN
+            if events & EVENT_WRITE:
+                epoll_events |= select.EPOLLOUT
+            self._epoll.register(key.fd, epoll_events)
+            return key
+
+        def unregister(self, fileobj):
+            key = super().unregister(fileobj)
+            self._epoll.unregister(key.fd)
+            return key
+
+        def select(self, timeout=None):
+            timeout = -1 if timeout is None else max(timeout, 0)
+            max_ev = len(self._fd_to_key)
+            ready = []
+            try:
+                fd_event_list = self._epoll.poll(timeout, max_ev)
+            except InterruptedError:
+                return ready
+            for fd, event in fd_event_list:
+                events = 0
+                if event & ~select.EPOLLIN:
+                    events |= EVENT_WRITE
+                if event & ~select.EPOLLOUT:
+                    events |= EVENT_READ
+
+                key = self._key_from_fd(fd)
+                if key:
+                    ready.append((key, events & key.events))
+            return ready
+
+        def close(self):
+            super().close()
+            self._epoll.close()
+
+
+if hasattr(select, 'kqueue'):
+
+    class KqueueSelector(BaseSelector):
+        """Kqueue-based selector."""
+
+        def __init__(self):
+            super().__init__()
+            self._kqueue = select.kqueue()
+
+        def fileno(self):
+            return self._kqueue.fileno()
+
+        def register(self, fileobj, events, data=None):
+            key = super().register(fileobj, events, data)
+            if events & EVENT_READ:
+                kev = select.kevent(key.fd, select.KQ_FILTER_READ,
+                                    select.KQ_EV_ADD)
+                self._kqueue.control([kev], 0, 0)
+            if events & EVENT_WRITE:
+                kev = select.kevent(key.fd, select.KQ_FILTER_WRITE,
+                                    select.KQ_EV_ADD)
+                self._kqueue.control([kev], 0, 0)
+            return key
+
+        def unregister(self, fileobj):
+            key = super().unregister(fileobj)
+            if key.events & EVENT_READ:
+                kev = select.kevent(key.fd, select.KQ_FILTER_READ,
+                                    select.KQ_EV_DELETE)
+                self._kqueue.control([kev], 0, 0)
+            if key.events & EVENT_WRITE:
+                kev = select.kevent(key.fd, select.KQ_FILTER_WRITE,
+                                    select.KQ_EV_DELETE)
+                self._kqueue.control([kev], 0, 0)
+            return key
+
+        def select(self, timeout=None):
+            timeout = None if timeout is None else max(timeout, 0)
+            max_ev = len(self._fd_to_key)
+            ready = []
+            try:
+                kev_list = self._kqueue.control(None, max_ev, timeout)
+            except InterruptedError:
+                return ready
+            for kev in kev_list:
+                fd = kev.ident
+                flag = kev.filter
+                events = 0
+                if flag == select.KQ_FILTER_READ:
+                    events |= EVENT_READ
+                if flag == select.KQ_FILTER_WRITE:
+                    events |= EVENT_WRITE
+
+                key = self._key_from_fd(fd)
+                if key:
+                    ready.append((key, events & key.events))
+            return ready
+
+        def close(self):
+            super().close()
+            self._kqueue.close()
+
+
+# Choose the best implementation: roughly, epoll|kqueue > poll > select.
+# select() also can't accept a FD > FD_SETSIZE (usually around 1024)
+if 'KqueueSelector' in globals():
+    DefaultSelector = KqueueSelector
+elif 'EpollSelector' in globals():
+    DefaultSelector = EpollSelector
+elif 'PollSelector' in globals():
+    DefaultSelector = PollSelector
+else:
+    DefaultSelector = SelectSelector
diff -r 78f3c32a92ce Lib/test/test_selectors.py
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Lib/test/test_selectors.py	Sat Aug 31 17:47:17 2013 +0200
@@ -0,0 +1,387 @@
+import errno
+import random
+import selectors
+import signal
+import socket
+from test import support
+import unittest
+try:
+    from time import monotonic as time
+except ImportError:
+    from time import time as time
+from time import sleep
+try:
+    import resource
+except ImportError:
+    resource = None
+
+
+if hasattr(socket, 'socketpair'):
+    socketpair = socket.socketpair
+else:
+    def socketpair(family=socket.AF_INET, type=socket.SOCK_STREAM, proto=0):
+        with socket.socket(family, type, proto) as l:
+            l.bind(('127.0.0.1', 0))
+            l.listen(3)
+            c = socket.socket(family, type, proto)
+            try:
+                c.connect(l.getsockname())
+                caddr = c.getsockname()
+                while True:
+                    a, addr = l.accept()
+                    # check that we've got the correct client
+                    if addr == caddr:
+                        return c, a
+                    a.close()
+            except OSError:
+                c.close()
+                raise
+
+
+def find_ready_matching(ready, flag):
+    match = []
+    for key, events in ready:
+        if events & flag:
+            match.append(key.fileobj)
+    return match
+
+
+class BaseSelectorTestCase(unittest.TestCase):
+
+    def test_register(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        key = s.register(rd, selectors.EVENT_READ, "data")
+        self.assertIsInstance(key, selectors.SelectorKey)
+        self.assertEqual(key.fileobj, rd)
+        self.assertEqual(key.fd, rd.fileno())
+        self.assertEqual(key.events, selectors.EVENT_READ)
+        self.assertEqual(key.data, "data")
+
+        # register an unknown event
+        self.assertRaises(ValueError, s.register, 0, 999999)
+
+        # register an invalid FD
+        self.assertRaises(ValueError, s.register, -10, selectors.EVENT_READ)
+
+        # register twice
+        self.assertRaises(KeyError, s.register, rd, selectors.EVENT_READ)
+
+        # register the same FD, but with a different object
+        self.assertRaises(KeyError, s.register, rd.fileno(),
+                          selectors.EVENT_READ)
+
+    def test_unregister(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        s.register(rd, selectors.EVENT_READ)
+        s.unregister(rd)
+
+        # unregister an unknown file obj
+        self.assertRaises(KeyError, s.unregister, 999999)
+
+        # unregister twice
+        self.assertRaises(KeyError, s.unregister, rd)
+
+    def test_modify(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        key = s.register(rd, selectors.EVENT_READ)
+
+        # modify events
+        key2 = s.modify(rd, selectors.EVENT_WRITE)
+        self.assertNotEqual(key.events, key2.events)
+        self.assertEqual(key2, s.get_key(rd))
+
+        s.unregister(rd)
+
+        # modify data
+        d1 = object()
+        d2 = object()
+
+        key = s.register(rd, selectors.EVENT_READ, d1)
+        key2 = s.modify(rd, selectors.EVENT_READ, d2)
+        self.assertEqual(key.events, key2.events)
+        self.assertNotEqual(key.data, key2.data)
+        self.assertEqual(key2, s.get_key(rd))
+
+        # modify unknown file obj
+        self.assertRaises(KeyError, s.modify, 999999, selectors.EVENT_READ)
+
+    def test_close(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        s.register(rd, selectors.EVENT_READ)
+        s.register(wr, selectors.EVENT_WRITE)
+
+        s.close()
+        self.assertRaises(KeyError, s.get_key, rd)
+        self.assertRaises(KeyError, s.get_key, wr)
+
+    def test_get_key(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        key = s.register(rd, selectors.EVENT_READ, "data")
+        self.assertEqual(key, s.get_key(rd))
+
+        # unknown file obj
+        self.assertRaises(KeyError, s.get_key, 999999)
+
+    def test_select(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        s.register(rd, selectors.EVENT_READ)
+        wr_key = s.register(wr, selectors.EVENT_WRITE)
+
+        result = s.select()
+        for key, events in result:
+            self.assertTrue(isinstance(key, selectors.SelectorKey))
+            self.assertTrue(events)
+            self.assertFalse(events & ~(selectors.EVENT_READ |
+                                        selectors.EVENT_WRITE))
+
+        self.assertEqual([(wr_key, selectors.EVENT_WRITE)], result)
+
+    def test_context_manager(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        with s as sel:
+            sel.register(rd, selectors.EVENT_READ)
+            sel.register(wr, selectors.EVENT_WRITE)
+
+        self.assertRaises(KeyError, s.get_key, rd)
+        self.assertRaises(KeyError, s.get_key, wr)
+
+    def test_fileno(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        if hasattr(s, 'fileno'):
+            fd = s.fileno()
+            self.assertTrue(isinstance(fd, int))
+            self.assertGreaterEqual(fd, 0)
+
+    def test_selector(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        NUM_SOCKETS = 12
+        MSG = b" This is a test."
+        MSG_LEN = len(MSG)
+        readers = []
+        writers = []
+        r2w = {}
+        w2r = {}
+
+        for i in range(NUM_SOCKETS):
+            rd, wr = socketpair()
+            self.addCleanup(rd.close)
+            self.addCleanup(wr.close)
+            s.register(rd, selectors.EVENT_READ)
+            s.register(wr, selectors.EVENT_WRITE)
+            readers.append(rd)
+            writers.append(wr)
+            r2w[rd] = wr
+            w2r[wr] = rd
+
+        bufs = []
+
+        while writers:
+            ready = s.select()
+            ready_writers = find_ready_matching(ready, selectors.EVENT_WRITE)
+            if not ready_writers:
+                self.fail("no sockets ready for writing")
+            wr = random.choice(ready_writers)
+            wr.send(MSG)
+
+            for i in range(10):
+                ready = s.select()
+                ready_readers = find_ready_matching(ready,
+                                                    selectors.EVENT_READ)
+                if ready_readers:
+                    break
+                # there might be delay between the write to the write end and
+                # the read end is reported ready
+                sleep(0.1)
+            else:
+                self.fail("no sockets ready for reading")
+            self.assertEqual([w2r[wr]], ready_readers)
+            rd = ready_readers[0]
+            buf = rd.recv(MSG_LEN)
+            self.assertEqual(len(buf), MSG_LEN)
+            bufs.append(buf)
+            s.unregister(r2w[rd])
+            s.unregister(rd)
+            writers.remove(r2w[rd])
+
+        self.assertEqual(bufs, [MSG] * NUM_SOCKETS)
+
+    def test_timeout(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        s.register(wr, selectors.EVENT_WRITE)
+        self.assertEqual(1, len(s.select(0)))
+        self.assertEqual(1, len(s.select(-1)))
+
+        s.unregister(wr)
+        s.register(rd, selectors.EVENT_READ)
+        t = time()
+        self.assertFalse(s.select(0))
+        self.assertFalse(s.select(-1))
+        self.assertTrue(time() - t < 0.3)
+
+        t = time()
+        self.assertFalse(s.select(1))
+        self.assertTrue(0.7 < time() - t < 1.3)
+
+    @unittest.skipUnless(hasattr(signal, "alarm"),
+                         "signal.alarm() required for this test")
+    def test_interrupted_retry(self):
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        rd, wr = socketpair()
+        self.addCleanup(rd.close)
+        self.addCleanup(wr.close)
+
+        orig_alrm_handler = signal.signal(signal.SIGALRM, lambda *args: None)
+        self.addCleanup(signal.alarm, 0)
+        self.addCleanup(signal.signal, signal.SIGALRM, orig_alrm_handler)
+
+        signal.alarm(1)
+
+        s.register(rd, selectors.EVENT_READ)
+        t = time()
+        self.assertFalse(s.select(2))
+        self.assertLess(time() - t, 2.3)
+
+
+class ScalableSelectorMixIn:
+
+    @support.requires_mac_ver(10, 5)
+    @unittest.skipUnless(resource, "Test needs resource module")
+    def test_above_fd_setsize(self):
+        # A scalable implementation should have no problem with more than
+        # FD_SETSIZE file descriptors. Since we don't know the value, we just
+        # try to set the soft RLIMIT_NOFILE to the hard RLIMIT_NOFILE ceiling.
+        soft, hard = resource.getrlimit(resource.RLIMIT_NOFILE)
+        try:
+            resource.setrlimit(resource.RLIMIT_NOFILE, (hard, hard))
+            self.addCleanup(resource.setrlimit, resource.RLIMIT_NOFILE,
+                            (soft, hard))
+            NUM_FDS = hard
+        except OSError:
+            NUM_FDS = soft
+
+        # guard for already allocated FDs (stdin, stdout...)
+        NUM_FDS -= 32
+
+        s = self.SELECTOR()
+        self.addCleanup(s.close)
+
+        for i in range(NUM_FDS // 2):
+            try:
+                rd, wr = socketpair()
+            except OSError:
+                # too many FD, skip - note that we should only catch EMFILE
+                # here, but apparently *BSD and Solaris can fail upon connect()
+                # or bind() with EADDRNOTAVAIL, so let's be safe
+                self.skipTest("FD limit reached")
+
+            self.addCleanup(rd.close)
+            self.addCleanup(wr.close)
+
+            try:
+                s.register(rd, selectors.EVENT_READ)
+                s.register(wr, selectors.EVENT_WRITE)
+            except OSError as e:
+                if e.errno == errno.ENOSPC:
+                    # this can be raised by epoll if we go over
+                    # fs.epoll.max_user_watches sysctl
+                    self.skipTest("FD limit reached")
+                raise
+
+        self.assertEqual(NUM_FDS // 2, len(s.select()))
+
+
+class DefaultSelectorTestCase(BaseSelectorTestCase):
+
+    SELECTOR = selectors.DefaultSelector
+
+
+class SelectSelectorTestCase(BaseSelectorTestCase):
+
+    SELECTOR = selectors.SelectSelector
+
+
+ at unittest.skipUnless(hasattr(selectors, 'PollSelector'),
+                     "Test needs selectors.PollSelector")
+class PollSelectorTestCase(BaseSelectorTestCase, ScalableSelectorMixIn):
+
+    SELECTOR = getattr(selectors, 'PollSelector', None)
+
+
+ at unittest.skipUnless(hasattr(selectors, 'EpollSelector'),
+                     "Test needs selectors.EpollSelector")
+class EpollSelectorTestCase(BaseSelectorTestCase, ScalableSelectorMixIn):
+
+    SELECTOR = getattr(selectors, 'EpollSelector', None)
+
+
+ at unittest.skipUnless(hasattr(selectors, 'KqueueSelector'),
+                     "Test needs selectors.KqueueSelector)")
+class KqueueSelectorTestCase(BaseSelectorTestCase, ScalableSelectorMixIn):
+
+    SELECTOR = getattr(selectors, 'KqueueSelector', None)
+
+
+def test_main():
+    tests = [DefaultSelectorTestCase, SelectSelectorTestCase,
+             PollSelectorTestCase, EpollSelectorTestCase,
+             KqueueSelectorTestCase]
+    support.run_unittest(*tests)
+    support.reap_children()
+
+
+if __name__ == "__main__":
+    test_main()

From report at bugs.python.org  Sat Aug 31 19:11:55 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Aug 2013 17:11:55 +0000
Subject: [issue18831] importlib.import_module() bypasses builtins.__import__
In-Reply-To: <1377443801.78.0.926402532335.issue18831@psf.upfronthosting.co.za>
Message-ID: <1377969115.88.0.195479100868.issue18831@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Adding something like '(not builtins.__import__)' or '(different from builtins.__import__') after 'importlib.__import__' should reduce the possibility of confusing the two and expecting something that will not happen.

You might check the doc for (builtins.)__import__ to make sure it does not promise anything that is no longer true.

What happens if people monkeypatch importlib.__import__?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18831>
_______________________________________

From report at bugs.python.org  Sat Aug 31 19:15:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 17:15:46 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1377969346.57.0.887110118196.issue16853@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Here's a patch returning [] on EINTR.

Hmm... Shouldn't it simply let the InterruptedError bubble up?
I know there's the sleep() precedent, but I find it a bit embarassing actually: the call can return early, but there's no way for the caller to know that it returned early.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Sat Aug 31 19:19:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Aug 2013 17:19:16 +0000
Subject: [issue18780] SystemError when formatting int subclass
In-Reply-To: <1376921434.69.0.557024484243.issue18780@psf.upfronthosting.co.za>
Message-ID: <3cS46W5sp3zPkT@mail.python.org>


Roundup Robot added the comment:

New changeset 33727fbb4668 by Ethan Furman in branch 'default':
Close #18780: %-formatting now prints value for int subclasses with %d, %i, and %u codes.
http://hg.python.org/cpython/rev/33727fbb4668

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18780>
_______________________________________

From report at bugs.python.org  Sat Aug 31 19:19:22 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 31 Aug 2013 17:19:22 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377968189.2.0.575176543025.issue18885@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJK2kb1DOmxx+0zoD+y=+45FV7N7R-FZSS=HD-ErOvCQMA@mail.gmail.com>


Guido van Rossum added the comment:

On Sat, Aug 31, 2013 at 9:56 AM, Charles-Fran?ois Natali
<report at bugs.python.org> wrote:
>
> Charles-Fran?ois Natali added the comment:
>
> Gregory, thanks, that's what I was planning to do.
>
> But since the recent discussions (mainly on selectors), there are points I obviously don't - and won't - agree with (such as select() returning EINTR or returning early, same for sleep()), I'm not interested in this anymore.

Whoa. Maybe you're overreacting a bit? I personally see a big divide
here between system calls whose functionality includes sleeping (e.g.
sleep(), poll(), select()) and those that just want some I/O to
complete (e.g. recv(), send(), read(), write()). The former are almost
always used in a context that can handle premature returns just fine,
since the return value for a premature return is the same as for
hitting the deadline, and the timeout is often used just as a hint
anyway. It's the latter category (recv() etc.) where the EINTR return
is problematic, and I think for many of those the automatic retry
(after the Python-level signal handler has been run and conditional on
it not raising an exception) will be a big improvement.

> Anyone interested can pick this up, though.
>
> (BTW, as for applications relying on EINTR being returned, I'm positive *way more applications* will break because of the recent change making file descriptors close-on-exec by default).

Again, I'd make a distinction: I agree for send(), recv() etc., but I
don't think there are many buggy uses of select()/poll() timeouts
around. (And even if there are, I still think it's better to fix these
by correcting the retry logic in the framework or the application,
since it may have other considerations.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18885>
_______________________________________

From report at bugs.python.org  Sat Aug 31 19:26:47 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 31 Aug 2013 17:26:47 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1377970007.21.0.0807878291921.issue16853@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Hm... I like the [] return just fine, it matches what Tulip's selector did.  The framework should be re-checking the clock anyway -- it's possible that select() returned late too...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16853>
_______________________________________

From report at bugs.python.org  Sat Aug 31 19:32:25 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Aug 2013 17:32:25 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1377970345.3.0.730180876014.issue18889@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

As I said on #12037, I would rather \r was not in the file. I do not know if it is present in the master repository or added by hg when cloning.

Buildbots and developer desktops are different environments. The tests must work on both.

Nit 1: right, I should have seen that. On #12037, I originally did the conversion in the test call.

Nit 2: why? The test passes as is.

Please pick a solution, test it on non-Windows if you can, and apply it so I can have the test suite pass on Windows after I apply a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18889>
_______________________________________

From report at bugs.python.org  Sat Aug 31 19:36:04 2013
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Sat, 31 Aug 2013 17:36:04 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377970564.02.0.0732788046931.issue18843@psf.upfronthosting.co.za>


Stephen J. Turnbull added the comment:

I did "emerge =dev-lang/python-2.7.5-r1" *twice* with the environment configuration described in msg196520, then *once* with it disabled because one of the cases you described was when you tried to revert to a non-debug Python.  (Besides, I am willing to risk your crash while I'm watching for it, but not a time bomb that will go off when I'm on deadline :-).  All builds succeeded and all passed the test suite.  Here's how the debug build describes itself:

== CPython 2.7.5 (default, Sep 1 2013, 00:59:02) [GCC 4.6.4] 
==   Linux-3.9.0-x86_64-Dual_Core_AMD_Opteron-tm-_Processor_265-with-gentoo-2.2 little-endian 

The test suite ran uneventfully (with a few DeprecationWarnings) except for this:

6 skips unexpected on linux2: 
    test_bsddb test_bsddb3 test_tcl test_tk test_ttk_guionly 
    test_ttk_textonly 

but I suppose that is expected on Gentoo.  If any of those modules (bsddb, tcl, tk) are built into your Python, a problem in one of those might be the culprit.

Oh, damn.  I just reread the whole thread.  For some reason I thought you were using gcc 4.6.4, but now I see you report 4.7.3.  OK build with 4.7.3 and your flags (also restore the --with-pydebug config):

# export CFLAGS=" -ggdb -pipe -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -mavx -maes -mpclmul -mpopcnt"
# export CXXFLAGS="${CFLAGS}"
# export CC=gcc-4.7.3

and we crash (from make output) immediately after linking ./python:

x86_64-pc-linux-gnu-ranlib libpython2.7.a 
gcc-4.7.3 -pthread -Wl,--hash-style=gnu -Wl,-O1 -Wl,--as-needed -L. -Xlinker -export-dynamic -o python \ 
                Modules/python.o \ 
                -L. -lpython2.7 -lpthread -ldl  -lutil   -lm   
LD_LIBRARY_PATH=/var/tmp/portage/dev-lang/python-2.7.5-r1/work/x86_64-pc-linux-gnu: ./python -E -S -m sysconfig --generate-posix-vars 
make: *** [pybuilddir.txt] Illegal instruction 

However, I'm pretty sure this is due to my hardware not liking your -m flags, not the crash you reported.  I'll try backing those flags out, but if anybody has a suggestion for the most aggressive set similar to yours, I'd appreciate it.

But first this process is going to go sleep(25200).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Sat Aug 31 19:36:18 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 31 Aug 2013 17:36:18 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377970578.76.0.322369803068.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

Someone may find the new stress.valgrind.stderr interesting, but - since I've never used valgrind - it doesn't mean much to me.

I _expected_ you'd run the little stress program under a debug Python and without valgrind, since that's the only combination you've tried so far that showed a definite problem ("pad leading pad byte" death, or the segfault in the other issue you filed).

But it doesn't much matter - this is all just thrashing at random, yes?  You need to find a reproducible test case, and/or try different hardware.  The little stress program may or may not provoke an error under a debug-build Python, and may or may not require increasing N (to consume more RAM).

If it does provoke an error, the next thing to try would be to write a little program that just writes 0xfb across a massive number of bytes, and then reads them all to verify they're still 0xfb.  Or write one like that now, and preferably in C (it may matter how quickly the bytes are written - and it may not matter).  But at this point youj're starting to write your own memory-testing program.

In any case, there's really no evidence of an error in Python so far.  Yes, Python has _detected_ a problem in some cases.  But without a reproducible test case, I don't see that there's anything more we can do for you on our end - sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________

From report at bugs.python.org  Sat Aug 31 19:53:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 17:53:16 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <1377971596.23.0.729742577701.issue18882@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, some comments about the patch (no "review" links appears so I'm gonna do it inline here):

- the doc addition needs a "versionadded" tag

- "The main thread is the thread that the OS creates to run application.": I would rephrase this "In normal conditions, the main thread is the thread from which the Python interpreter was started".

- in the tests:
+        self.assertEqual(data, "Thread-1\nTrue\nTrue\n")

Hmm, how do you know it will be called "Thread-1"?
I would give a specific name to the Thread, so as to make the test deterministic.

+        self.assertEqual(rc, 0)

You don't need this, it is already ensured by assert_python_ok().

- in threading.py, why doesn't _exitfunc() reuse the _main_thread global variable, instead of taking it as a parameter?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18882>
_______________________________________

From report at bugs.python.org  Sat Aug 31 19:55:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Aug 2013 17:55:42 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <3cS4wY2kGBzPkT@mail.python.org>


Roundup Robot added the comment:

New changeset 868ad6fa8e68 by Andrew Svetlov in branch 'default':
Temporary disable tests cleanup (issue 11798).
http://hg.python.org/cpython/rev/868ad6fa8e68

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sat Aug 31 20:05:10 2013
From: report at bugs.python.org (Alori)
Date: Sat, 31 Aug 2013 18:05:10 +0000
Subject: [issue18896] Remove namedtuple 255 arguments restriction
Message-ID: <1377972310.66.0.567176219008.issue18896@psf.upfronthosting.co.za>


New submission from Alori:

Named tuples offer a useful mix of features from both dict and tuple data structures. However, unlike dictionaries and tuples, Named tuples are only allowed to hold up to 255 items.

This behavior seems inconsistent and un-Pythonic.
Is there a way to remove this restriction? Why not set a much higher limit?

Also see:
http://grokbase.com/t/python/python-ideas/109hbv63sv/new-3-x-restriction-on-number-of-keyword-arguments#responses_tab_top

http://stackoverflow.com/questions/18550270/any-way-to-bypass-namedtuple-255-arguments-limitation

----------
messages: 196660
nosy: valorien
priority: normal
severity: normal
status: open
title: Remove namedtuple 255 arguments restriction
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18896>
_______________________________________

From report at bugs.python.org  Sat Aug 31 20:09:31 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 31 Aug 2013 18:09:31 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1377972571.08.0.0737120008005.issue18885@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I wrote too many words.  In short:

time.sleep()'s behavior should remain as it is today given how it is documented to behave.  If you disagree, consider adding an optional interruptable=False parameter so that both behavior options exist.

ALL IO calls and wait* should handle EINTR transparently for the user and never expose it to the Python application.

select(), poll() and equivalents.  If you want to transparently handle EINTR on these, just make sure you deal with the timeouts properly.  While I suspect a few people wanted to see the signal interruption on those I agree: very uncommon and undesirable for most.

If people need a specific signal interruption they should define a signal handler that raises.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18885>
_______________________________________

From report at bugs.python.org  Sat Aug 31 20:43:23 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 31 Aug 2013 18:43:23 +0000
Subject: [issue17276] HMAC: deprecate default hash
In-Reply-To: <1361535402.96.0.618065106631.issue17276@psf.upfronthosting.co.za>
Message-ID: <1377974603.29.0.497766622067.issue17276@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

comments added to the review.

I don't think a DeprecationWarning should be raised as that'll infuriate users of python programs more than developers who can fix code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17276>
_______________________________________

From report at bugs.python.org  Sat Aug 31 20:44:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 18:44:23 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377974663.76.0.207502707852.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, here is a new patch observing the timeout parameter. I've changed the implementation strategy a bit, it seems hopefully sane.

There's a remaining (slightly bordeline) issue: the thread state lock isn't reinitialized on fork(). Should it?

----------
Added file: http://bugs.python.org/file31537/threadstate_join_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Aug 31 20:47:20 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 31 Aug 2013 18:47:20 +0000
Subject: [issue18896] Remove namedtuple 255 arguments restriction
In-Reply-To: <1377972310.66.0.567176219008.issue18896@psf.upfronthosting.co.za>
Message-ID: <1377974840.11.0.232179597281.issue18896@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18896>
_______________________________________

From report at bugs.python.org  Sat Aug 31 20:47:37 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 31 Aug 2013 18:47:37 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1377974857.33.0.773143459887.issue18885@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18885>
_______________________________________

From report at bugs.python.org  Sat Aug 31 20:49:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 18:49:56 +0000
Subject: [issue18896] Remove namedtuple 255 arguments restriction
In-Reply-To: <1377972310.66.0.567176219008.issue18896@psf.upfronthosting.co.za>
Message-ID: <1377974996.56.0.699037739515.issue18896@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'll let Raymond give his answer here, but namedtuples are meant as lightweight structures or records (if you know C, think "struct"), not arbitrary containers.

----------
nosy: +pitrou, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18896>
_______________________________________

From report at bugs.python.org  Sat Aug 31 20:51:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 18:51:27 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1377975087.75.0.644188896823.issue11798@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Er... your latest commit broke this issue's own tests!

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sat Aug 31 20:58:52 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 31 Aug 2013 18:58:52 +0000
Subject: [issue12304] expose signalfd(2) in the signal module
In-Reply-To: <1307660456.9.0.497118052372.issue12304@psf.upfronthosting.co.za>
Message-ID: <1377975532.07.0.284217083309.issue12304@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12304>
_______________________________________

From report at bugs.python.org  Sat Aug 31 21:04:46 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 31 Aug 2013 19:04:46 +0000
Subject: [issue18100] socket.sendall() cannot send buffers of 2GB or more
In-Reply-To: <1369918582.13.0.605373457603.issue18100@psf.upfronthosting.co.za>
Message-ID: <1377975886.14.0.752343349807.issue18100@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18100>
_______________________________________

From report at bugs.python.org  Sat Aug 31 21:05:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 19:05:33 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>
Message-ID: <1377975933.51.0.869777044265.issue18876@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks for the patch. It looks mostly ok.
Could you sign a contributor agreement so that we can move forward?
http://www.python.org/psf/contrib/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18876>
_______________________________________

From report at bugs.python.org  Sat Aug 31 21:33:38 2013
From: report at bugs.python.org (Alori)
Date: Sat, 31 Aug 2013 19:33:38 +0000
Subject: [issue18896] Remove namedtuple 255 arguments restriction
In-Reply-To: <1377972310.66.0.567176219008.issue18896@psf.upfronthosting.co.za>
Message-ID: <1377977618.14.0.577235264509.issue18896@psf.upfronthosting.co.za>


Alori added the comment:

@pitrou:
Thank you for your answer.
I agree they should not replace databases or files, but I think 255 is just way too lightweight. It feels unnatural to have this limitation for no specific reason. 

Recently, I've seen a lot of solutions that emulate the namedtuple functionality with some classes in order to workaround this issue, but they all feel "forced" and require some unsavory hacks.

I think namedtuple is one the most useful structures in the language, and like tuples and dicts, shouldn't be limited by design.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18896>
_______________________________________

From report at bugs.python.org  Sat Aug 31 21:49:06 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Aug 2013 19:49:06 +0000
Subject: [issue18780] SystemError when formatting int subclass
In-Reply-To: <1376921434.69.0.557024484243.issue18780@psf.upfronthosting.co.za>
Message-ID: <3cS7RQ0zMDzP77@mail.python.org>


Roundup Robot added the comment:

New changeset 833246d42825 by Ethan Furman in branch 'default':
Issue #18780: code cleanup.
http://hg.python.org/cpython/rev/833246d42825

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18780>
_______________________________________

From report at bugs.python.org  Sat Aug 31 22:29:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Aug 2013 20:29:20 +0000
Subject: [issue18489] IDLE Unit test for SearchEngine.py
In-Reply-To: <1374118219.91.0.797974191988.issue18489@psf.upfronthosting.co.za>
Message-ID: <3cS8Kr1rTxzM9M@mail.python.org>


Roundup Robot added the comment:

New changeset 4179e2312089 by Terry Jan Reedy in branch '2.7':
Issue #18489: Add complete, gui-free tests for idlelib.SearchEngine.
http://hg.python.org/cpython/rev/4179e2312089

New changeset dfbf0f9034cc by Terry Jan Reedy in branch '3.3':
Issue #18489: Add complete, gui-free tests for idlelib.SearchEngine.
http://hg.python.org/cpython/rev/dfbf0f9034cc

New changeset 7605847c15a4 by Terry Jan Reedy in branch 'default':
Merge from 3.3 #18489 Search Engine tests
http://hg.python.org/cpython/rev/7605847c15a4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18489>
_______________________________________

From report at bugs.python.org  Sat Aug 31 22:32:03 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Aug 2013 20:32:03 +0000
Subject: [issue18489] IDLE Unit test for SearchEngine.py
In-Reply-To: <1374118219.91.0.797974191988.issue18489@psf.upfronthosting.co.za>
Message-ID: <1377981123.38.0.478872547428.issue18489@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

By masking mock Text.index with instance functions, I removed the need for tk.Text and hence the tests are gui free.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18489>
_______________________________________

From report at bugs.python.org  Sat Aug 31 22:46:08 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 31 Aug 2013 20:46:08 +0000
Subject: [issue18831] importlib.import_module() bypasses builtins.__import__
In-Reply-To: <1377443801.78.0.926402532335.issue18831@psf.upfronthosting.co.za>
Message-ID: <1377981968.91.0.701350985576.issue18831@psf.upfronthosting.co.za>


Brett Cannon added the comment:

help(__import__) doesn't mention anything about overriding the function. I already touched up the stdlib docs for builtins.__import__ to strongly advise you don't override the function.

As for overriding importlib.__import__, it won't do anything; the code for importlib.import_module() cuts through the cruft in __import__ that is unneeded and skips straight to the relevant code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18831>
_______________________________________

From report at bugs.python.org  Sat Aug 31 23:01:24 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 31 Aug 2013 21:01:24 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1377982884.97.0.741244299739.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

I'm getting a headache now - LOL ;-)  Thanks for the explanation!

What I still don't understand:  the new lock is an internal implementation detail.  How would it gain a weakref with a callback?  Users aren't going to mess with this lock, and if you want to stop Python maintainers from giving it a weakref with a callback, simply say they shouldn't do that (in the code comments) - you could even add code verifying it doesn't have any weakrefs outstanding (although that would likely be a waste of time and code:  no maintainer is going to _want_ to make a weakref to it, let alone a weakref with a callback).

My concern is the bulk and obscurity of this code, all to plug such a minor hole.  I call it "minor" because it's been reported once in the history of the project, and Tamas wormed around it with a 1-liner (added a sleep).

Granted, it's much harder to fix "for real" and when most of the interpreter has been destroyed ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Aug 31 23:16:03 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Aug 2013 21:16:03 +0000
Subject: [issue12037] test_email failures under Windows with the eol extension
 activated
In-Reply-To: <1304958829.88.0.465488458456.issue12037@psf.upfronthosting.co.za>
Message-ID: <3cS9Mk3wPlzRCM@mail.python.org>


Roundup Robot added the comment:

New changeset f0eedca4b2a2 by Terry Jan Reedy in branch '3.3':
Issue #12037: Fix test_email for desktop Windows.
http://hg.python.org/cpython/rev/f0eedca4b2a2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12037>
_______________________________________

From report at bugs.python.org  Sat Aug 31 23:17:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Aug 2013 21:17:07 +0000
Subject: [issue12037] test_email failures under Windows with the eol extension
 activated
In-Reply-To: <1304958829.88.0.465488458456.issue12037@psf.upfronthosting.co.za>
Message-ID: <3cS9Ny5db1zRCM@mail.python.org>


Roundup Robot added the comment:

New changeset 5600e9a5c35d by Terry Jan Reedy in branch 'default':
Issue #12037: Fix test_email for desktop Windows.
http://hg.python.org/cpython/rev/5600e9a5c35d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12037>
_______________________________________

From report at bugs.python.org  Sat Aug 31 23:19:05 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Aug 2013 21:19:05 +0000
Subject: [issue12037] test_email failures under desktop Windows
In-Reply-To: <1304958829.88.0.465488458456.issue12037@psf.upfronthosting.co.za>
Message-ID: <1377983945.2.0.338359870181.issue12037@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
title: test_email failures under Windows with the eol extension activated -> test_email failures under desktop Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12037>
_______________________________________

From report at bugs.python.org  Sat Aug 31 23:35:54 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Aug 2013 21:35:54 +0000
Subject: [issue18831] importlib.import_module() bypasses builtins.__import__
In-Reply-To: <1377443801.78.0.926402532335.issue18831@psf.upfronthosting.co.za>
Message-ID: <1377984954.13.0.930666607286.issue18831@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Looking at the actual doc:
"importlib.__import__(name, globals=None, locals=None, fromlist=(), level=0) An implementation of the built-in __import__() function."

I think this is pretty clear that builtin.__import__ has no effect unless directly called.

"importlib.import_module(name, package=None)...The import_module() function acts as a simplifying wrapper around importlib.__import__()."

The word 'wrapper' implies that import_module calls __import__, but you say it currently does not. So if you want to keep the code as is, I would change 'acts as a simplifying wrapper around' to 'is a simplified version of', which makes no promises.

Do you really want people to directly call importlib.__import__? If not, maybe the nearly empty entry should be deleted and the entry for import_module changed to make no reference to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18831>
_______________________________________

From report at bugs.python.org  Sat Aug 31 23:42:08 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 31 Aug 2013 21:42:08 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1377985328.18.0.965878094724.issue18738@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Final (hopefully ;) patch attached.  Thanks, Eli, for your comments and help.

----------
Added file: http://bugs.python.org/file31538/issue18738.stoneleaf.04.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________

From report at bugs.python.org  Sat Aug 31 23:47:47 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 31 Aug 2013 21:47:47 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1377985667.24.0.988441969731.issue18738@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thanks, Eric, for teaching me a bunch about format.  :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________