Stefan Behnel added the comment:
Sorry, here's another doc fix.
--
Added file: http://bugs.python.org/file39151/generator_abc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
New submission from Stefan Behnel:
Currently, CPython tends to assume that generators are always implemented by a
Python function that uses the yield keyword. However, it is absolutely
possible to implement generators as a protocol by adding send(), throw() and
close() methods to an iterator
Changes by Stefan Behnel sco...@users.sourceforge.net:
Removed file: http://bugs.python.org/file39150/generator_abc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Changes by Stefan Behnel sco...@users.sourceforge.net:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23996
___
___
Python-bugs
Stefan Behnel added the comment:
And in fact, fixing it in ceval.c would not be enough, since gen_throw() also
calls the function. So this is really the right place to fix it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Stefan Behnel added the comment:
Here's a better patch that avoids exception normalisation in all normal cases.
--
Added file: http://bugs.python.org/file39116/fix_stopiteration_crash.patch
___
Python tracker rep...@bugs.python.org
http
New submission from Stefan Behnel:
asyncio/coroutines.py contains this code:
_COROUTINE_TYPES = (types.GeneratorType, CoroWrapper)
def iscoroutine(obj):
Return True if obj is a coroutine object.
return isinstance(obj, _COROUTINE_TYPES)
In other places, it uses inspect.isgenerator
Stefan Behnel added the comment:
And another patch update that should avoid any potential performance
regressions due to the additional type check.
--
Added file: http://bugs.python.org/file39119/fix_stopiteration_crash.patch
___
Python tracker rep
New submission from Stefan Behnel:
The yield-from implementation calls _PyGen_FetchStopIterationValue() to get the
exception value. If the StopIteration exception is not normalised, e.g. because
it was set by PyErr_SetObject() in a C extension, then
_PyGen_FetchStopIterationValue() will cast
Stefan Behnel added the comment:
As noted below the table, the exact size is platform specific, so the current
documentation is correct in stating a minimum size in bytes of 2 for int.
https://en.wikipedia.org/wiki/C_data_types
IMHO, close as not a bug as it works as documented
Sepideh Ghanavati schrieb am 06.04.2015 um 04:26:
I know basic of python and I have an xml file created from csv which has
three attributes category, definition and definition description.
I want to parse through xml file and identify actors, constraints,
principal from the text. However, I am
Dave Hein schrieb am 05.04.2015 um 22:38:
I would like to distribute a python package with different code for
Python 2.* than for Python 3.*. (Mostly this is because of different
unicode string handling).
There is nothing in to setuptools or PyPi that directly supports
this scenario.
But
Stefan Behnel added the comment:
duplicate of issue 14465
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23847
___
___
Python
Stefan Behnel added the comment:
do not add a C-API
what speaks against it?
--
nosy: +scoder
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16991
Stefan Behnel added the comment:
Meaning, something like this should work:
x = (nom * 10**(prec+1)) // den
if x % 10 5:
x = x // 10
else:
x = x // 10 + 1
print('%s.%s' % (x[:-prec], x[-prec:]))
--
___
Python tracker
Stefan Behnel added the comment:
Or, speaking of division with remainder:
n, r = divmod(nom * 10**prec, den)
if r * 5 = den:
n += 1
x = str(n)
print('%s.%s' % (x[:-prec], x[-prec:]))
... minus the usual off-by-one that the tests would quickly find
Stefan Behnel added the comment:
But these parameters could also be partly delegated to normal string (not
number) formatting, right?
One of the advantages of not depending on Decimal is, well, to not depend on
Decimal, which is a rather uncommon dependency when using Fractions
Stefan Behnel added the comment:
Absolutely. Fractions are all about exact calculations, much more so than
Decimals. So the formatting output should be as accurate as requested or
possible (well, excluding infinity).
--
nosy: +scoder
___
Python
Changes by Stefan Behnel sco...@users.sourceforge.net:
--
nosy: +scoder
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23642
___
___
Python-bugs
Stefan Behnel added the comment:
The problem is, even if the chance is excessively small, it's not zero.
Meaning, someone's data set somewhere will break somehow. And with hash
randomisation, it'll mean that the problem spotted in some life system will be
entirely unreproducible without
Ian Kelly schrieb am 06.03.2015 um 18:13:
On Fri, Mar 6, 2015 at 1:24 AM, Abhiram R wrote:
A list of 100 elements has approximately 9.33 x 10**157 permutations.
If you could somehow generate one permutation every yoctosecond,
exhausting them would still take more than a hundred orders of
Changes by Stefan Behnel sco...@users.sourceforge.net:
--
nosy: +scoder
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23507
___
___
Python-bugs
Dave Farrance schrieb am 23.02.2015 um 15:13:
Dave Cook wrote:
On 2015-02-22, Dave Farrance wrote:
It's still quicker to do a re-write in the more cumbersome C
You should try Cython.
I did try Cython when I was trying to figure out what to do about the slow
speed. My initial attempt
Stefan Behnel added the comment:
Serhiy, I suggest you look at the code that Cython generates for its functions.
It has been extensively profiled and optimised (years ago), so generating the
same code for the argument clinic should yield the same performance.
And while I don't have exact
Sayth Renshaw schrieb am 08.02.2015 um 12:22:
How can I actually access the values of an element with lxml objectify?
for example if I had this element in my xml file.
Track VenueName=Flemington VenueDesc=Flemington VenueAbbr=FLEM
VenueCode=151 TrackName=Main TrackCode=149
I can see
Stefan Behnel added the comment:
Closing as not worth doing.
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18813
New submission from Stefan Behnel:
distutils uses this code to validate the input in Command.__init__():
# late import because of mutual dependence between these classes
from distutils.dist import Distribution
if not isinstance(dist, Distribution):
raise
Stefan Behnel added the comment:
Yes, pretty much the same problem.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23114
___
___
Python-bugs
Stefan Behnel added the comment:
The same applies to the error dist must be a Distribution instance in cmd.py.
See issue 23114.
--
nosy: +scoder
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23102
Hi,
Abubakar Roko schrieb am 17.12.2014 um 07:30:
Please I am new in using python to write program. I am trying to parse an XML
document using sax parse and store the parsed result in a tree like
definedbelow. XNode class define an xml element which has an ID , a tag, a
text value,
Albert-Jan Roskam schrieb am 06.12.2014 um 21:28:
On Fri, Dec 5, 2014 8:54 PM CET Mark Lawrence wrote:
For those who haven't heard thought this might be of interest
https://github.com/fijal/jitpy
Interesting, but it is not clear to me when you would use jitpy instead
of pypy.
I think this
Stefan Behnel added the comment:
Regarding the patch below, isn't most of this redundant? ISTM that simply
calling PyErr_SetString(...) should do all of this, including the exception
chaining.
diff -r 23ab1197df0b Objects/genobject.c
--- a/Objects/genobject.c Wed Nov 19 13:21:40 2014
Stefan Behnel added the comment:
Ah, right - chaining only happens automatically when the exception has already
been caught and moved to sys.exc_info.
There's a _PyErr_ChainExceptions(), though, which does it for you. You should
be able to say
PyErr_Fetch(x,y,z)
PyErr_SetString
Stefan Behnel added the comment:
Public underscore C functions are there for exactly the purpose of not
duplicating functionality across *internal* core runtime code, without making
them an official part of the C-API for *external* code. (I understand that it's
a POC patch, though, so whoever
Stefan Behnel added the comment:
FYI, here's the set of tests that I've written for my implementation in Cython:
https://github.com/cython/cython/blob/b4383a540a790a5553f19438b3fc22b11858d665/tests/run/generators_pep479.pyx
--
___
Python tracker rep
Chris Angelico schrieb am 23.11.2014 um 11:35:
On Sun, Nov 23, 2014 at 9:28 PM, Patrick Stinson wrote:
Is there a better and more secure way to do the python-within-python in
order allow users to automate your app?
More secure? Basically no. You could push the inner script into a
separate
Tim schrieb am 20.11.2014 um 18:31:
On Thursday, November 20, 2014 12:04:09 PM UTC-5, Denis McMahon wrote:
On Wednesday, November 19, 2014 2:08:27 PM UTC-7, Denis McMahon wrote:
So what I'm looking for is a method to create an html5 document using
dom manipulation, ie:
doc = new
Chris Angelico schrieb am 20.11.2014 um 06:06:
On Thu, Nov 20, 2014 at 3:58 PM, Steven D'Aprano wrote:
And the award for the most gratuitous comments before an import goes to
one of my (former) workmates, who wrote this piece of code:
# Used for base64-decoding.
import base64
# Used for
Ian Kelly schrieb am 20.11.2014 um 20:44:
On Thu, Nov 20, 2014 at 12:02 PM, Stefan Behnel wrote:
There's also the E-factory for creating (sub-)trees and a nicely objectish
way:
http://lxml.de/lxmlhtml.html#creating-html-with-the-e-factory
That looks ugly with all those caps and also hard
Stefan Behnel added the comment:
Here's another idea. There could be two implementations of slice, one that
uses Python object indices (as currently) and one that has Py_ssize_t indices
(and properties for the start/stop/step attributes). Similar to what Unicode
strings do, the slice type
Stefan Behnel added the comment:
Thanks for the review, Serhiy. There isn't really a reason not to 'normalise'
the Python step object to None when 1 is passed from C code, so I updated the
patch to do that.
Regarding on-demand creation of the Python values, the problem is that C code
New submission from Stefan Behnel:
The median tends to give a better idea about benchmark results than an average
as it inherently ignores outliers.
--
components: Benchmarks
files: show_median.patch
keywords: patch
messages: 231239
nosy: pitrou, scoder
priority: normal
severity
Stefan Behnel added the comment:
Fair enough, patch updated.
--
Added file: http://bugs.python.org/file37207/show_median.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22881
Stefan Behnel added the comment:
I reran the benchmarks with the fast path in _PyEval_SliceIndex() and the
results are not conclusive. There is no clear indication that it improves the
performance.
The problem is that most slices have no step, many slices are open ended on at
least one side
Stefan Behnel added the comment:
why you pass through fast path only if -1= Py_SIZE(v) =1?
It's usually enough, it's the fastest fast path, and it doesn't even need
error handling.
Any slicing where the slice calculation time matters is going to be of
fairly limited size, often involving
Changes by Stefan Behnel sco...@users.sourceforge.net:
Removed file: http://bugs.python.org/file31421/faster_PyEval_SliceIndex.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18813
Stefan Behnel added the comment:
As mentioned, the fannkuch benchmark benefits quite a bit from the fast path,
by 8%. It was a while ago when I tested, though, so I don't have exact numbers
ATM.
--
___
Python tracker rep...@bugs.python.org
http
Stefan Behnel added the comment:
FWIW, LZ4HC compression sounds like an obvious choice for write-once-read-many
data like .pyc files to me. Blosc shows that you can achieve a pretty major
performance improvement just by stuffing more data into less space (although it
does it for RAM and CPU
Ned Batchelder schrieb am 26.10.2014 um 21:45:
On 10/26/14 4:07 PM, Tony the Tiger wrote:
On Wed, 22 Oct 2014 10:27:34 +0200, ast wrote:
If i am writing (-1)**1000 on a python program, will the interpreter do
(-1)*(-1)*...*(-1) or something clever ?
Even vs. odd. It ought to know. I would
Hi,
please keep this on-list.
Nicholas Cole schrieb am 26.10.2014 um 22:43:
On Sun, Oct 26, 2014 at 6:30 PM, Stefan Behnel wrote:
Nicholas Cole schrieb am 26.10.2014 um 18:00:
I'm looking for a python library that can parse XML Documents and
create xml-aware diff files, and then use those
Nicholas Cole schrieb am 26.10.2014 um 18:00:
I'm looking for a python library that can parse XML Documents and
create xml-aware diff files, and then use those to patch documents.
In other words, I'd like something similar to the Google
diff-match-patch tools, but something which is XML aware.
Changes by Stefan Behnel sco...@users.sourceforge.net:
--
nosy: +eli.bendersky, scoder
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22622
Stefan Behnel added the comment:
it might be worth at least considering how a 'one or more parameter' gcd
compares on performance grounds with a two parameter one.
There shouldn't be a difference in practice. The bulk of the work is in the
algorithm that finds the GCD of two numbers
Stefan Behnel added the comment:
Any objections to merging the last patch?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22486
___
___
Python
Stefan Behnel added the comment:
There are not such changes in patch 7. The fractions.gcd() function is
unchanged but no longer used by the Fraction type, which now uses math.gcd()
internally instead.
--
___
Python tracker rep...@bugs.python.org
Stefan Behnel added the comment:
+1
I mean, there is already such a type check in Fraction.__init__(), but I can
see a case for also optimising fraction.gcd() for exact ints.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Stefan Behnel added the comment:
Sure.
--
keywords: +patch
Added file: http://bugs.python.org/file36813/undocument_tp_print.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19477
Stefan Behnel added the comment:
Proper escaping should be added to the _escape_attrib() function into
/xml/etree/ElementTree.py (and equivalent for cElementTree).
Agreed. Can you provide a patch?
--
versions: -Python 2.7
___
Python tracker rep
Changes by Stefan Behnel sco...@users.sourceforge.net:
Removed file: http://bugs.python.org/file36813/undocument_tp_print.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19477
Changes by Stefan Behnel sco...@users.sourceforge.net:
Added file: http://bugs.python.org/file36815/undocument_tp_print.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19477
Chris Angelico schrieb am 02.10.2014 um 16:12:
On Fri, Oct 3, 2014 at 12:07 AM, Grant Edwards wrote:
On 2014-10-01, Steven D'Aprano wrote:
Obviously the easiest way to recover is to exit the current session and
restart it, but as a challenge, can we recover from this state?
Python
Stefan Behnel added the comment:
That does seem odd -- how can you have 'b' of something?
Don't ask this kind of question as long as any math guys are listening.
But seriously, I consider this proposal reasonable. If the problem is that the
counter values can be non-integers, then why
Stefan Behnel added the comment:
I'd raise an exception whenever the values of the Counter turn out to be
uncomparable. If users manage to fill Counters with non-number values that are
comparable amongst each other, or even if each key has a value of a different
type, why not just support
Stefan Behnel added the comment:
Patch 7 works for me. Why are the two Py_ABS() calls at the end needed when we
start off the algorithm with long_abs()?
The Lehmer code is complex (I guess that's why you added the pure Euclidean
implementation), but it's the right algorithm to use here, so
Stefan Behnel added the comment:
One more comment: I also benchmarked the change in long_true_div() now and
found that it's only a minor improvement for large numbers and a
*pessimisation* for small numbers:
Before:
$ ./python -m timeit -s 'x = 5' 'x / -1'
1000 loops, best of 3: 0.0313
Stefan Behnel added the comment:
My personal take is: if there is an implementation in the stdlib, it should be
the one that's most widely applicable. And that includes large numbers. We have
a working implementation that is algorithmically faster for large numbers, so I
can't see why we
Wolfgang Maier schrieb am 26.09.2014 um 09:47:
is there any reliable and inexpensive way to inspect a callable from
running Python code to learn whether it is implemented in Python or C
before calling into it ?
Not really. Both can have very different types and very different
interfaces. There
Chris Angelico schrieb am 26.09.2014 um 10:42:
On Fri, Sep 26, 2014 at 5:47 PM, Wolfgang Maier wrote:
is there any reliable and inexpensive way to inspect a callable from running
Python code to learn whether it is implemented in Python or C before calling
into it ?
I'm not sure you can say
New submission from Stefan Behnel:
The attached patch adds fast paths for PyLong division by 1 and -1, as well as
dividing 0 by something. This was found helpful for fractions normalisation, as
the GCD that is divided by can often be |1|, but firing up the whole division
machinery
Stefan Behnel added the comment:
I tried it, but it seems better to open a new ticket for this as there are
behavioural changes. See #22501.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22464
Stefan Behnel added the comment:
Attaching a similar patch for long_mul().
--
Added file: http://bugs.python.org/file36730/mul_by_1_fast_path.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22501
Stefan Behnel added the comment:
Any optimization requires a benchmark. What is the speedup?
I gave numbers in ticket #22464.
Since many Fraction input values can already be normalised for some reason, the
following change shaves off almost 30% of the calls to
PyNumber_InPlaceFloorDivide
Stefan Behnel added the comment:
@Serhiy: moving the fast path into l_divmod() has the disadvantage of making it
even more complex because we'd then also want to determine the modulus, but
only if requested, and it can be 1, 0 or -1, depending on the second value.
Sounds like a lot more if's
Stefan Behnel added the comment:
Combined patch for both mul and div that fixes the return value of
long_true_div(), as found by Serhiy, and removes the useless change in
long_divrem(), as found by Antoine. Thanks!
All test_long.py tests pass now.
--
Added file: http
Stefan Behnel added the comment:
@Serhiy: please ignore my comment in msg227599. I'll submit a patch that moves
the specialisation to l_divmod().
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22501
Stefan Behnel added the comment:
Thanks for the reviews, here's a new patch.
--
Added file: http://bugs.python.org/file36732/mul_div_by_1_fast_path_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22501
Changes by Stefan Behnel sco...@users.sourceforge.net:
Removed file: http://bugs.python.org/file36732/mul_div_by_1_fast_path_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22501
Stefan Behnel added the comment:
Sorry, last patch version contained a use before type check bug.
--
Added file: http://bugs.python.org/file36733/mul_div_by_1_fast_path_3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Stefan Behnel added the comment:
Here is an incremental patch that adds fast paths for adding and subtracting 0.
Question: the module calls long_long() in some places (e.g. long_abs()) and
thus forces the return type to be exactly a PyLong and not a subtype. My
changes use a plain incref
Changes by Stefan Behnel sco...@users.sourceforge.net:
Added file: http://bugs.python.org/file36736/mul_div_by_1_fast_path_3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22501
Stefan Behnel added the comment:
Ok, updating both patches.
--
Added file: http://bugs.python.org/file36735/add_sub_0_fast_path_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22501
Stefan Behnel added the comment:
I reran the fractions benchmark over the final result and the overall gain
turned out to be, well, small. It's a clearly reproducible 2-3% faster. That's
not bad for the macro impact of a micro-optimisation, but it's not a clear
argument for throwing more code
Stefan Behnel added the comment:
Thanks, Serhiy. However, something is wrong with the implementation. The
benchmark runs into an infinite loop (it seems). And so do the previous
patches. Does it work for you?
--
___
Python tracker rep
Stefan Behnel added the comment:
I compiled it with 30 bit digits, in case that's relevant. (It might be.)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22486
Stefan Behnel added the comment:
This is what hangs for me:
math.gcd(1216342683557601535506311712, 436522681849110124616458784)
a and b keep switching between both values, but otherwise, the loop just
keeps running.
The old fractions.gcd() gives 32 for them
Stefan Behnel added the comment:
I can confirm that it works with 15 bit digits.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22486
Stefan Behnel added the comment:
Since Serhiy gave another round of valid feedback, here's an updated patch.
--
Added file: http://bugs.python.org/file36739/mul_div_by_1_fast_path_3.patch
___
Python tracker rep...@bugs.python.org
http
Stefan Behnel added the comment:
I callgrinded it again and it confirmed that the gain when doing this inside of
long_div() and friends is way lower than doing it right in Fraction.__new__().
It's not safe to do there, though, as is tests on integers are generally not
a good idea in Python
Stefan Behnel added the comment:
That's what the patch does anyway. +1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22486
___
___
Python-bugs
Stefan Behnel added the comment:
Also see issue 22486. There is an unmerged C implementation in the old issue
1682 that would go into the math module.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22477
Stefan Behnel added the comment:
http://bugs.python.org/file9486/lehmer_gcd.patch
(see #1682)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22486
Stefan Behnel added the comment:
The problem is that this changes the behaviour of fractions.gcd() w.r.t.
negative numbers. It's a public function, so we should keep it for backwards
compatibility reasons, *especially* when adding a new function in the math
module.
--
components
Stefan Behnel added the comment:
Oh, and thanks for working on it, Serhiy! :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22486
Stefan Behnel added the comment:
The thing is, if we add something new in a substantially more exposed place
(the math module), then why break legacy code *in addition*? Just leaving it
the way it is won't harm anyone, really.
--
___
Python tracker
Stefan Behnel added the comment:
IMHO, the most straight forward way for a new gcd() function to work would be
to always, predictably return a non-negative value and let users handle all
cases themselves where a negative sign of any or all input values has a
specific meaning to them. That's
Stefan Behnel added the comment:
+1 for Mark Terry, just for the record
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22477
___
___
Python
Stefan Behnel added the comment:
Sorry for reopening this, but I found one more thing. Division is pretty heavy
on PyLong objects and there doesn't seem to be an internal optimisation for
division by 1 and -1. Since many Fraction input values can already be
normalised for some reason
blindanagram schrieb am 24.09.2014 um 15:25:
On 24/09/2014 12:44, Steven D'Aprano wrote:
blindanagram wrote:
[snip]
- Mathworld says that GCD of two negative numbers is a negative number;
- but Mathematica says that GCD of two negative numbers is a positive;
- Wikipedia agrees with
Stefan Behnel added the comment:
BTW, the last two patches (int4 and redundant_property) are ready to be
applied. Anyone?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22464
Stefan Behnel added the comment:
I suggest adding a new implementation instead of replacing the current function
in the fractions module. As Mark noted, the current gcd() is more of a
sideeffect of the fractions module, but there's no real need to change that. It
works perfectly ok
801 - 900 of 3085 matches
Mail list logo
