Roundup Robot added the comment:
New changeset 749fd043de95 by Berker Peksag in branch '3.4':
Issue #23400: Raise same exception on both Python 2 and 3 if sem_open is not
available.
https://hg.python.org/cpython/rev/749fd043de95
New changeset a49737bd6086 by Berker Peksag in branch 'default':
Roundup Robot added the comment:
New changeset c2f6b3677630 by Berker Peksag in branch '2.7':
Issue #23400: Add notes about the sem_open support of the host OS to
https://hg.python.org/cpython/rev/c2f6b3677630
--
___
Python tracker
Berker Peksag added the comment:
Fixed. Thank you all (and sorry for my late commit, Davin).
--
resolution: - fixed
stage: commit review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23400
Davin Potts added the comment:
Attaching updated single patch for both default/3.5 and 3.4 to use Serhiy's
insightful simplification.
This updated patch has been tested on current Debian Hurd (see earlier comments
about full battery of tests there) and OS X 10.10 (full, verbose tests).
Note
Davin Potts added the comment:
No, I suggested to replace only the line that produces AttributeError now.
Ah! Sorry, I misunderstood and incorrectly assumed you were imagining the
import to happen at the top of the module.
I must confess I am hesitant about the idea of putting an import
Serhiy Storchaka added the comment:
But if this change is worth, I would write it as
-maxsize = _multiprocessing.SemLock.SEM_VALUE_MAX
+# Can raise ImportError (see issues #3770 and #23400)
+from .synchronize import SEM_VALUE_MAX as maxsize
This would avoid
Serhiy Storchaka added the comment:
I'm not sure that this issue is worth to fix. AttributeError is not worse than
ImportError, and users of 3.x expect AttributeError (if expect).
--
nosy: +brett.cannon, eric.snow, jnoller, ncoghlan, sbt, serhiy.storchaka
Davin Potts added the comment:
Please keep in mind that this issue should only be encountered by people using
Python 3.x on a platform like Hurd (an unsupported platform) that has no
working sem_open implementation. If we try to imagine what Python 3.x users
should expect, it's that they
Berker Peksag added the comment:
If not, I am tempted to bend on my instinctive reaction here and go with
Serhiy's style.
+1 to Serhiy's suggestion.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23400
Serhiy Storchaka added the comment:
Please keep in mind that this issue should only be encountered by people
using Python 3.x on a platform like Hurd (an unsupported platform) that has
no working sem_open implementation.
Yes, and I compiled Python with disabled sem_open for testing.
Python
Berker Peksag added the comment:
LGTM
--
stage: patch review - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23400
___
___
Davin Potts added the comment:
Attaching a further revised patch for 3.4 and 3.5/default, now with cleaned-up
code style per the discussion in the review.
No changes are prompted for the patch to 2.7 as it only contained changes to
the docs and nothing code-related.
Thanks again goes to
Changes by Davin Potts pyt...@discontinuity.net:
Added file: http://bugs.python.org/file38175/issue23400_py27_improveddocs.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23400
___
Davin Potts added the comment:
Attaching revised patches with improved phrasing in the changes to the docs.
Thanks goes to Berker for reviewing and providing helpful feedback, especially
paying close attention to detail in the docs.
--
Added file:
Berker Peksag added the comment:
Thanks for the patch, Davin. I left a couple of comments on Rietveld.
--
nosy: +berker.peksag
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23400
___
Davin Potts added the comment:
Attached are proposed patches for default (3.5), 3.4, and 2.7 branches. (The
patch for 3.4 is identical to that for 3.5 so there are only two files in total
being attached.)
Regarding the exception being raised:
* An ImportError is now consistently being raised
Davin Potts added the comment:
To be clear, the changes to 2.7 are exclusively in the documentation. Changes
to 3.4 and default (3.5) are in both documentation and code.
--
Added file: http://bugs.python.org/file38078/issue23400_py27.patch
___
Davin Potts added the comment:
Having installed a fresh copy of Debian Hurd into a VM, I am able to reproduce
the described issue using this 2-line snippet of code:
import multiprocessing
q = multiprocessing.Queue()
It was possible to reproduce the issue both using the builds of
Davin Potts added the comment:
Apologies -- it was already pointed out that there is no sem_open
implementation on Hurd.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23400
___
Changes by Erik Bray erik.m.b...@gmail.com:
--
nosy: +erik.bray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23400
___
___
Python-bugs-list
New submission from Ole Streicher:
On Debian Hurd, there is no sem_open implementation. When I try there to create
a Queue, I get different errors, depending on the Python version:
import multiprocessing
q = multiprocessing.Queue()
gives on Python 2.7.9:
maxsize = 0
def
21 matches
Mail list logo
