On 1/26/2010 2:27 AM, Terry Reedy wrote:
On 1/25/2010 5:34 PM, Victor Stinner wrote:
It looks like fuzzing bugs are not always appreciated by developers,
maybe
because they are always "borderline" cases (not "realist").
People grumble, sometimes, even when quietly appreciative.
Sometimes, e
On 1/25/2010 5:34 PM, Victor Stinner wrote:
It looks like fuzzing bugs are not always appreciated by developers, maybe
because they are always "borderline" cases (not "realist").
People grumble, sometimes, even when quietly appreciative.
Sometimes, even if I write a patch, an unit test, expl
--- On Mon, 1/25/10, Steve Howell wrote:
> From: Steve Howell
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: "Michael Foord" , "Nick Coghlan"
>
> Cc: "Christian Heimes" , python-dev@python.org
> Date: Monday, January 25, 2010, 8:33 PM
> I made enough of a patch t
Barry Warsaw python.org> writes:
>
> On Jan 22, 2010, at 10:06 AM, Chris McDonough wrote:
>
> >Can you tell us where Uncle Timmy has been and when he'll be back?
>
> He's given up bags of ham for walls of chocolate.
>
In the Mountain View Chocolate Factory?
Regards,
Vinay Sajip
_
On 1/25/2010 9:32 PM, Nick Coghlan wrote:
However, as Cameron pointed out, the O() value for an operation is an
important characteristic of containers, and having people get used to an
O(1) list.pop(0) in CPython could create problems not only for other
current Python implementations but also fo
> On Tue, Jan 26, 2010 at 06:27, David Lyon
> wrote:
>> Secondly, I never knew about it.
>
> Why did you say the process was like black magic when you didn't know
> about it?
>
> Is this a distutils option?
>
> No, it's new in Python 2.6, which Nick Coghlan clearly stated in the
> text you quoted
On Tue, Jan 26, 2010 at 06:27, David Lyon wrote:
> Secondly, I never knew about it.
Why did you say the process was like black magic when you didn't know about it?
Is this a distutils option?
No, it's new in Python 2.6, which Nick Coghlan clearly stated in the
text you quoted before saying it w
Nick Coghlan wrote:
> Jeffrey Yasskin wrote:
>> (b) could be a problem if we depend on LLVM as a shared library on one
>> of these platforms (and, of course, if LLVM's JIT supports these
>> systems at all). The obvious answers are: 1) --without-llvm on these
>> systems, 2) link statically on these
> At 03:15 PM 1/26/2010 +1100, David Lyon wrote:
>>With all due respect, that process is a bit like a black magic
>>approach. Maybe the capability is there, but it isn't very well
>>documented and it isn't obvious.
>
> I don't see what's so hard about:
>
> 1. Zip up your application in myapp.zip wi
At 03:15 PM 1/26/2010 +1100, David Lyon wrote:
With all due respect, that process is a bit like a black magic
approach. Maybe the capability is there, but it isn't very well
documented and it isn't obvious.
I don't see what's so hard about:
1. Zip up your application in myapp.zip with a __main
On Tue, Jan 26, 2010 at 02:56, Nick Coghlan wrote:
> Lennart Regebro wrote:
>> On Mon, Jan 25, 2010 at 15:30, Nick Coghlan wrote:
>>> Ah, you mean the case where both classes implement the recipe, but know
>>> nothing about each other and hence both return NotImplemented from their
>>> root compa
I made enough of a patch to at least get a preliminary benchmark.
The program toward the bottom of this email runs over 100 times faster with my
patch. The patch still has a ways to go--I use a very primitive scheme to
reclaim orphan pointers (1000 at a time) and I am still segfaulting when
re
Nick Coghlan:
>> I'd like to see Python 3+ be more suitable for full distributable
>> applications over 2.X and earlier.
>
> Out of curiousity, have you tried experimenting with the zipfile
> execution capabilities in 2.6/3.1? A major part of that was to make
> multi-file Python applications nearl
--- On Mon, 1/25/10, Nick Coghlan wrote:
> From: Nick Coghlan
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: "Michael Foord"
> Cc: "Christian Heimes" , python-dev@python.org
> Date: Monday, January 25, 2010, 6:32 PM
> Michael Foord wrote:
> > On 26/01/2010 00:28,
On Mon, Jan 25, 2010 at 9:05 PM, Meador Inge wrote:
> Also related to reduced code size with C++ I was wondering whether or not
> anyone has explored using the ability of some toolchains to remove unused
> code and data? In GCC this can be enabled by compiling with
> '-ffunction-sections' and '-f
Victor> Fuzzing is just one tool helping to improve the global security.
Victor,
Thank you, thank you, thank you.
At my day job I work on automated trading systems. One key component of
such tools is the safeguard subsystem which places limits on various parts
of the system, the rates at w
Michael Foord wrote:
> On 26/01/2010 00:28, Christian Heimes wrote:
>> I favor this approach over an integer offset because doesn't change the
>> semantic of ob_item.
>>
> Well, on the face of it this doesn't sound like a huge increase in
> complexity. Not that I'm qualified to judge.
Christia
Meador Inge wrote:
> When 'obj1' and 'obj2' get linked into the final image there are no
> guarantees on whose constructor (T::T or S::S) will be called first.
> Sometimes folks write code where this initialization order matters. It
> may cause strange behavior at run-time that is hard to pin dow
Jeffrey Yasskin wrote:
> (b) could be a problem if we depend on LLVM as a shared library on one
> of these platforms (and, of course, if LLVM's JIT supports these
> systems at all). The obvious answers are: 1) --without-llvm on these
> systems, 2) link statically on these systems, 3) eliminate the
> We really do need precise descriptions of the problems so we can avoid
them.
Initialization of objects with static storage duration typically get a bad
wrap for two main reasons: (1) each toolchain implements them differently
(but typically by storing initialization thunks in a table that is wal
Tres Seaver wrote:
>> Perhaps we could also add a warning to the open() API which warns
>> in case a file is opened in text mode without specifying an
>> encoding ?!
>
> That ounds like a good plan to me, given that backward-compatibility
> requires keeping the guessing enabled by default.
Perhap
Ron Adam wrote:
> I'd like to see Python 3+ be more suitable for full distributable
> applications over 2.X and earlier.
Out of curiousity, have you tried experimenting with the zipfile
execution capabilities in 2.6/3.1? A major part of that was to make
multi-file Python applications nearly as eas
Lennart Regebro wrote:
> On Mon, Jan 25, 2010 at 15:30, Nick Coghlan wrote:
>> Ah, you mean the case where both classes implement the recipe, but know
>> nothing about each other and hence both return NotImplemented from their
>> root comparison?
>
> Well, only one needs to return NotImplemented,
On 25Jan2010 12:34, Steve Howell wrote:
| From: Raymond Hettinger
| > 1) To many things in the Python world rely on
| > the current implementation of lists. It's not
| > worth breaking third-party extensions, tools like psyco,
| > work on unladen swallow, and other implementations of Python
| >
Hey Floris,
On Mon, Jan 25, 2010 at 1:25 PM, Floris Bruynooghe
wrote:
> On Mon, Jan 25, 2010 at 10:14:35AM -0800, Collin Winter wrote:
>> I'm working on a patch to completely remove all traces of C++ with
>> configured with --without-llvm. It's a straightforward change, and
>> should present no d
--- On Mon, 1/25/10, Christian Heimes wrote:
> From: Christian Heimes
> Michael Foord wrote:
> > How great is the complication? Making list.pop(0)
> efficient sounds like
> > a worthy goal, particularly given that the reason you
> don't use it is
> > because you *know* it is inefficient (so the
On Mon, Jan 25, 2010 at 7:32 PM, Michael Foord
wrote:
> On 26/01/2010 00:28, Christian Heimes wrote:
>>
>> Michael Foord wrote:
>>
>>>
>>> How great is the complication? Making list.pop(0) efficient sounds like
>>> a worthy goal, particularly given that the reason you don't use it is
>>> because y
On 26/01/2010 00:28, Christian Heimes wrote:
Michael Foord wrote:
How great is the complication? Making list.pop(0) efficient sounds like
a worthy goal, particularly given that the reason you don't use it is
because you *know* it is inefficient (so the fact that you don't use it
isn't eviden
Michael Foord wrote:
> How great is the complication? Making list.pop(0) efficient sounds like
> a worthy goal, particularly given that the reason you don't use it is
> because you *know* it is inefficient (so the fact that you don't use it
> isn't evidence that it isn't wanted - merely evidence
--- On Mon, 1/25/10, Benjamin Peterson wrote:
> From: Benjamin Peterson
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: "Steve Howell"
> Cc: python-dev@python.org
> Date: Monday, January 25, 2010, 3:15 PM
> 2010/1/25 Steve Howell :
> >> From: Raymond Hettinger
> >
On 26/01/2010 00:12, Christian Heimes wrote:
Benjamin Peterson wrote:
Yes, but in either of these cases is there an excellent performance
improvement to be gained and is it worth the complexity of your
optimization? I think not.
Me, too.
I already tried to explain Steve that I have us
Hi,
Le mardi 26 janvier 2010 00:40:47, Christian Heimes a écrit :
> Victor Stinner wrote:
> > I'm running regulary my fuzzer (Fusil) on CPython since summer 2008: I
> > tested Python 2.5, 2.6, 2.7, 3.0, 3.1 and 3.2. I'm only looking for
> > "fatal errors": Python process killed by a signal, or som
Benjamin Peterson wrote:
> Yes, but in either of these cases is there an excellent performance
> improvement to be gained and is it worth the complexity of your
> optimization? I think not.
Me, too.
I already tried to explain Steve that I have used list.pop(0) in very
few cases during my seven yea
--- On Mon, 1/25/10, Mike Klaas wrote:
> From: Mike Klaas
> > On Mon, Jan 25, 2010 at 1:22 PM, Steve Howell
> wrote:
> >>
> >> I haven't completely worked out the best strategy
> to eventually release
> >> the memory taken up by the pointers of the
> unreleased elements, but the
> >> worst case
Victor Stinner wrote:
> I'm running regulary my fuzzer (Fusil) on CPython since summer 2008: I tested
> Python 2.5, 2.6, 2.7, 3.0, 3.1 and 3.2. I'm only looking for "fatal errors":
> Python process killed by a signal, or sometimes fuzzer timeouts. I ignore
> most
> timeout results because most
On Mon, Jan 25, 2010 at 5:34 PM, Victor Stinner
wrote:
> Hi,
>
> I'm running regulary my fuzzer (Fusil) on CPython since summer 2008: I tested
> Python 2.5, 2.6, 2.7, 3.0, 3.1 and 3.2. I'm only looking for "fatal errors":
> Python process killed by a signal, or sometimes fuzzer timeouts. I ignore
On Mon, Jan 25, 2010 at 11:32 AM, Daniel Stutzbach
wrote:
> On Mon, Jan 25, 2010 at 1:22 PM, Steve Howell wrote:
>>
>> I haven't completely worked out the best strategy to eventually release
>> the memory taken up by the pointers of the unreleased elements, but the
>> worst case scenario is that
2010/1/25 Steve Howell :
>> From: Raymond Hettinger
>>
>> On Jan 25, 2010, at 12:36 PM, Steve Howell wrote:
>>
>> >
>> > Deque does not support all the operations that list
>> does. It is also roughly twice as slow for accessing
>> elements (I've measured it).
>>
>>
>> ISTM that apps that want to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Victor Stinner wrote:
> Hi,
>
> I'm running regulary my fuzzer (Fusil) on CPython since summer 2008: I tested
> Python 2.5, 2.6, 2.7, 3.0, 3.1 and 3.2. I'm only looking for "fatal errors":
> Python process killed by a signal, or sometimes fuzzer tim
>> a) main() is not compiled with g++: static objects get not constructed
>> b) code that gets linked into shared libraries (assuming the system
>> supports them) does not get its initializers invoked.
>> c) compilation of main() with a C++ compiler, but then linking with ld
>> results in an un
Hi,
I'm running regulary my fuzzer (Fusil) on CPython since summer 2008: I tested
Python 2.5, 2.6, 2.7, 3.0, 3.1 and 3.2. I'm only looking for "fatal errors":
Python process killed by a signal, or sometimes fuzzer timeouts. I ignore most
timeout results because most of them are valid function c
On Mon, Jan 25, 2010 at 1:50 PM, "Martin v. Löwis" wrote:
>> We really do need precise descriptions of the problems so we can avoid them.
>
> One family of problems is platform lack of initializer support in the
> object file format; any system with traditional a.out (or b.out) is
> vulnerable (al
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey Yasskin wrote:
> On Mon, Jan 25, 2010 at 10:44 AM, Tres Seaver wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Collin Winter wrote:
>>
>>> For reference, what are these "obscure platforms" where static
>>> initializers cause p
Floris Bruynooghe wrote:
> Since I was under the
> impression that the JIT/LLVM can't emit machine code for the platforms
> where these C++ problems would likely occur nothing would be lost.
AFAICT, LLVM doesn't support Itanium or HPPA, and apparently not POWER,
either (although they do support PP
> We really do need precise descriptions of the problems so we can avoid them.
One family of problems is platform lack of initializer support in the
object file format; any system with traditional a.out (or b.out) is
vulnerable (also, COFF is, IIRC).
The solution e.g. g++ came up with is to have
On Mon, Jan 25, 2010 at 11:48:56AM -0800, Jeffrey Yasskin wrote:
> On Mon, Jan 25, 2010 at 10:44 AM, Tres Seaver wrote:
> > Collin Winter wrote:
> >
> >> For reference, what are these "obscure platforms" where static
> >> initializers cause problems?
> >
> > It's been a long while since I had to d
> From: Raymond Hettinger
>
> On Jan 25, 2010, at 12:36 PM, Steve Howell wrote:
>
> >
> > Deque does not support all the operations that list
> does. It is also roughly twice as slow for accessing
> elements (I've measured it).
>
>
> ISTM that apps that want to insert or pop from the front of
> l
On Mon, Jan 25, 2010 at 10:14:35AM -0800, Collin Winter wrote:
> I'm working on a patch to completely remove all traces of C++ with
> configured with --without-llvm. It's a straightforward change, and
> should present no difficulties.
Great to hear that, thanks for caring.
> For reference, what a
On Jan 25, 2010, at 12:36 PM, Steve Howell wrote:
>
> Deque does not support all the operations that list does. It is also roughly
> twice as slow for accessing elements (I've measured it).
ISTM that apps that want to insert or pop from the front of list are also apps
that don't care about
--- On Mon, 1/25/10, Benjamin Peterson wrote:
> 2010/1/25 Steve Howell :
> > I am interested in creating a patch to make deleting
> elements from the front
> > of Python list work in O(1) time by advancing the
> ob_item pointer.
>
> How about just using a deque?
Deque does not support all the op
From: Raymond Hettinger
> On Jan 25, 2010, at 11:22 AM, Steve Howell
> wrote:
> I
> am interested in creating a patch to make deleting elements
> from the front of Python list work in O(1) time by advancing
> the ob_item pointer.
>
> +1 on doing whatever experiments you feel like
> doing-1 on putt
--- On Mon, 1/25/10, Daniel Stutzbach wrote:
> FWIW, for a long-running FIFO queue, it's critical to
> release some of the memory along the way, otherwise the
> amount of wasted memory is unbounded.
>
Somebody implementing a long-running FIFO queue should actually be using deque
instead of lis
On Mon, Jan 25, 2010 at 10:44 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Collin Winter wrote:
>
>> For reference, what are these "obscure platforms" where static
>> initializers cause problems?
>
> It's been a long while since I had to deal with it, but the "usual
Thanks. I see that you've cc'd the PSF already, so I'll wait a while and
ask them directly if I don't hear anything.
Stefan Krah
Guido van Rossum wrote:
> I would ask a lawyer. If the PSF's lawyer (Van Lindbergh) is okay
> you're golden. Most lawyer don't like licenses that are clearly
> writt
2010/1/25 Steve Howell :
> I am interested in creating a patch to make deleting elements from the front
> of Python list work in O(1) time by advancing the ob_item pointer.
How about just using a deque?
--
Regards,
Benjamin
___
Python-Dev mailing lis
On Jan 25, 2010, at 11:22 AM, Steve Howell wrote:
> I am interested in creating a patch to make deleting elements from the front
> of Python list work in O(1) time by advancing the ob_item pointer.
+1 on doing whatever experiments you feel like doing
-1 on putting something like this in the cor
On Mon, Jan 25, 2010 at 1:22 PM, Steve Howell wrote:
> I haven't completely worked out the best strategy to eventually release the
> memory taken up by the pointers of the unreleased elements, but the worst
> case scenario is that the unused memory only gets wasted until the time that
> the list
I am interested in creating a patch to make deleting elements from the front of
Python list work in O(1) time by advancing the ob_item pointer.
The patch will probably be rejected, but I would like to try it anyway as an
exercise in digging into the CPython source, and working through the proces
Hi Cesare,
On Sat, Jan 23, 2010 at 1:09 PM, Cesare Di Mauro
wrote:
> Hi Collin
>
> IMO it'll be better to make Unladen Swallow project a module, to be
> installed and used if needed, so demanding to users the choice of having it
> or not. The same way psyco does, indeed.
> Nowadays it requires to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Collin Winter wrote:
> For reference, what are these "obscure platforms" where static
> initializers cause problems?
It's been a long while since I had to deal with it, but the "usual
suspets" back in the day were HP-UX, AIX, and Solaris with non-GCC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
M.-A. Lemburg wrote:
> Antoine Pitrou wrote:
>> Le samedi 23 janvier 2010 à 20:43 +0100, M.-A. Lemburg a écrit :
>>> Now, we cannot easily remove this guessing since we're in stable
>>> mode again with 3.1. Perhaps we should add a way to at least be
>>
Hi Floris,
On Sun, Jan 24, 2010 at 3:40 AM, Floris Bruynooghe
wrote:
> On Sat, Jan 23, 2010 at 10:09:14PM +0100, Cesare Di Mauro wrote:
>> Introducing C++ is a big step, also. Aside the problems it can bring on some
>> platforms, it means that C++ can now be used by CPython developers. It
>> does
Guido van Rossum wrote:
Please mail me topics you'd like to hear me talk about in my keynote
at PyCon this year.
How about something on the differences and obstacles of using Python for
developing full distributable applications vs small local scripts.
I'd like to see Python 3+ be more suit
I would ask a lawyer. If the PSF's lawyer (Van Lindbergh) is okay
you're golden. Most lawyer don't like licenses that are clearly
written by laypersons like this one, so it may require some convincing
to do.
--Guido
On Mon, Jan 25, 2010 at 7:37 AM, Victor Stinner
wrote:
> Hi,
>
> Le lundi 25 jan
Hi,
Le lundi 25 janvier 2010 13:49:48, Stefan Krah a écrit :
> The license is public domain like:
>
> http://www.hackersdelight.org/permissions.htm
>
> Is this license good enough for inclusion in Python?
"You are free to use, copy, and distribute any of the code on this web site,
whether modi
On Mon, Jan 25, 2010 at 15:30, Nick Coghlan wrote:
> Ah, you mean the case where both classes implement the recipe, but know
> nothing about each other and hence both return NotImplemented from their
> root comparison?
Well, only one needs to return NotImplemented, actually.
> OK, that sounds li
Lennart Regebro wrote:
> On Mon, Jan 25, 2010 at 14:34, Nick Coghlan wrote:
>> However, returning NotImplemented generally implies that A and B are
>> *different* classes
>
> Which is exactly the case here.
It wasn't in my tests though - I used the same class on both sides of
the comparison.
>>
On Mon, Jan 25, 2010 at 14:34, Nick Coghlan wrote:
> However, returning NotImplemented generally implies that A and B are
> *different* classes
Which is exactly the case here.
> so I think this is more of a theoretical problem
> than a practical one.
How so? The whole point of returning NotImpl
Lennart Regebro wrote:
> 1. A() < B() will call A.__lt__(B) which will return NotImplemented.
> 2. which will mean that Python calls B.__ge__(A)
> 3. Which B implements by doing A < B
> 4. Start over at 1.
>
>
> Have I missed something, or is this recipe incomplete by not handling
> the NotImplem
Hi,
I would like to use this code from Hacker's Delight in cdecimal:
http://www.hackersdelight.org/HDcode/divlu.c
The divlu function is Knuth's algorithm D optimized for 64bit/32bit -> 32bit
divrem. It is going to be used for (hypothetical?) platforms without uint64_t.
The license is public d
If you look at the description of the rich comparison methods in the
documentation:
http://docs.python.org/reference/datamodel.html#object.__lt__
It refers to a recipe: http://code.activestate.com/recipes/576529/
However, that recipe will convert a __ge__(self, other) into a other < self.
So when
Antoine Pitrou wrote:
> Le samedi 23 janvier 2010 à 20:43 +0100, M.-A. Lemburg a écrit :
>>
>> Now, we cannot easily remove this guessing since we're in stable
>> mode again with 3.1. Perhaps we should add a way to at least be
>> able to switch off this guessing, so that applications can be
>> test
72 matches
Mail list logo
