Tomi Pieviläinen added the comment:
Platform: RHEL 6.3 x86_64.
0. (remove old python 3 install, though this doesn't change anything)
1. Unpack 3.3rc1 source, cd Python-3.3.0rc1/
2. ./configure; make
3. sudo make install
4. ls -ltc --full-time /usr/local/lib/python3.3/lib2to3/
This shows that
Arfrever Frehtes Taifersar Arahesis added the comment:
This issue can be easily reproduced on filesystems with nanosecond precision
(e.g. ext4).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15822
Tomi Pieviläinen added the comment:
Ah, sorry, forgot to add that info. I also am running ext4.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15822
___
Arfrever Frehtes Taifersar Arahesis added the comment:
`make install DESTDIR=/some/temporary/path` can be used to avoid affecting
installed version of Python.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15822
Changes by Berker Peksag berker.pek...@gmail.com:
--
versions: -Python 3.1, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15676
___
New submission from Mark Tolonen:
I built a C extension using SWIG for both Python 3.2 and Python 3.3. The
Python file supplying class proxies uses imp.load_module and fails with the
following traceback on 3.3.0rc1, but works on 3.2.3:
Traceback (most recent call last):
File stdin,
The Written Word added the comment:
Actually, this regression appeared after the Hash Randomization patches prior
to 2.6.8, 2.7.3, 3.1.4 and 3.2.3.
Also, it not only breaks `from os import urandom`, but also prevents
installation of many third-party packages that use setuptools or distribute,
Stefan Krah added the comment:
Dag Sverre Seljebotn rep...@bugs.python.org wrote:
It is perfectly possible for an object to export memory in a read-only
way that may still change. Another object may have a writeable view:
x = obj.readonly_view
y = obj.writable_view
Ned Deily added the comment:
Thanks for the details. Moving to ext4, I was still not seeing the problem as
Grammar.txt and the pickle file have the same nanosecond ctime but that may be
due to running in a vm environment or other factors. Manually touching
Grammar.txt, not surprisingly, does
Stefan Krah added the comment:
Dag Sverre Seljebotn rep...@bugs.python.org wrote:
OK, I can understand the desire to make memoryviews be bytes-like objects
(though to my mind, bytes is frozen in a very different way...)
We have two desires that sometimes conflict: People who want to use
Berker Peksag added the comment:
Python 2.6 is now in security-fix-only mode.
--
components: +Library (Lib)
nosy: +berker.peksag
versions: +Python 2.7 -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15701
Mike Hoy added the comment:
I added two patches one for 2.7 and one for 3.3. Please advise if this is the
correct way to handle this.
--
keywords: +patch
nosy: +mikehoy
Added file: http://bugs.python.org/file27068/typo-ordered-dict2.7.diff
___
Changes by Mike Hoy mho...@gmail.com:
Added file: http://bugs.python.org/file27069/typo-ordered-dict3.3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15825
___
New submission from Mike Hoy:
From the Docs mailing list:
Hi
I found a bug in python docs which can be accessed at links:
http://docs.python.org/library/threading.html#lock-objects
http://docs.python.org/py3k/library/threading.html#lock-objects
Bug is in second paragraph describing
Mike Hoy added the comment:
Working on a patch now unless there are objections to the OP.
--
nosy: +docs@python
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15829
___
Martin v. Löwis added the comment:
Am 31.08.12 06:14, schrieb Stefan Behnel:
To add on Dag's comments, this essentially means that any caching of
the hash value is dangerous
Stefan Krah is right here: the proper test (which is already
implemented) is whether the underlying object is
Andrew Svetlov added the comment:
The problem is: threading.Lock raises ThreadingError (which is subclass of
RuntimeError for 3.3 but not for 3.2), but threading.Condition raises
RuntimeError for the same reason.
RLock behavior is even worse: it raises ThreadingError if C accelerator is
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
___
Mike Hoy added the comment:
I think RuntimeError should be replaced by ThreadingError for _RLock and
Condition implementations as well as docs need to be updated.
Also I think this patch should be applied to 3.4 only, it is enchacement,
not bugfix.
About fixing docs for 2.7-3.3: I see nothing
Mike Hoy added the comment:
I think RuntimeError should be replaced by ThreadingError for _RLock and
Condition implementations as well as docs need to be updated.
Also I think this patch should be applied to 3.4 only, it is enchacement,
not bugfix.
About fixing docs for 2.7-3.3: I see nothing
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
stage: committed/rejected -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15819
___
___
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
Removed message: http://bugs.python.org/msg169518
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15829
___
Andrew Svetlov added the comment:
ValueError can be referenced by :exc:`ValueError`.
For ThreadError you can add section for describing this exception type like:
.. exception:: ThreadError
Raised when lock object cannot be acquired or released.
--
The Written Word added the comment:
The root of the problem preventing me from running some 3rd party setup.py
scripts correctly is the mismatch between (recently) raising an OSError in
Python/random.c, but catching only NotImplementedError in Lib/random.py.
For backwards compatibility
Antoine Pitrou added the comment:
Looks like a critical regression to me.
--
nosy: +barry, benjamin.peterson, georg.brandl, pitrou
priority: normal - release blocker
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset 69952b5599b5 by Andrew Svetlov in branch '2.7':
Issue #15825: fix typo in OrderedDict docs.
http://hg.python.org/cpython/rev/69952b5599b5
New changeset 8877d25119ef by Andrew Svetlov in branch '3.2':
Issue #15825: fix typo in OrderedDict docs.
Andrew Svetlov added the comment:
Thanks.
--
nosy: +asvetlov
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15825
___
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +brett.cannon, ncoghlan
priority: normal - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15828
___
Mike Hoy added the comment:
I discussed this in IRC and got the following information from Ezio:
Taggnostr the doc fix can go in 2.7/3.3, the code fix in 3.4
Plan is to put the definition for ThreadError in threading.rst for both 2.7 and
3.3
--
Andrew Svetlov added the comment:
Sounds good.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15829
___
___
Python-bugs-list mailing list
Mike Hoy added the comment:
3.3 patch
--
keywords: +patch
Added file: http://bugs.python.org/file27071/15829-thread-errror3.3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15829
___
Mike Hoy added the comment:
2.7 patch.
--
Added file: http://bugs.python.org/file27072/15829-thread-errror2.7.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15829
___
Nick Coghlan added the comment:
An even easier reproducer:
import imp
[93559 refs]
details = imp.find_module(_elementtree)
[93572 refs]
mod = imp.load_module('_elementtree', *details)
Traceback (most recent call last):
File stdin, line 1, in module
File
Nick Coghlan added the comment:
Patch adds test case and fix (there was simply a missing entry for
C_EXTENSION/load_dynamic in the load_module if-elif chain).
Also moves an imp module test from test_import to test_imp (it's the test I
used as a guide to check I wasn't missing anything obvious
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +georg.brandl
stage: - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15828
___
Nick Coghlan added the comment:
Tweaked patch to also fix the typo in the error message
--
Added file:
http://bugs.python.org/file27074/issue15828_handle_extension_modules.diff
___
Python tracker rep...@bugs.python.org
Changes by Nick Coghlan ncogh...@gmail.com:
Removed file:
http://bugs.python.org/file27073/issue15828_handle_extension_modules.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15828
___
Nick Coghlan added the comment:
I'm heading to bed, so whoever reviews this one, please feel free to add a NEWS
entry and check it in :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15828
R. David Murray added the comment:
Please see Issue 14502. The docs probably do need clarification, but it must
be done carefully.
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15829
Brett Cannon added the comment:
LGTM
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15828
___
___
Python-bugs-list mailing list
Unsubscribe:
Trent Nelson added the comment:
Well, that escalated quickly :-)
I think I should clarify my use case that resulted in raising this bug.
1. Create a fresh hg clone, say, ~/hg/cpython-3.2.
2. Make it readonly: `zfs set readonly=on tank/home/cpython/hg/cpython-3.2`
3. cd /tmp/cpython-3.2-build
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14502
___
___
Martin v. Löwis added the comment:
Am 31.08.12 15:19, schrieb Trent Nelson:
I think I should clarify my use case that resulted in raising this
bug.
1. Create a fresh hg clone, say, ~/hg/cpython-3.2.
2. Make it readonly
The use case is really uncontended, and long-standing. People want
to
New submission from Brett Cannon:
Sometime in the last month (probably) I change has been made in either
configure(.ac), Makefile.pre.in, or setup.py that is causing the -s option
passed to make to not also make its way into setup.py when extensions are built.
--
components: Build
Nick Coghlan added the comment:
Since I'm still up, I guess I'll check it in, then :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15828
___
Manu Cupcic added the comment:
I am testing this patch right now. Will report back.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
___
Nick Coghlan added the comment:
Over to Georg to cherry pick this one into rc2
--
assignee: - georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15828
___
Roundup Robot added the comment:
New changeset 9ba57938f54d by Nick Coghlan in branch 'default':
Issue #15828: Restore support for C extension modules in imp.load_module()
http://hg.python.org/cpython/rev/9ba57938f54d
--
nosy: +python-dev
___
Python
Richard Oudkerk added the comment:
Richard: what was your use case?
Building on the main host and a VM without having to commit and synchronize
temporary changes. (The VM has read-only access to the host's repositories).
What steps did you take that resulted in getting typeslots.inc and
Martin v. Löwis added the comment:
Am 31.08.12 16:40, schrieb Richard Oudkerk:
I suspect a bigger issue is the fact that *.pyc files cannot be
written to $(srcdir)/Lib/__pycache__. This means that to complete
the build, $(PYTHON_FOR_BUILD) should probably include the -B flag to
prevent it
Roundup Robot added the comment:
New changeset d54f047312a8 by Brett Cannon in branch 'default':
Issue #15828: Don't try to close a file if imp.find_module() doesn't
http://hg.python.org/cpython/rev/d54f047312a8
--
___
Python tracker
Richard Oudkerk added the comment:
Why is that? python will work just fine if it can't write pyc files.
When I hacked around the _sysconfigdata.py issue, running the created python
produced
Fatal Python error: Py_Initialize: Unable to get the locale encoding
Traceback (most recent call
Richard Oudkerk added the comment:
It looks like the code which writes the byte-compiled codes checks for and
ignores PermissionError (EACCES, EPERM) and FileExistsError (EEXIST).
However, for me it is EIO which is raised.
--
___
Python tracker
Martin v. Löwis added the comment:
Am 31.08.12 17:32, schrieb Richard Oudkerk:
File frozen importlib._bootstrap, line 128, in _write_atomic
OSError: [Errno 5] Input/output error:
'/mnt/hgfs/Repos/cpython-dirty/Lib/__pycache__/codecs.cpython-33.pyc.3076609376'
Aborted
I took this to be
New submission from Chris Jerdonek:
From d...@python.org:
In a number of places we find documentation with optional leading arguments
where the meta-notation (square brackets) are in the wrong place. For
example, for range, the standard doc heading says
range([start], stop [,
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
keywords: +easy
nosy: +ezio.melotti
stage: - needs patch
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15831
___
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15831
___
___
New submission from Riccardo Murri:
The `argparse` module (tested with 2.7, but other versions might be
affected) checks the `default` value of an option too early: if the
default value raises an exception, then command-line parsing stops.
Consider for example the following code:
Chris Jerdonek added the comment:
Do we know that this is easy? It might be a Sphinx issue, in which case it
might not be as trivial as fixing typos.
I ask because the reST file looks correct (for range() for example):
.. function:: range([start,] stop[, step])
--
Ezio Melotti added the comment:
I thought that was just a matter of finding the wrong commas and fixing them,
but if they are correct in the source, then the situation might be a bit more
complicated.
Does this happen only with unusual signatures like range([start], stop [,
step])?
FWIW
R. David Murray added the comment:
It is possible this could be considered a feature rather than a bug :)
Let's see what Steven thinks.
--
nosy: +bethard, r.david.murray
versions: +Python 3.2, Python 3.3, Python 3.4
___
Python tracker
Eric Snow added the comment:
Doesn't EIO cover pathologies which we don't want to silence? I could see
adding EROFS though.
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15819
Chris Jerdonek added the comment:
This is what my search for ,] gave me (though the OP's print and random.seed
do not show up in this list):
library/curses.rst
380:.. function:: newwin([nlines, ncols,] begin_y, begin_x)
659:.. method:: window.addch([y, x,] ch[, attr])
673:.. method::
Ezio Melotti added the comment:
I think it would be easier to subclass GlobTests and override norm and glob
there (assuming that doesn't create problems with some of the tests).
--
nosy: +ezio.melotti
stage: - patch review
versions: +Python 3.2, Python 3.4
Andrew Svetlov added the comment:
Yes, it looks like Sphinx problem.
About having tho signatures for single function/method.
Does Sphinx support it for *.. function::*?
Pointing to anchor for first signature with adding second one somewhere in
paragraph text doesn't look good.
--
Ezio Melotti added the comment:
I'm not sure this is really useful. Once I know that I divided by zero and I
know where the division is, I don't really care what the numerator is. Knowing
the exact type of the denominator (0, 0.0, 0j) doesn't sound too useful as well
-- unless you somehow
Andrew Svetlov added the comment:
No, methods for *curses* are also corrupted.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15831
___
___
Ezio Melotti added the comment:
Does Sphinx support it for *.. function::*?
I'm pretty sure it does for methods, so I don't see why it shouldn't work for
functions.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15831
Martin v. Löwis added the comment:
Am 31.08.12 18:18, schrieb Eric Snow:
Doesn't EIO cover pathologies which we don't want to silence? I could see
adding EROFS though.
[This should *really* be its own issue]
Sure, EIO indicates normally something pathological, such as a broken
cable to the
Senthil Kumaran added the comment:
Okay, this is funny. first info is invoking addinfourl of urllib, which would
return headers. But in urllib2, the headers are self.hdrs
I would side with the documentation that info is advertised method for
HTTPError object. In 2.7, I guess just docs could
Ezio Melotti added the comment:
This is what my search for ,] gave me
It would be fine with me to use a double signature for these.
Georg, do you have any opinion?
(The double signature might be easier to understand, but the original issue
should probably be fixed in Sphinx, even if we
Ezio Melotti added the comment:
No, methods for *curses* are also corrupted.
I meant the double signature support.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15831
___
Chris Jerdonek added the comment:
It would be fine with me to use a double signature for these.
Just an FYI that more than two signatures would be needed for cases like this:
766:.. method:: window.chgat([y, x, ] [num,] attr)
--
___
Python tracker
New submission from Richard Oudkerk:
As discussed in
http://bugs.python.org/issue15819
trying to run python built outside a read-only source directory fails for me
because OSError(EIO, ...) is raised when importlib tries to write the byte
compiled file. (I built python in a Linux VM
Ezio Melotti added the comment:
766:.. method:: window.chgat([y, x, ] [num,] attr)
What's this even supposed to mean?
See also #14783.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15831
Chris Jerdonek added the comment:
What's this even supposed to mean?
I started wondering the same thing after I posted. :)
I guess my point/question is: are there any cases where more than two
signatures would be needed to account for all of the possibilities?
--
Éric Araujo added the comment:
+1! This notation helps clearing up how int, str and other constructors work.
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14783
___
Ezio Melotti added the comment:
I think/hope that all the APIs we have in the stdlib are sane enough to have no
more than 2-3 signatures (I'm not counting optional args (at the end) here).
If that's not the case we should still be able to add as many signature as we
need (I don't know if
Richard Oudkerk added the comment:
I have opened a new issue:
http://bugs.python.org/issue15833
It is a regression because in Python 3.2 all failures to open the file for
writing were supressed.
But as I said: I'd also be fine with declaring this VM software
unsupported. If this
Changes by Steven Bethard steven.beth...@gmail.com:
--
resolution: - duplicate
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15832
___
Steven Bethard added the comment:
It's a bug, but it's already been reported in Issue 12776. There's a patch
there, but someone needs to commit it.
--
superseder: - argparse: type conversion function should be called only once
___
Python tracker
Ned Deily added the comment:
Issue15591 perhaps?
--
nosy: +ned.deily
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15830
___
___
Python-bugs-list
Gregory P. Smith added the comment:
When we added this functionality to assertEqual we were *intentionally*
conservative on when it would auto-promote to nicer equality comparison
functions. It needs to behave exactly as == would in all situations.
(1,2,3) == [1,2,3]
False
We must maintain
Ezio Melotti added the comment:
Here's a patch for the signature.
--
assignee: - ezio.melotti
keywords: +patch
stage: needs patch - commit review
Added file: http://bugs.python.org/file27075/issue14783.diff
___
Python tracker rep...@bugs.python.org
Stefan Krah added the comment:
Alexander, your test case is brilliant and could eventually go into
_testbuffer.c, but I'd prefer a simpler test case for now. :)
Here's a patch that restores the info.obj cleanup facility.
I intentionally did not add copying the format in order to keep the
diff
Alexander Belopolsky added the comment:
On Fri, Aug 31, 2012 at 2:34 PM, Stefan Krah rep...@bugs.python.org wrote:
With the ManagedBuffer, we could now write a new function that returns
a memoryview with much nicer cleanup facilities. But that doesn't help
here since we're stuck with this
Stefan Krah added the comment:
Alexander Belopolsky rep...@bugs.python.org wrote:
I am still getting up to speed with all the changes that went in since
3.2. I'll review your patch over the weekend. Meanwhile, I think the
goal should be that after PyMemoryview_FromBuffer(info) is called, it
Changes by Berker Peksag berker.pek...@gmail.com:
--
versions: -Python 2.6, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15756
___
Terry J. Reedy added the comment:
The large issue is documenting complex signatures that do not really fit in any
of the standard one-line patterns.
I was initially puzzled by Raymond describing the 3.3 line as 'confusing', but
putting on 'newbie glasses' I see now that correctly parsing
Thomas Miedema added the comment:
Added a better testcase.
--
title: Fix pickling of named tuples in 2.7.3 - Fix pickling of named tuples in
2.7.3 (BUG)
Added file: http://bugs.python.org/file27077/namedtuple_pickle_fix.patch
___
Python tracker
Changes by Thomas Miedema thomasmied...@gmail.com:
Removed file: http://bugs.python.org/file26662/namedtuple_pickle_fix.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15535
___
Nicholas Cole added the comment:
I'm reopening this bug because I've noticed that in Python3.3rc1, although
trying to print curses.ACS_HLINE and other such characters no long cause an
Exception, only blank characters are printed to the screen.
Tested with both Terminal.App and xterm running
Nicholas Cole added the comment:
import curses
def test_screen(screen):
screen.addch(5,5, curses.ACS_HLINE)
screen.addch(5,6, curses.ACS_HLINE)
screen.refresh()
curses.napms(2000)
curses.wrapper(test_screen)
--
___
Python tracker
Gregory P. Smith added the comment:
thanks! I'll take care of getting this fix in.
--
assignee: - gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15756
___
Alexander Belopolsky added the comment:
On Fri, Aug 31, 2012 at 3:12 PM, Stefan Krah rep...@bugs.python.org wrote:
Now I'm puzzled: I thought your goal was to preserve the implicit cleanup
from 3.2, i.e. PyBuffer_Release() is called when the managed buffer is
deallocated.
The issue that I
Alexander Belopolsky added the comment:
Here is what I think the test case should look like (untested):
static PyObject *
memoryview_from_buffer_cleanup(PyObject *self, PyObject *noargs)
{
PyObject *b, *view = NULL;
Py_buffer info;
Py_ssize_t shape[3] = {2, 2, 3};
Py_ssize_t
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +doko
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15830
___
___
Python-bugs-list mailing list
Antoine Pitrou added the comment:
Raising EIO in a read-only dir sounds weird.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15833
___
Chris Jerdonek added the comment:
The following commit from today is related to this issue: 815b88454e3e
Remove trailing whitespace in order to silence warnings on HP-UX.
--
nosy: +cjerdonek
___
Python tracker rep...@bugs.python.org
Changes by Berker Peksag berker.pek...@gmail.com:
--
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15775
___
___
1 - 100 of 132 matches
Mail list logo