Stefan Krah added the comment:
I've already committed a decorator in 5c7f92bfe785, but it isn't
quite robust. I think the one in issue17041-decorator.diff should
do the trick.
Also, we then can use support.HAVE_DOCSTRINGS for some doctests.
--
Added file: http://bugs.
Stefan Krah added the comment:
Serhiy Storchaka wrote:
> > It seems like it would make more sense to combine both checks into one
> > decorator.
>
> These are different cases. @unittest.skipIf(sys.flags.optimize >= 2) is about
> docstrings in Python
Stefan Krah added the comment:
Please don't change this: It's a common pattern in C to undo memory
allocations in the opposite order.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.o
New submission from Stefan Krah:
Found this in test_codecs running under Valgrind (Python 3.3):
test_bug1251300 (test.test_codecs.UnicodeInternalTest) ... ==11511== Invalid
read of size 1
==11511==at 0x44AF37: _PyUnicode_DecodeUnicodeInternal
(unicodeobject.c:6133)
==11511==by
Stefan Krah added the comment:
Same in test_codeccallbacks:
test_badhandlerresults (test.test_codeccallbacks.CodecCallbackTest) ...
==11604== Invalid read of size 1
==11604==at 0x44AF37: _PyUnicode_DecodeUnicodeInternal
(unicodeobject.c:6133)
==11604==by 0x4DEB5C
Stefan Krah added the comment:
The patches are really small, so +1 for committing this before the
rc1 for 2.7.4 is released.
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
I left some comments but have no indication that they got mailed.
--
___
Python tracker
<http://bugs.python.org/issue17041>
___
___
Stefan Krah added the comment:
Buildbots etc. look all good. Thanks for fixing this.
--
___
Python tracker
<http://bugs.python.org/issue10156>
___
___
Python-bug
Changes by Stefan Krah :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10156>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Stefan Krah :
--
resolution: -> fixed
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue10156>
___
___
Stefan Krah added the comment:
Moderately opposed, yes. PyMem_Malloc()/PyMem_Free() and PyMem_New()/PyMem_Del()
are already explained in depth above.
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Behnel added the comment:
This is a duplicate of issue 9518 (or the other way round) and should be closed
as fixed in 3.2.
--
components: +Extension Modules
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue7
Stefan Krah added the comment:
Right, keeping the cases separate is indeed clearer.
Serhiy, in case you are waiting for my "stick to minimal changes" comment to be
resolved: People apparently *do* use --without-doc-strings, so the additional
code in test_pydoc.py is r
Stefan Krah added the comment:
doctests_without_docstrings.patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue17041>
___
___
Python-bug
Stefan Krah added the comment:
Serhiy, if you have time, I think it would be nice to get the remaining
fix into the upcoming release candidates.
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
This is mainly about Py_CLEAR(), right? The initializations to NULL should
be guaranteed by the C standard.
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
Yes, it's guaranteed:
6.7.8 Initialization
10) If an object that has automatic storage duration is not initialized
explicitly, its value is indeterminate. If an object that has static
storage duration is not initialized expli
New submission from Stefan Ring:
After a fork, the list of thread states contains all the threads from before.
It is especially unfortunate that, at least for me, it usually happens that
threads created in the forked process reuse the same thread ids, and
sys._current_frames will then return
Changes by Stefan Ring :
Added file: http://bugs.python.org/file28925/test-fork-frames.py
___
Python tracker
<http://bugs.python.org/issue17094>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Thanks for the report. I cannot reproduce it with the latest 3.2 version.
Perhaps the version shipped with Ubuntu 11.04 has this problem.
--
nosy: +doko, skrah
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
IOW, my advice is to get Python 3.3 from hg.python.org and see if
you can reproduce the issue.
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
Thanks for testing. The problem with the Ubuntu Python
"Python 3.2 (r32:88445, Oct 20 2012, 14:09:50)"
is that it seems to be a patched 3.2.0, while we're already at 3.2.3.
So it might be worth reporting this issue to Ubuntu.
--
resolu
Stefan Krah added the comment:
Theoretically int may be 16 bits (C99):
5.2.4.2.1 Sizes of integer types
-- maximum value for an object of type int
INT_MAX +32767 // 2**15 − 1
I agree that Python wouldn't compile on such a platform anyway.
--
nosy: +
Stefan Krah added the comment:
Hmm, Mark was faster. ;)
--
___
Python tracker
<http://bugs.python.org/issue5308>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Changing array.array would be a new feature, so it cannot go into 2.7.
The documentation could be improved, see also #14198.
--
assignee: -> docs@python
components: +Documentation -None
nosy: +docs@python, sk
Stefan Krah added the comment:
The FreeBSD 6.4 bot is failing, too. Note that the other functions
in test_returnfuncptrs.py do this in order to get strchr():
dll = CDLL(_ctypes_test.__file__)
get_strchr = dll.get_strchr
get_strchr.restype = CFUNCTYPE(c_char_p, c_char_p, c_char
New submission from Stefan Behnel:
I can't see a reason why Signature.from_function() should explicitly check the
type of the object being passed in. As long as the object has all required
attributes, it should be accepted.
This is specifically an issue with Cython compiled functions,
Stefan Behnel added the comment:
This patch removes the type check from Signature.from_function() and cleans up
the type tests in signature() to use whatever the inspect module defines as
isfunction() and isbuiltin(), so that it becomes properly monkey-patchable.
It also adds a test that
Stefan Behnel added the comment:
The method doesn't seem to be documented, and I'm not sure if the docstring
really benefits from this lengthy addition. Anyway, here's a patch that
includes the docstring update.
The exception could be kept the same if we catch an Att
Stefan Behnel added the comment:
Fine with me. Updated patch attached.
--
Added file: http://bugs.python.org/file29007/inspect_sig_2.patch
___
Python tracker
<http://bugs.python.org/issue17
Changes by Stefan Krah :
--
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> uses of locale-dependent ctype functions
___
Python tracker
<http://bugs.pytho
Stefan Krah added the comment:
I'm not sure if I'll use pyctype.h in libmpdec: It's still going to be an
external project that should be completely identical to the version in the
Python tree.
libmpdec/io.c is specified to be ASCII only (while handling the Turkish 'I'
Stefan Behnel added the comment:
Any more comments? Any objections to applying the last patch? Anyone ready to
do it?
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
Not technically the topic of this issue, but should we just lock
down _Py_Uid_Converter() to ints?
This is still accepted:
os.setuid(Decimal("1000.2"))
--
nosy: +skrah
___
Python tracker
<http://bu
Stefan Behnel added the comment:
1) that's a regex test, so it just looks for the text. I only extended it to
include the object it's supposed to test for. It's not actually related to my
changes, but I considered it the right thing to do. I used "42.*is not" in
order
Stefan Krah added the comment:
Serhiy Storchaka wrote:
> > Not technically the topic of this issue, but should we just lock
> > down _Py_Uid_Converter() to ints?
>
> I just copied this code from PyArg_ParseTuple*() for 'l' format.
> > os.setuid(Decimal(&qu
Stefan Behnel added the comment:
ping - I would like to see this fixed for alpha3, which is due in two weeks.
--
___
Python tracker
<http://bugs.python.org/issue18
Stefan Behnel added the comment:
The way the XMLPullParser is implemented in lxml.etree now is that it simply
inherits from XMLParser. This would also make sense for ElementTree, even
before supporting arbitrary targets. The patch in ticket #18990 makes this
simple to do.
For reference, here
Stefan Behnel added the comment:
The way the XMLPullParser is implemented in lxml.etree now is that it simply
inherits from XMLParser. This would also make sense for ElementTree, even
before supporting arbitrary targets. The patch in ticket #18990 makes this
simple to do.
For reference, here
Stefan Behnel added the comment:
> Also, +1 for allowing start-ns and end-ns event callbacks on parser targets,
> although that's a different feature entirely.
Actually, I take that back. I can't see a use case for this feature, and it
doesn't really fit with the notion o
Stefan Behnel added the comment:
I created a separate ticket #19010 for the inheritance issue.
--
___
Python tracker
<http://bugs.python.org/issue18902>
___
___
New submission from Stefan Behnel:
As mentioned in tickets #18902 and #17741, the XMLPullParser in the external
lxml.etree package inherits from the existing XMLParser class. This makes the
interface simpler, both simpler to explain and to implement.
The implementation in ElementTree should
Stefan Behnel added the comment:
I've updated the lxml documentation to reflect the new implementation. It also
has a couple of examples that show how the API works now.
https://github.com/lxml/lxml/blob/74ab4b10176750e7797eb0eff3c7c91901ab6adb/doc/parsing.txt
Stefan Behnel added the comment:
I don't think I have my head deep enough in the encodings implementation to say
that this is the correct/best way to do it, but the patch looks mostly
reasonable to me and would be a helpful addition.
I have two comments on the pyexpat_encoding_co
Stefan Krah added the comment:
I agree that this cast should work. Perhaps disallowing zero strides
is enough -- I have to look at this more closely though.
--
___
Python tracker
<http://bugs.python.org/issue19
Stefan Behnel added the comment:
Inviting some more people to get this patch reviewed in a timely fashion. Given
that it's a cleanup of a newly introduced API, it must go in before the first
beta release of 3.4.
The even wider cleanup would be to make XMLPullParser inherit from XMLParser
Stefan Behnel added the comment:
I'm not entirely happy about the docs anyway. Most people just want to loop
over iterparse() and be done (use case being to save memory). The new parser
class is a rather special and more complex thing that we shouldn't let innocent
users run into t
Stefan Behnel added the comment:
Ah, right - I forgot that it currently only implements a part of the parser API
in ElementTree. Adding "Returns the toplevel document element." behind the
current sentence would do, I guess. That will need updating once the
XMLPullParser implements s
Stefan Behnel added the comment:
> Just as an example: consider that in a lot of use cases the programmer will
> want to discard parts of the tree that's parsed iteratively (similarly to the
> main use case of iterparse()), because the XML itself is too huge. It's a
> co
Stefan Behnel added the comment:
Eli, seeing our discussion so far, ISTM that the parser-target interface is at
the very heart of our disagreement.
For me, it's a good design that provides a clean separation of concerns between
the parser that generates events, and the target (usually
Stefan Behnel added the comment:
> That means the patch could be simplified to just removing the root
> attribute without changing the result of calling close().
Absolutely.
Returning the parse result from close() would still make it both more
consistent and easier to use (also from
Stefan Behnel added the comment:
> Unfortunately I don't have time to review refactoring patches now. In light
> of a larger refactoring planned in this part of the module in the future, I
> don't think it's very important to tweak things right now.
You misunderst
Stefan Krah added the comment:
The regular build (with threads) on that machine has the same problem.
Closing the issue is fine, but there does not seem to be an easy way
to upgrade Fedora from 16 to 19. Perhaps we can skip the test so that
the buildbot continues to be useful
Stefan Behnel added the comment:
> I still consider this refactoring gratuitious at this point. The API is
> well defined by the documentation. All the rest is implementation details.
Famous last words.
--
___
Python tracker
<http://bugs.p
Stefan Behnel added the comment:
Here's the obvious minimal patch that removes the non-public 'root' attribute.
Please apply it for Py3.4 and then set the version tag of this ticket to Py3.5
(instead of closing it, because it's not resolved yet).
As I said, the expected t
New submission from Stefan Behnel:
The perf.py script opens the file for CSV output in binary mode, which no
longer works in Py3:
Index: perf.py
===
--- perf.py (Revision 80409)
+++ perf.py (Arbeitskopie)
@@ -2443,7
Changes by Stefan Behnel :
--
nosy: +brett.cannon, pitrou
___
Python tracker
<http://bugs.python.org/issue19107>
___
___
Python-bugs-list mailing list
Unsub
New submission from Stefan Behnel:
In changeset 88b6ef9aa9e9, a new function ported_lib() was added that crashes
on error reporting in Py3 because it tries to do this:
raise RuntimeError("Benchmark died: " + err)
"err" is a bytes object that comes straight from the s
Stefan Behnel added the comment:
Eli didn't explicitly comment on the patch so far, but let me quote some of his
earlier comments:
> if the reader discards parts of the tree (by deleting subtrees), then
> returning the root from close() becomes even more meaningless, because it
Stefan Krah added the comment:
Nick Coghlan wrote:
> My F19 system (which works) shows gdb-7.6-34, while the new debugging output
> Antoine added shows 7.3.50.20110722-16.fc16 on F16
>
> Maybe the new gdb version check needs to be looking for 7.4+ rather than 7.3+?
Yes, pro
Stefan Behnel added the comment:
Thanks, Nick. Your changes look good to me.
--
___
Python tracker
<http://bugs.python.org/issue18990>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Yes, len() should return the number of items. +1 for making reversed()
work.
NumPy does this:
>>> x = numpy.array([1,2,3,4,5,6,7,8])
>>> list(reversed(x))
[8, 7, 6, 5, 4, 3, 2, 1]
>>>
>>> x = numpy.array([[1,2,3], [4,5,6]])
&
Stefan Krah added the comment:
Hmm, I meant: Number of items in the first dimension, thus 4 in
Claudiu's example.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Behnel added the comment:
Any comment and/or reason?
--
___
Python tracker
<http://bugs.python.org/issue19010>
___
___
Python-bugs-list mailing list
Unsub
Stefan Behnel added the comment:
Closing #18990 defines the API of the new XMLPullParser that 3.4 will ship
with, so this ticket becomes an enhancement for future versions.
--
type: behavior -> enhancement
versions: -Python 3.4
___
Python trac
Stefan Behnel added the comment:
Well, it worked before, so the current state is clearly a regression.
--
___
Python tracker
<http://bugs.python.org/issue19
Stefan Behnel added the comment:
Copying a relevant comment by Eli from
http://bugs.python.org/issue18990#msg198145 and replying inline.
"""
The way the APIs are currently defined, XMLParser and XMLPullParser are
different animals. XMLParser can be considered to only have one
Stefan Behnel added the comment:
Given that the inheritance chain has no real user impact, I can live with this
difference.
--
___
Python tracker
<http://bugs.python.org/issue19
Stefan Behnel added the comment:
Patch LGTM and seems to work well, according to your numbers.
Only minor nitpick would be that the method references could be decref-ed
earlier, but that would complicate the code a bit.
--
___
Python tracker
<h
Stefan Behnel added the comment:
Antoine, I really don't like this attitude of adding code and then saying
"well, it's there, I won't change it" when others complain about breakage.
Please undo your change that broke the ability of using (non-trivial) wrapper
script
Stefan Behnel added the comment:
Can you update the benchmark numbers to show what the difference is compared to
pure Python (and to the fastpath) now?
One more thing: the fastpath depends on .__getitem__() and friends, whereas the
fallback path depends on .get(). What if someone overrides
Stefan Behnel added the comment:
> I'm leaving you with this, if you're wanting to do anything about it
Sorry, but weren't you just asking *me* to be constructive?
I'm aware that getting this change right isn't trivial. But that doesn't mean
we should happ
Stefan Krah added the comment:
> Stefan, what do you think about Claudiu's patch? Should a test be added to
> test_buffer as well?
I think the patch is good. We can add more tests when (if?) multi-dimensional
support is added to memoryview.
In that case we should probably do the sa
Stefan Krah added the comment:
Well, I got tired of the OS gdb with an almost transcendental version
number and installed gdb from gnu.org.
The problem seems to have disappeared.
--
___
Python tracker
<http://bugs.python.org/issue19
New submission from Stefan Krah:
On the Fedora 16 buildbot:
==
ERROR: test_qualname_source (test.test_inspect.TestMain)
--
Traceback (most recent call last
Stefan Behnel added the comment:
What about this: by default, we assume all runtimes to have the same major
version as the Python runtime that executes the benchmark runner. If that's not
the case, users must override it explicitly with a command line option, say,
"--pyversions
Stefan Krah added the comment:
Ok, I think the main reason for disallowing zeros in view->shape here
was that casts are undefined if also the "shape" argument is given:
x = memoryview(b'')
x.cast('d', shape=[1])
Now, this case *is* already caught at a late
Stefan Behnel added the comment:
I'm having trouble understanding your last comment. Are you saing that you want
the exact value to be a two digits version and therefore use separate arguments
for both Pythons (e.g. "--basever 2.7 --cmpver 3.3"), or that you want it to
a
Stefan Behnel added the comment:
Just as a quick update here: Cython has since then switched to only using
PyObject_ClearWeakRefs() and otherwise leaves the handling of the weakref slot
to CPython.
--
___
Python tracker
<http://bugs.python.
New submission from Stefan Krah:
As discussed on python-dev, importing _decimal at the bottom of
decimal.py is about 9x slower than importing _decimal directly.
--
assignee: skrah
components: Extension Modules
messages: 199553
nosy: skrah
priority: normal
severity: normal
stage: needs
Changes by Stefan Krah :
--
keywords: +patch
Added file: http://bugs.python.org/file32060/issue19232.diff
___
Python tracker
<http://bugs.python.org/issue19
Stefan Krah added the comment:
Right, let's start collecting objections. :)
Mark, Raymond: Would you support the change (__name__ hack and all)?
Maciej: Is this approach a problem for PyPy?
--
nosy: +fijall, mark.dickinson, rhettinger
___
P
Changes by Stefan Krah :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue19232>
___
___
Python-bugs-list mailing list
Un
Stefan Krah added the comment:
Using the microbenchmark I get (standard version):
./python -m timeit "import sys; modname='operator'" "__import__(modname); del
sys.modules[modname]"
1000 loops, best of 3: 460 usec per loop
Victor's version:
./python -m ti
Stefan Krah added the comment:
I guess if some of the pickling stuff get's rewritten, we can drop
__name__.
The other thing is that traditionally the types were "decimal.Decimal"
etc., so I'm not sure if it is good idea to have "_decimal.Decimal" and
"_py
Stefan Krah added the comment:
_decimal already lies about its name (for pickling).
--
___
Python tracker
<http://bugs.python.org/issue19232>
___
___
Python-bug
Stefan Behnel added the comment:
Here's a patch that replaces the current simplistic Python executable command
config with a dedicated PythonRuntime config class. That makes it easy to
properly pass around the program specific configuration. Part of that is the
Python executable path
Stefan Krah added the comment:
I can't apply the patch that was created with diff --git, so here is
another one that is less readable but applies.
--
Added file: http://bugs.python.org/file32066/issue19232-2.patch
___
Python tracker
Changes by Stefan Behnel :
--
components: +Benchmarks
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue19236>
___
___
Python-bugs-list mailin
Stefan Behnel added the comment:
+1. Does it give reasonably predictable timings?
--
___
Python tracker
<http://bugs.python.org/issue19236>
___
___
Python-bug
Stefan Behnel added the comment:
Another thing: you are only using one thread for both the client and the
server, and the app writes the entire content in one go (during one call to
get()). Wouldn't it be more interesting to make the app's get() method
asynchronous as well, so that
Stefan Krah added the comment:
Antoine Pitrou wrote:
> You can apply it using "hg import --no-commit", I think.
mercurial 2.1 throws an exception even though the patch was created with
that version. Now I upgraded to 2.7.2 and it works.
Rietveld also seems to choke on the fi
Stefan Krah added the comment:
To be fair, for the startup time I can't really detect any difference between
importing _operator directly and the current setup.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
About IDLE I can't say anything, but I'm not entirely sure if the
PEP-399 import method is easier to understand for users, see e.g.:
http://stackoverflow.com/questions/13194384/instantiate-decimal-class
I get the impression that the posters at first di
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue19254>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
This commit conflicts with the patch for issue #19108 and breaks benchmarking
in Py3 (at least for me).
Traceback (most recent call last):
File "perf.py", line 2538, in
main(sys.argv[1:])
File "perf.py", line 2481, in main
Stefan Krah added the comment:
trap() is a bit ambiguous, since in floating point operations it
means that something is actually raised and not suppressed. So one
could write:
from decimal import *
c = getcontext()
c.traps[Inexact] = True
>>> Decimal(9) / 11 # raises now!
with tra
Stefan Krah added the comment:
Zero Piraeus wrote:
> 'Ignore' and 'suppress' are not synonyms:
I wrote "synonyms here", meaning that in *this context* they are practically
synonyms. "suppress" describes the mechanics more pr
Stefan Krah added the comment:
Unfortunately the tests pass when I run them manually. On my FreeBSD
bot thsi may be relevant:
o LC_* is "C".
o The filesystem encoding is ascii.
--
nosy: +skrah
___
Python tracker
<http://bu
Stefan Krah added the comment:
I've looked at this, and the question is: Do we really need a capsule
API? All relevant symbols in _decimal start with Py* and shouldn't
need to be static.
--
___
Python tracker
<http://bugs.python.o
3201 - 3300 of 4952 matches
Mail list logo
