New submission from Stefan Mihaila :
In order to implement pickling of instance methods, a means of separating
the object and the unbound method is necessary.
This is easily done for Python methods (f.__self__ and f.__func__),
but not all of builtins support __func__. Moreover, there currently
Stefan Mihaila added the comment:
Yes, the patch is at http://codereview.appspot.com/6425052/
The code there also contains some tests I've written for functools.unbind.
--
Added file: http://bugs.python.org/file26439/unbind_test.patch
___
P
Stefan Mihaila added the comment:
Doesn't the definition I've added at the end of methodobject.c suffice?
(http://codereview.appspot.com/6425052/patch/1/10) Or should the macro be
removed altogether?
--
___
Python tracker
<http://bu
Stefan Krah added the comment:
The fix would require all of these functions from memoryview.c (3.3):
last_dim_is_contiguous
cmp_structure
copy_base
copy_rec
copy_buffer
How to avoid code duplication? I could move them into abstract.c,
but conceptually they're really just low level b
Stefan Krah added the comment:
> You could move PyBuffer_ToContiguous() from abstract.c to memoryview.c.
For 3.3 that would be ideal, yes. I asked a while ago on python-dev
whether to backport the memoryview rewrite. The general mood was
against it.
So, for 2.7/3.2 I could add all th
Stefan Krah added the comment:
I think the original issue in parsetok.c is still present. The
fix that was committed was for sys_update_path().
--
___
Python tracker
<http://bugs.python.org/issue3
Stefan Krah added the comment:
There is an additional problem with PyBuffer_ToContiguous():
Suppose 'view' is multi-dimensional, C-contiguous and initialized
according to PyBUF_ND, i.e. view->shape != NULL but view->strides == NULL.
Now if PyBuffer_ToContiguous() i
Stefan Mihaila added the comment:
Richard, yes, I think that would work, I didn't think of using f.__self__'s
type.
You might want to replace
if self is not None and not isinstance(self, types.ModuleType):
with
if self is not None and not isinstance(self, types.
Stefan Mihaila added the comment:
Andrew, thanks for creating a separate issue (the refleak was very rare and I
thought I'd put it in the same place, but now I realize it was a bad idea).
Richard, actually, the isinstance(self, type) check I mentioned earlier would
have to be befor
New submission from Stefan Krah :
Using b127046831e2, I'm experiencing an import problem during the NumPy build.
I've reduced it to this scenario, which works in 3.2 but not in 3.3.
Note that in NumPy's setup.py, the equivalent of /home/stefan/tmp is
the first entry in sys.pat
Stefan Krah added the comment:
It looks like distutils/command from the stdlib is searched first
despite the fact that the first path entry is '/home/stefan/tmp'.
If distutils/command is replaced with a/b, the import works:
$ pwd
/home/stefan/tmp
$
$ ls a/b/
__init__.py x
Stefan Krah added the comment:
This is not a distutils issue. I want to know why this does not
throw an exception ...
python3.2 distutils/command/__init__.py
... while this raises ImportError:
~/usr/bin/python3.3 distutils/command/__init__.py
For the path structure please see my previous
Stefan Krah added the comment:
Argh. __init__.py was missing in the top directory. For some reason
Python 3.2 does not throw the error. Also, 3.3 does not raise in the
case of the a/b directory structure:
$ tree a
a
`-- b
|-- __init__.py
`-- xyz.py
$ ~/usr/bin/python3.3 a/b/__init__
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue15295>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
I think Serhiy has already explained that 43**10 is too large
to be represented exactly in 53-bit floating point arithmetic.
The math module wraps the floating point functions from the
C standard:
"It provides access to the mathematical functions defined b
Stefan Krah added the comment:
"Title" referring to the section header of
http://docs.python.org/dev/library/math.html ...
--
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
How about changing the title to something like:
math -- 53-bit floating point arithmetic
--
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
A quick question: Prior to this patch test_memoryview.py exercised
both mbuf_clear() and memory_clear(). Now gcov shows no coverage.
Is this expected? Is it still possible to construct tests that
exercise the code
Stefan Krah added the comment:
""Everywhere" is nowhere close to the truth. There are tons of
NOARGS functions which have the correct signature."
When I started writing C-extensions, I used the PyObject *unused
idiom. Then I saw Meador's version in so many places
Stefan Krah added the comment:
Here's a patch for 3.3, which consists mostly of tests. A couple of points:
o I removed the len > view->len check in PyBuffer_ToContiguous(), since
the function is not documented and silently accepting output buffers
that are too large seems
Stefan Krah added the comment:
Ramchandra Apte wrote:
> > [+1 for removing pow from the builtins and shunting three-argument pow to
> > the math module in Python 500.]
> Anybody who uses pow with three is doing something mathematical and has most
> likely imported math
Stefan Krah added the comment:
Sorry folks, I messed up the revisions when testing. This commit has
nothing to do with the decreased coverage.
Now I properly bisected and in r75481 mbuf_clear() and memory_clear()
are still covered, but in r75484 they are not.
r75484 addresses #1469629. I&#x
Stefan Krah added the comment:
r75484 should be b595e1ad5722.
--
___
Python tracker
<http://bugs.python.org/issue14930>
___
___
Python-bugs-list mailin
Stefan Mihaila added the comment:
I have attached a fix to this issue (and implicitly issue1062277).
This patch allows pickling self-referential sets by implementing a
set.__reduce__ which uses states as opposed to ctor parameters.
Before:
>>> s=set([1,2,3])
>>> s.__reduc
Stefan Krah added the comment:
Any objections to committing this before beta2? What about the
len > view->len change: Does that look reasonable?
--
___
Python tracker
<http://bugs.python.org/i
Changes by Stefan Mihaila :
--
nosy: +mstefanro
___
Python tracker
<http://bugs.python.org/issue1062277>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Mihaila added the comment:
Attaching patch for fixing a test and adding better testing of sets.
--
Added file: http://bugs.python.org/file26539/sets-test.patch
___
Python tracker
<http://bugs.python.org/issue9
Stefan Krah added the comment:
Thanks, Nick! I'll move the function declaration back to abstract.h.
Waiting for Georg's input. -- It seems to me that #14330 is a blocker
that will only be fixed on Monday.
--
___
Python trac
Stefan Krah added the comment:
All right, 3.3 is fixed. Re-targeting for 3.2 and 2.7.
--
priority: release blocker -> normal
versions: +Python 3.1 -Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
Christian's posts and my initial report were about memoryview.tobytes(). It's
good that you changed the title: memoryview.tobytes() is more meaningful than
the slightly obscure PyBuffer_ToContiguous().
BTW, I'm sure that PyBuffer_FromC
Stefan Krah added the comment:
Nick, are you talking about a complete backport or just about pulling
in all functions needed by PyBuffer_ToContiguous()?
--
___
Python tracker
<http://bugs.python.org/issue12
Stefan Mihaila added the comment:
Only an issue in Python2.
>>> A.B.__qualname__
'A.B'
>>> repr(A.B)
""
--
nosy: +mstefanro
versions: +Python 2.6, Python 2.7
___
Python tracke
Stefan Krah added the comment:
> Right now major parts of the buffer API are broken for non-trivial
> buffer definitions. IMHO a backport of the fix doesn't count as a new
> feature although it needs some new internal functions.
This particular bug fix for PyBuffer_ToContiguous(
Stefan Krah added the comment:
I can reproduce this exclusively with the pgupdate build:
msbuild PCbuild\pcbuild.sln /p:Configuration=PGInstrument /p:Platform=win32
msbuild PCbuild\pcbuild.sln /p:Configuration=PGUpdate /p:Platform=win32
PCbuild\Win32-pgo\python.exe
Python 3.3.0b1 (default, Jul
New submission from Stefan Krah:
_decimal does not build in PGUpdate mode. I didn't notice this because
I've always used the Release mode so far:
msbuild PCbuild\pcbuild.sln /p:Configuration=PGInstrument /p:Platform=x64
msbuild PCbuild\pcbuild.sln /p:Configuration=PGUpdate /p:Platfor
Stefan Krah added the comment:
Martin v. L??wis wrote:
> > If not, then I doubt PGO is buying us anything anyway.
>
> It was originally added because people reported measurable speedups when
> profile-guided optimization is used, for VS 2008.
For libmpdec/64-bit I've measu
Stefan Krah added the comment:
_decimal-pgo.diff sort of solves the problem. It might be a good
idea to regenerate _decimal.vcproj using the GUI. I've created it
in true Unix fashion by modifying an existing vcproj...
I'm always building using the command line. If you say that the
Changes by Stefan Krah :
--
keywords: +needs review -patch
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue15511>
___
___
Py
Stefan Krah added the comment:
Using MSVC Professional 2010 and the GUI, I'm getting the same error:
1) Select PGInstrument|x64. Clean the solution.
2) Select PGUpdate|x64. Clean the solution.
3) Select PGInstrument|x64. Build the solution.
4) Select PGUpdate|x64. Build the sol
Stefan Krah added the comment:
Ok, Microsoft dropped PGO support in VS 2010 "Professional". In
VS 2008 *Professional* it was present.
So I'll jump through the hoops of the marketing department and
install "Ultimate".
The patch is of limited value then: _decimal does b
Stefan Krah added the comment:
Well, I have Ultimate now and encounter the same problem. Also, when
I start PCbuild\x64-pgi\python.exe it exits immediately without
displaying an error.
The PC\VS9.0 PGUpdate build works fine.
--
title: VS 2010 "Professional": _decimal does no
Stefan Krah added the comment:
Building from a fresh tree enables successful launching of
PCbuild\x64-pgi\python.exe,
but _decimal is still not built. I literally ran the following commands,
so anyone can paste them into a command window and see for themselves:
# cpython is a pristine clone
Stefan Krah added the comment:
Here's a patch based on the analysis. All test cases given here
now raise TypeError.
--
keywords: +patch
Added file: http://bugs.python.org/file26623/issue8847.diff
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
Antoine Pitrou wrote:
> I think we want to add those tests to the test suite as well.
What's a good place? Shall we just add one of the tests to test_tuple?
Also, the only person to run the tests with the PGO build will probably
be Martin just be
Stefan Krah added the comment:
New patches with tests for 3.2 and 3.3. For 3.2 I determined empirically
that EnableCOMDATFolding="1" (and not "0") turns on NOICF.
If anyone can confirm that this is the case or has a pointer to
the relevant vcproj docs, I'd be thrille
Changes by Stefan Krah :
Added file: http://bugs.python.org/file26633/issue8847-3.2.diff
___
Python tracker
<http://bugs.python.org/issue8847>
___
___
Python-bugs-list m
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file26632/issue8847-3.3.diff
___
Python tracker
<http://bugs.python.org/issue8847>
___
___
Python-bugs-list m
Changes by Stefan Krah :
Added file: http://bugs.python.org/file26634/issue8847-3.3.diff
___
Python tracker
<http://bugs.python.org/issue8847>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Is it possible without too much effort to keep the old behavior
('u' -> Py_UNICODE)? Then I'd say that should go into 3.3.
The problem with the current behavior is that it's neither backwards
compatible nor PEP-3118 compliant.
If it is t
Stefan Krah added the comment:
The diff between b9558df8cc58 and default with array_revert_pep393.patch
applied is small, but I noticed that in some places you switched back to
Py_UNICODE typecode and in others not. For instance, in struct arraydescr
typecode is still char.
I'm not sur
Stefan Krah added the comment:
array_revert_pep393-2.patch looks good (checked against 7042a83f37e
and all following commits that should be kept).
--
___
Python tracker
<http://bugs.python.org/issue13
Stefan Krah added the comment:
A couple of days ago there was another effort by Ondřej Čertík to get
NumPy working with 3.3, see the thread starting here:
http://comments.gmane.org/gmane.comp.python.numeric.general/51087
I participated in that discussion and we hit the same problem with
the
Stefan Krah added the comment:
> There is a need to byte-swap only when the data is stored on disk in the
> reverse order from the native machine (i.e. NumPy is pointing to
> memory-mapped data).
In that case it should be a matter of disabling some NumPy unit tests.
It seems that
Changes by Stefan Krah :
--
nosy: +certik
___
Python tracker
<http://bugs.python.org/issue15540>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
I think math.isnan('snan') probably should not raise. Decimal('snan').is_nan()
just returns true and I am under the impression that IEEE 754 specifies the
same. I have to admit though that I just consulted Wikipedia for the latter:
&q
Stefan Krah added the comment:
Martin v. L??wis wrote:
> I don't mind that at all, either. What I dislike is "I have this issue,
> here is what I've got, and I will continue to work on it" kind of reports
> (when Dave clearly said that his patch is work-in-progr
Stefan Krah added the comment:
> OTOH, IEEE 754 *does* cover floating-point to int conversions (5.4.1, 5.8):
> those fall under 'general-computational operations', and as such should
> signal when given an sNaN.
That sounds good. Let's keep the ValueError
Stefan Krah added the comment:
> Why not add a is_nan() method to float numbers instead?
Do you mean replacing math.isnan(x) by x.is_nan() to avoid the issue
altogether? I'm not sure that's possible given that math just wraps
Stefan Krah added the comment:
Mark Dickinson wrote:
> Looks like we've got two separate issues here, that should probably be
> split into two separate bug reports. The first issue is that
> Decimal.__float__ is brain-dead when it comes to NaNs with payloads;
> I consider that
Stefan Krah added the comment:
I'm not against whitespace cleanup every now and then, but also -0
on a hook for C files. I think that (for C) the annoyance of having
a patch rejected because of trailing whitespace outweighs the
overall benefit.
--
nosy: +
Stefan Krah added the comment:
STINNER Victor wrote:
> Hum, this issue is a regression from Python 3.2.
>
> Python 3.2.3+ (3.2:243ad1a6f638+, Aug 4 2012, 01:36:41)
> [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux2
> >>> import array
> >>> a=array.ar
Stefan Krah added the comment:
Also, it was suggested that 'u' should be deprecated:
http://mail.python.org/pipermail/python-dev/2012-March/117392.html
Personally, I don't have an opinion on that; I don't use the 'u'
format code.
Nick, could you have a lo
Stefan Krah added the comment:
Of course, if two formats *are* the same, it is possible to use
memcmp(). I'll work on a patch.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Stefan Behnel:
Line 912 of threading.py, Py2.7, reads:
self.queue = deque()
"deque" hasn't been imported.
--
components: Library (Lib)
messages: 167554
nosy: scoder
priority: normal
severity: normal
status: open
title: threading.py con
Stefan Krah added the comment:
> Did you see attached patch array_unicode_format.patch? It uses struct
> format "H" or "I" depending on the size of wchar_t.
I totally overlooked that. Given that memoryview can be fixed to
compare buffers with unknown formats, I don&
Stefan Krah added the comment:
I have a patch already for the unknown format codes in memoryview.
Currently fighting (as usual) with the case explosions in the tests.
I think I can have a full patch by next weekend.
--
___
Python tracker
<h
New submission from Stefan Krah:
Continuing the discussion from #13072. I hit a snag here:
Determining in full generality whether two format strings describe
identical items is pretty complicated, see also #3132.
I'm attaching a best effort fmtcmp() function that should do the
foll
Stefan Krah added the comment:
Installing dpkg-dev indeed resolved the issue for me on Debian Wheezy,
but msg166444 said that the problem appeared in 7955d769fdf5.
So was dpkg-dev already an official dependency before 7955d769fdf5
or not?
--
nosy: +skrah
Stefan Krah added the comment:
With ma.diff from #11715 dpkg-dev is indeed not required (checked
on Wheezy).
--
___
Python tracker
<http://bugs.python.org/issue14
New submission from Stefan Behnel:
The new importlib shows a regression w.r.t. previous CPython versions. It no
longer recognises an "__init__.so" file as a package. All previous CPython
versions have always tested first for an extension file before testing for a
.py/.pyc fil
Stefan Behnel added the comment:
Additional info: working around this bug from user code is fairly involved
because some FileLoader instances are already created early at initialisation
time and the overall configuration of the FileLoaders is kept in the closure of
a path hook
Stefan Behnel added the comment:
Hi, thanks for bringing in the 'historical details'. It's not so much that
"Cython has been relying on it" - it's entirely up to users what they compile
and what not. It's more that I don't see anything being wrong
New submission from Stefan Krah:
Running *any* test of the test suite currently produces a bus error
on Debian sparc [http://people.debian.org/~aurel32/qemu/sparc/].
After the bus error, the tests seem to proceed normally though.
This is definitely new. I've been testing memoryview fo
Stefan Krah added the comment:
Setting to critical: debian-sparc 32-bit is apparently deprecated
since Lenny and still uses linuxthreads.
Tracking down the failure could end up in finding a platform bug
like in #12936.
--
priority: release blocker -> criti
Stefan Krah added the comment:
Right, byte order specifiers are always at the beginning of the string.
That is at least something. I wonder if we should tighten PEP-3118 to
demand a canonical form of format strings, such as (probably incomplete):
- Whitespace is disallowed.
- Except for &#
Stefan Krah added the comment:
I think I've identified one legit Python bug. This is from a *different*
traceback, i.e. the traceback in my first message is still unresolved.
A bus error occurs in test_capi, test_skipitem with format 'D':
Python/getargs.c:782
Py_comp
Stefan Krah added the comment:
Floris, the traceback in my first message only occurs in the
optimized regular build with -O3. Did you try that, too?
--
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
Larry Hastings wrote:
> Attached is a patch attempting to force double alignment. Stefan: please
> apply and try it. Does this help?
Yes, this works nicely.
--
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
As for the original error: in test_subprocess basically every test
fails. With the standard regrtest.py (faulthandler enabled), most
tests generate a bus error in subprocess_fork_exec():
621 cwd_obj2 = NULL;
(gdb)
624 pid = fork(); <-
Stefan Krah added the comment:
> 329 tests OK.
> 7 tests failed:
> test_cmd_line test_exceptions test_ipaddress test_os test_raise
> test_socket test_traceback
Thanks. A lot of these appear to be big-endian related, see #15597.
--
__
Stefan Krah added the comment:
> Removing 3.1, since its addition was apparently done by mistake.
I'm unable to set 2.7 and 3.2 in my browser without also setting
3.1 (using the Shift key to mark multiple fields).
--
___
Python tracke
Stefan Krah added the comment:
The buildbot is running inside kvm on a heavily loaded machine. Perhaps
some timeout is too low.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
> If disabling faulthandler avoids new issues, you can add 'if
> [not] sys.thread_info.version.startswith("linuxthreads")'
That suppresses some bus errors. However, they still occur without
being raised (some print statements and a WI
Stefan Krah added the comment:
Antoine Pitrou wrote:
> Could you try to run the tests manually after having upped said timeouts?
> (look for "sleep" in the test file)
No luck there: The tests pass unmodified (100 times wi
Stefan Krah added the comment:
> I can easily provide a specification that makes the current implementation
> "correct"
Yes, the current specification is: memoryview only attempts to
compare arrays with known (single character native) formats and
returns "not equal"
Stefan Krah added the comment:
PEP-3118 specifies strongly typed multi-dimensional arrays. The existing
code in the 3.2 memoryview as well as numerous comments by Travis Oliphant
make it clear that these capabilities were intended from the start for
memoryview as well.
Perhaps the name
Stefan Krah added the comment:
> 1. what does it mean that the formats of v and w are equal?
I'm using array and Py_buffer interchangeably since a Py_buffer struct
actually describes a multi-dimensional array. v and w are Py_buffer
structs.
So v.format must equal w.format, where for
Changes by Stefan Krah :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue15573>
___
___
Python-bugs-list mailing list
Un
Stefan Krah added the comment:
The ideal specification is:
1) Arrays v and w are equal iff format and shape are equal and for all valid
indices allowed by shape
memcmp((char *)PyBuffer_GetPointer(v, indices),
(char *)PyBuffer_GetPointer(w, indices),
itemsize
Stefan Krah added the comment:
Martin v. Loewis wrote:
> Sure: someone would have to make a proposal what exactly that is.
> IMO, the 3.2 definition *was* simple, but apparently it was considered
> too simple.
It was simply broken in multiple ways. Example:
>>> from nu
Stefan Behnel added the comment:
I understand that this is not trivial to test as part of the regression test
suite. However, when I try it now I get this:
Traceback (most recent call last):
File "", line 1, in
File "__init__.py", line 8, in init my_test_package
(my_t
Stefan Krah added the comment:
You have rejected the PEP-3118 'u' and 'w' specifiers here:
http://mail.python.org/pipermail/python-dev/2012-March/117390.html
Otherwise, memoryview follows the existing struct module syntax:
http://docs.python.org/dev/library/struct.html#fo
Changes by Stefan Krah :
--
title: memoryview.to_list() incorrect for 'c' format -> struct module 'c'
specifier does not follow PEP-3118
___
Python tracker
<http://
Stefan Krah added the comment:
Martin v. L??wis wrote:
> It's unfortunate that PEP 3118 deviates from the struct module, however,
> memoryview is based onthe buffer interface,and its formatcodes ought to
> conform to the PEP, not to the struct module (IMO).
The struct module
Stefan Krah added the comment:
Martin v. L??wis wrote:
> That the struct module hasn't been updated to support the PEP 3118 is
> already reported as issue 3132, please don't confuse the issues.
> This issue is about memoryview.
No, it isn't. It was always planned
Changes by Stefan Krah :
--
dependencies: +implement PEP 3118 struct changes
title: memoryview.to_list() incorrect for 'c' format -> struct module 'c'
specifier does not follow PEP-3118
___
Python tracker
<http://
Stefan Behnel added the comment:
Hmm, yes, sounds more like a separate issue than something to add to this
ticket. It worked before (starting with Py2.5, which was the first Python
version to support relative imports) and only stopped working in 3.3 now.
The .srctree test file basically just
New submission from Stefan Behnel:
Since CPython 2.5, relative imports could be used from __init__.so package
modules. This stopped working in CPython 3.3.
This is a follow-up ticket to issue15576.
This feature is exercised by Cython's initial_file_path test, which now gives
this r
Stefan Behnel added the comment:
I've created issue15623, so that we can keep this one as fixed.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
So we have two competing proposals:
1) Py_buffers are strongly typed arrays in the ML sense (e.g. array of float,
array of int).
This is probably what I'd prefer on the C level, imagine a function like
function like PyBuffer_Compare(v, w).
Back
2501 - 2600 of 4951 matches
Mail list logo
