On 17.07.2014 20:34, Paul Rubin wrote:
> Could os.urandom() be patched to use the new Linux getrandom() system
> call on systems where it is available? Further info:
>
> http://lists.openwall.net/linux-kernel/2014/07/17/235
>
> I've stopped posting to the Python bug tracker because the password
On 17/07/14 20:34, Paul Rubin wrote:
Could os.urandom() be patched to use the new Linux getrandom() system
call on systems where it is available?
/dev/urandom exists on other Unix-like systems as well.
Right now os.urandom only uses special system calls on Windows.
Sturla
--
https://mail.
In article <[email protected]>,
Paul Rubin wrote:
> I've stopped posting to the Python bug tracker because the password
> management issues became too annoying.
Can you elaborate on the problems you are having?
--
Ned Deily,
[email protected]
--
https://mail.python.org/mailman/
On Fri, Jul 18, 2014 at 4:34 AM, Paul Rubin wrote:
> Could os.urandom() be patched to use the new Linux getrandom() system
> call on systems where it is available? Further info:
>
> http://lists.openwall.net/linux-kernel/2014/07/17/235
Uhm... does that even exist in kernel trunk yet? That's pret
On 1/22/10 5:47 PM, G73 wrote:
im trying to update a patch. here is link to various patches
http://bugs.python.org/issue6075
how do i update the patch, say for EditorWindow.patch.
i have located my python installation the EditorWindow.py, and i can
see some differences (which lines from the patc
sorry, pls forget :-(
--
http://mail.python.org/mailman/listinfo/python-list
Nicko wrote:
> I note that in both of those tests you didn't actually ever realise the
> concatenated string. Can you give us figures for these tests having
> forced the concatenated string to be computed?
Sure, good call. And bad news.
All these benchmarks were with functions taking N argument
Larry Hastings wrote:
> It's *slightly* slower for two:
>
> def addTwoThings(a, b):
> return a + b
> for i in range(1000):
> x = addTwoThings("aaa", "bbb")
...
> But starts paying off already, even with three:
>
> def addThreeThings(a, b, c):
> return a + b + c
> for i in range(1000
"> Forgot to mention this, in case you haven't done so post your original
> message/patch on the python-dev lists since that's where the decisions
> are made. This group is more end-user oriented.
>
> http://mail.python.org/pipermail/python-dev/2006-October/thread.html
It is often good to get com
Larry Hastings wrote:
> That patch addressed the same general problem, but took a completely
> different approach. For the record, this patch (#980695) optimized "x
Larry,
Forgot to mention this, in case you haven't done so post your original
message/patch on the python-dev lists since that's w
Istvan Albert wrote:
> I remember a similar patch from some time ago:
> > http://mail.python.org/pipermail/python-dev/2004-August/046686.html
That patch addressed the same general problem, but took a completely
different approach. For the record, this patch (#980695) optimized "x
+= a" by examini
I remember a similar patch from some time ago:
http://mail.python.org/pipermail/python-dev/2004-August/046686.html
i
--
http://mail.python.org/mailman/listinfo/python-list
John Machin wrote:
> Don't you mean y = x[1] or something like that? y = "".join(x) looks
> like a copy-paste error.
You're right, by gum. Worse than that, my benchmark wasn't actually
*doing* much of anything there; at the end of the run x was still
length 0. That was sloppy, and I apologize.
Larry Hastings wrote:
>
> John Machin wrote:
> > try benchmarking this ... well "style" may not be the appropriate word
>
> Running this under Python 2.5 release:
> x = []
> xappend = x.append
> for i in xrange(1000):
> xappend("a")
> y = "".join(x)
> took 3281ms.
>
>
Fredrik Lundh wrote:
> You should also benchmark this against code that uses the ordinary
> append/join pattern.
Sorry, thought I had. Of course, now that the patch is up on
Sourceforce you could download it and run all the benchmarks you like.
For all the benchmarks I ran below, the number list
In article <[EMAIL PROTECTED]>,
Larry Hastings <[EMAIL PROTECTED]> wrote:
>Steve Holden wrote:
>>
>> I think your project might make a very
>> interesting PyCon paper for people who were thinking about joining the
>> development effort but hadn't yet started.
>
>Perhaps; I've never been to PyCon, b
Fredrik Lundh wrote:
>
> You should also benchmark this against code that uses the ordinary
> append/join pattern. (you've posted conflicting benchmarks for 2.5,
> but if I'm trusting the benchmarks that looks more reasonable, the
> standard implementation pattern is still around 10 times faster
Larry Hastings wrote:
> There are some improvements in this version. Specifically:
>
> * Python will no longer crash if you do ten million prepends
> ( x = 'a' + x ). Since the problem was blowing the stack
> with an incredibly deep render, I now limit the depth of
> the string concatenat
An update: I have submitted this as a patch on SourceForge.
It's request ID #1569040.
http://sourceforge.net/tracker/?group_id=5470&atid=305470
I invite everyone to take it for a spin!
There are some improvements in this version. Specifically:
* Python will no longer crash if you do ten
Congratulations on the clear way in which you have set out your proposal.
I hope that it will make its way to PEPdom.
Colin W.
Larry Hastings wrote:
> This is such a long posting that I've broken it out into sections.
> Note that while developing this patch I discovered a Subtle Bug
> in CPython
Larry Hastings wrote:
> Fredrik Lundh wrote:
>
>>so what does the benchmark look like if you actually do this ?
>
>
> Okay, timing this:
> x = ""
> for i in range(10):
> x += "a"
> t = x[1] # forces the concat object to render
>
> The result:
> Python 2.5 release: 30.0s
> Pyth
Larry Hastings wrote:
[snip]
> The core concept: adding two strings together no longer returns a pure
> "string" object. Instead, it returns a "string concatenation" object
> which holds references to the two strings but does not actually
> concatenate
> them... yet. The strings are concatenated
Fredrik Lundh wrote:
> so what does the benchmark look like if you actually do this ?
Okay, timing this:
x = ""
for i in range(10):
x += "a"
t = x[1] # forces the concat object to render
The result:
Python 2.5 release: 30.0s
Python 2.5 locally built: 30.2s
Python 2.5 concat: 4
Larry Hastings wrote:
>
> At the exact moment that the loop is done, it's a
> PyStringConcatenationObject * which points to a deep one-sided tree of
> more PyStringConcatenationObject * objects. Its ob_sval is NULL, which
> means that the first time someone asks for its value (via the macro
> PyS
Fredrik Lundh wrote:
> >> what's in "s" when that loop is done?
> > It's equivalent to " 'a' * 1000 ". (I shan't post it here.)
> but what *is* it ? an ordinary PyString object with a flattened buffer,
> or something else ?
At the exact moment that the loop is done, it's a
PyStringConcatenat
William Heymann wrote:
> This is a pretty small change but I would suggest xrange instead of range.
Good point! Since I was calling range() during the benchmark, it was
timed too. Switching to xrange() will mean less overhead.
I re-ran this benchmark (again):
s = ""
for i in range(10):
Larry Hastings wrote:
>> what's in "s" when that loop is done?
>
> It's equivalent to " 'a' * 1000 ". (I shan't post it here.)
but what *is* it ? an ordinary PyString object with a flattened buffer,
or something else ?
--
http://mail.python.org/mailman/listinfo/python-list
On Friday 29 September 2006 08:34, Larry Hastings wrote:
> It would still blow up if you ran
> s = ""
> for i in range(1000):
> s = "a" + s
This is a pretty small change but I would suggest xrange instead of range.
That way you don't allocate that large list just to throw all the ite
Fredrik Lundh wrote:
> > Sure. Here are the results, but with range (1000):
> ten million? what hardware are you running this on?
Athlon 64 x2 4400+ (aka 2.2GHz), 3GB of RAM, Windows XP.
> what's in "s" when that loop is done?
It's equivalent to " 'a' * 1000 ". (I shan't post it here
Larry Hastings wrote:
>> Nice idea, though. You might also see how it does on tasks like
>>
>> s = ""
>> for i in range(10):
>> s += "a"
>
> Sure. Here are the results, but with range (1000):
ten million? what hardware are you running this on?
> Python 2.5 release: 31.0s
>
Steve Holden wrote:
> you should diff your source against the current
> SVN repository and lodge that diff as a patch on SourceForge.
Okay, I'll try to do that today.
> Your suggested bug isn't, I think a real bug in the current
> implementation because as I understand it Python strings do alwa
Carl Friedrich Bolz wrote:
> Robin Becker wrote:
>> Larry Hastings wrote:
>> __
>>> THE PATCH
>>>
>>> The core concept: adding two strings together no longer returns a pure
>>> "string" object. Instead, it returns a "string concatenation" object
>>> which holds references to the two strings bu
Robin Becker wrote:
> Larry Hastings wrote:
> __
>> THE PATCH
>>
>> The core concept: adding two strings together no longer returns a pure
>> "string" object. Instead, it returns a "string concatenation" object
>> which holds references to the two strings but does not actually
>> concatenate
>
Robin Becker wrote:
> Larry Hastings wrote:
> __
>> THE PATCH
>>
>> The core concept: adding two strings together no longer returns a pure
>> "string" object. Instead, it returns a "string concatenation" object
>> which holds references to the two strings but does not actually
>> concatenate
>
Robin Becker wrote:
> Larry Hastings wrote:
> __
>> THE PATCH
>>
>> The core concept: adding two strings together no longer returns a pure
>> "string" object. Instead, it returns a "string concatenation" object
>> which holds references to the two strings but does not actually
>> concatenate
>
Robin Becker wrote:
> Larry Hastings wrote:
> __
>> THE PATCH
>>
>> The core concept: adding two strings together no longer returns a pure
>> "string" object. Instead, it returns a "string concatenation" object
>> which holds references to the two strings but does not actually
>> concatenate
>
28 Sep 2006 19:07:23 -0700, Larry Hastings <[EMAIL PROTECTED]>:
> THE BENCHMARKS
>
> Benchmark 1:
> def add(a, b, c, ... t): return a + b + c + ... + t
> for i in range(1000): add("aaa", "bbb", "ccc", ..., "ttt")
[snip]
What about "a + b"? Or "a + b + c"? Does it have a large o
Larry Hastings wrote in news:1159495643.213830.289620
@m7g2000cwm.googlegroups.com in comp.lang.python:
> _
> THE PATCH
>
> The core concept: adding two strings together no longer returns a pure
> "string" object. Instead, it returns a "string concatenation" object
> which holds referenc
Larry Hastings wrote:
__
> THE PATCH
>
> The core concept: adding two strings together no longer returns a pure
> "string" object. Instead, it returns a "string concatenation" object
> which holds references to the two strings but does not actually
> concatenate
> them... yet. The strings ar
Larry Hastings wrote:
> This is such a long posting that I've broken it out into sections.
> Note that while developing this patch I discovered a Subtle Bug
> in CPython, which I have discussed in its own section below.
>
[...]
> __
> THE SUBMISSION
>
> I don't know the protocol from
Here's method 3 :
# Python 2.3 (no generator expression)
a.update([(k,v) for k,v in b.iteritems() if k not in a])
# Python 2.4 (with generator expression)
a.update((k,v) for k,v in b.iteritems() if k not in a)
It's a bit cleaner but still less efficient than using what's already
in the PyDict_Me
Christopher Li wrote:
> I am surprised to find out the mmap module in python always
> mmap from offset 0. So I just hack up some patch to allow it
> accept offset arguments.
patches posted to the newsgroup are likely to be ignored or
forgotten.
patches posted to the patch tracker
http://sou
Stefan Behnel wrote:
Nick Coghlan wrote
a) Patches are more likely to be looked at if placed on the SF patch
tracker.
see your own b), I wanted to discuss them first.
Fair enough.
Still, when I first tried out the Template class, I immediately stumbled
over the fact that the substitute methods
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> a) Patches are more likely to be looked at if placed on the SF patch tracker.
>
> b) I don't quite see the point, given how easy these are to spell using the
> basic safe_substitute. You're replacing one liners with one-liners.
c) add a documentati
Nick Coghlan wrote
a) Patches are more likely to be looked at if placed on the SF patch
tracker.
see your own b), I wanted to discuss them first.
b) I don't quite see the point, given how easy these are to spell using
the basic safe_substitute. You're replacing one liners with one-liners.
Still,
a) Patches are more likely to be looked at if placed on the SF patch
tracker.
b) I don't quite see the point, given how easy these are to spell using the
basic safe_substitute. You're replacing one liners with one-liners.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Aust
"Stefan Behnel"
> I generally believe that many programmers will
> silently expect frozenset() to be (and become) more efficient than set() - in
> whatever regard: processing, memory, etc.
That belief is without foundation. Except for mutating
methods and hashing methods, both set() and frozenset
Raymond Hettinger wrote:
It is not quite correct to say that this is what all immutables do:
.>>>x = 500
.>>>y = 600 - 100
.>>>x is y
False
That is an implementation detail, not guaranteed by the language (i.e. not
necessarily true in future versions, in Jython, or other implementations). It
is j
> > It is not quite correct to say that this is what all immutables do:
> >
> >.>>>x = 500
> >.>>>y = 600 - 100
> >.>>>x is y
> > False
>
> I know. The same is true for concateneted strings, etc. But whenever an
> immutable object is created directly ('by hand'), it holds. It also holds,
> btw, for
On Sat, 12 Feb 2005 23:21:58 +0100, Stefan Behnel <[EMAIL PROTECTED]> wrote:
>
>
> Raymond Hettinger wrote:
> >Stefan Behnel wrote:
> >>I stumbled over the fact that 'frozenset()' doesn't return a constant but
> >>creates a new object everytime. Since it is immutable, I wrote to c.l.py
> >>that
Raymond Hettinger wrote:
>Stefan Behnel wrote:
I stumbled over the fact that 'frozenset()' doesn't return a constant but
creates a new object everytime. Since it is immutable, I wrote to c.l.py
that this behaviour is different from what tuple() & Co do.
It is not quite correct to say that this i
51 matches
Mail list logo
