> Perhaps timeit should grow a macro-benchmark tool too? I find myself often
> using timeit to time macro-benchmarks simply because it's more convenient at
> the interactive interpreter than the alternatives.
>
> Something like this idea perhaps?
>
> http://preshing.com/20110924/timing-your-code-us
On 08Oct2011 01:13, Michael Foord wrote:
| On 08/10/2011 00:19, Terry Reedy wrote:
| >On 10/7/2011 6:18 AM, Glyph wrote:
| >
| >>To sum up what I believe is now the consensus from this thread:
| >>
| >> 1. Anyone setting up a buildslave should take care to invoke the build
| >>in an environmen
Antoine Pitrou wrote:
In CPython, looking for reference cycles is a parasitic task that
interferes with what you are trying to measure. It is not critical in
any way, and you can schedule it much less often if it takes too much
CPU, without any really adverse consequences. timeit takes the safe w
On Sat, Oct 8, 2011 at 2:18 AM, Antoine Pitrou wrote:
>
>> >
>> > In CPython, looking for reference cycles is a parasitic task that
>> > interferes with what you are trying to measure. It is not critical in
>> > any way, and you can schedule it much less often if it takes too much
>> > CPU, withou
> >
> > In CPython, looking for reference cycles is a parasitic task that
> > interferes with what you are trying to measure. It is not critical in
> > any way, and you can schedule it much less often if it takes too much
> > CPU, without any really adverse consequences. timeit takes the safe way
On Sat, Oct 8, 2011 at 1:47 AM, Antoine Pitrou wrote:
> On Sat, 8 Oct 2011 00:13:40 +0200
> Maciej Fijalkowski wrote:
>> On Fri, Oct 7, 2011 at 11:47 PM, Nick Coghlan wrote:
>> > On Fri, Oct 7, 2011 at 4:50 PM, Maciej Fijalkowski
>> > wrote:
>> >> Hi
>> >>
>> >> Can we disable by default disab
On 08/10/2011 00:19, Terry Reedy wrote:
On 10/7/2011 6:18 AM, Glyph wrote:
To sum up what I believe is now the consensus from this thread:
1. Anyone setting up a buildslave should take care to invoke the build
in an environment where an out-of-control buildbot, potentially
executing a
On Sat, 8 Oct 2011 00:13:40 +0200
Maciej Fijalkowski wrote:
> On Fri, Oct 7, 2011 at 11:47 PM, Nick Coghlan wrote:
> > On Fri, Oct 7, 2011 at 4:50 PM, Maciej Fijalkowski wrote:
> >> Hi
> >>
> >> Can we disable by default disabling the cyclic gc in timeit module?
> >> Often posts on pypy-dev or o
On 10/7/2011 6:18 AM, Glyph wrote:
To sum up what I believe is now the consensus from this thread:
1. Anyone setting up a buildslave should take care to invoke the build
in an environment where an out-of-control buildbot, potentially
executing arbitrarily horrible and/or malicious code
On 10/7/2011 10:06 AM, Nick Coghlan wrote:
On Fri, Oct 7, 2011 at 9:21 AM, "Martin v. Löwis" wrote:
> if (!PyUnicode_READY(foo)) is not better, also because of
PyUnicode_IS_READY(foo).
I prefer PyUnicode_IS_READY(foo)< 0 over PyUnicode_IS_READY(foo) == -1.
Ok, so feel free to replace
On Fri, Oct 7, 2011 at 11:47 PM, Nick Coghlan wrote:
> On Fri, Oct 7, 2011 at 4:50 PM, Maciej Fijalkowski wrote:
>> Hi
>>
>> Can we disable by default disabling the cyclic gc in timeit module?
>> Often posts on pypy-dev or on pypy bugs contain usage of timeit module
>> which might change the perf
On Fri, Oct 7, 2011 at 4:50 PM, Maciej Fijalkowski wrote:
> Hi
>
> Can we disable by default disabling the cyclic gc in timeit module?
> Often posts on pypy-dev or on pypy bugs contain usage of timeit module
> which might change the performance significantly. A good example is
> json benchmarks -
Hi
Can we disable by default disabling the cyclic gc in timeit module?
Often posts on pypy-dev or on pypy bugs contain usage of timeit module
which might change the performance significantly. A good example is
json benchmarks - you would rather not disable cyclic GC when running
a web app, so enco
Le jeudi 6 octobre 2011 02:06:30, Victor Stinner a écrit :
> The rfind case is really strange: the code between Python 3.2 and 3.3 is
> exactly the same. Even in Python 3.2: rfind looks twice faster than find:
>
> ("AB"*300+"C").find("BC") (*1000) : 1.21
> ("C"+"AB"*300).rfind("CA") (*1000) : 0.57
Le vendredi 7 octobre 2011 21:02:00, Martin v. Löwis a écrit :
> After discussion with several people, I changed
> PyUnicode_KIND to have values of 1,2,4, respectively,
> thus reflecting the element size of the string numerically.
You may rename it to "character size" (char_size) ;-)
Victor
_
On Fri, Oct 7, 2011 at 3:57 PM, anatoly techtonik wrote:
> On Sun, Oct 2, 2011 at 3:17 PM, Maciej Fijalkowski wrote:
>> On Sun, Oct 2, 2011 at 8:05 AM, Maciej Fijalkowski wrote:
>>> On Sun, Oct 2, 2011 at 5:02 AM, anatoly techtonik
>>> wrote:
Hello,
I've stumbled upon Dave Beazl
On Fri, Oct 7, 2011 at 12:02 PM, "Martin v. Löwis" wrote:
> After discussion with several people, I changed
> PyUnicode_KIND to have values of 1,2,4, respectively,
> thus reflecting the element size of the string numerically.
Hah! I suggested this when first reviewing the PEP. :-)
--
--Guido va
After discussion with several people, I changed
PyUnicode_KIND to have values of 1,2,4, respectively,
thus reflecting the element size of the string numerically.
As a consequence, the PyUnicode_CHARACTER_SIZE and
PyUnicode_KIND_SIZE macros are now gone.
Regards,
Martin
__
I see that the Packaging documentation is now more complete (at least
at docs.python.org) - I don't know if it's deemed fully complete yet,
but I scanned the documentation and "Installing Python Projects" looks
pretty much converted (and very good!!), but "Distributing Python
Projects" still has qu
On Fri, Oct 7, 2011 at 4:18 AM, Glyph wrote:
> On Oct 7, 2011, at 5:10 AM, Stephen J. Turnbull wrote:
>
> The principle here is "ran as root" without further explanation is a
> litmus test for "not bothering about security", even today. It's
> worth asking for explanation, or at least a comment t
Hi Ned,
> Issue #7367: Add test case to test_pkgutil for walking path with
> an unreadable directory.
Kudos for fixing this bug, the pydoc one and cleaning the duplicate reports!
> diff --git a/Lib/test/test_pkgutil.py b/Lib/test/test_pkgutil.py
> --- a/Lib/test/test_pkgutil.py
> +++ b/Lib/test
Hi,
I too prefer venv (module) and pyvenv (script).
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ACTIVITY SUMMARY (2011-09-30 - 2011-10-07)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3052 ( +6)
closed 21853 (+40)
total 24905 (+46)
Open issues wit
Le 06/10/2011 12:42, Victor Stinner a écrit :
"A".join(["Bob"]*100)): 0.92 => 2.11
I just optimized PyUnicode_Join() for such dummy benchmark. It's now
1.2x slower instead of 2.3x slower on this dummy benchmark.
With longer *ASCII* strings, Python 3.3 is now 2x (narrow 3.2) or 4x
(wide 3.2
Glyph writes:
> Have I left anything out? :-)
Probably. That's the nature of the problem. But you caught enough
that if all our buildbots are set up that way, the Bad Guys' scripts
will probably conclude there's nothing to see here, and move along.
_
On Fri, 7 Oct 2011 09:04:08 -0500
Brian Curtin wrote:
> On Fri, Oct 7, 2011 at 08:57, anatoly techtonik wrote:
> >> It's just that SimpleHTTPServer doesn't quite survive slashdot effect.
> >> Where do I fill a bug report :)
> >
> > http://bugs.python.org
>
> http://www.theonion.com/
Does theoni
On Fri, Oct 7, 2011 at 9:21 AM, "Martin v. Löwis" wrote:
> > if (!PyUnicode_READY(foo)) is not better, also because of
>>
>> PyUnicode_IS_READY(foo).
>>
>> I prefer PyUnicode_IS_READY(foo) < 0 over PyUnicode_IS_READY(foo) == -1.
>>
>
> Ok, so feel free to replace all == -1 tests with < 0 tests as
On Fri, Oct 7, 2011 at 08:57, anatoly techtonik wrote:
>> It's just that SimpleHTTPServer doesn't quite survive slashdot effect.
>> Where do I fill a bug report :)
>
> http://bugs.python.org
http://www.theonion.com/
___
Python-Dev mailing list
Python-De
On Sun, Oct 2, 2011 at 3:17 PM, Maciej Fijalkowski wrote:
> On Sun, Oct 2, 2011 at 8:05 AM, Maciej Fijalkowski wrote:
>> On Sun, Oct 2, 2011 at 5:02 AM, anatoly techtonik
>> wrote:
>>> Hello,
>>>
>>> I've stumbled upon Dave Beazley's article [1] about trying ancient GIL
>>> removal patch at
>>>
> if (!PyUnicode_READY(foo)) is not better, also because of
PyUnicode_IS_READY(foo).
I prefer PyUnicode_IS_READY(foo) < 0 over PyUnicode_IS_READY(foo) == -1.
Ok, so feel free to replace all == -1 tests with < 0 tests as well.
I'll point out that the test for -1 is also widespread in Python,
Le 07/10/2011 03:19, Steven D'Aprano a écrit :
Given that strings are immutable, would it not be an obvious
optimization for replace to return the source string unchanged if the
old and new substrings are equal, and avoid making a potentially
expensive copy?
I just implemented this optimization
On Oct 3, 2011, at 6:12 AM, Lars Buitinck wrote:
> After some digging, I found out that Counter [2] does not
> have __iadd__ and += copies the entire left-hand side in __add__!
This seems like a reasonable change for Py3.3.
> I also figured out that I should use the update method instead, whi
Hello,
2011/10/7 Vinay Sajip :
> I work on Ubuntu Jaunty for my cpython development work - an old version, I
> know, but still quite serviceable and has worked well for me over many months.
> With the latest default cpython repository, however, I can't run the
> regression
> suite because the soc
> Is this a bug which doesn't show up on more recent Linux versions
Probably. AF_CAN was introduced in e767318baccd.
Cheers
Ross
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://m
On Oct 7, 2011, at 7:10 AM, Cameron Simpson wrote:
> The point here is security, not test coverage: if a procedure is known
> to be broken as a regular user, is it not highly unsafe to then run it
> as root?
No. As I mentioned previously, any environment where the tests are run should
be isolat
I work on Ubuntu Jaunty for my cpython development work - an old version, I
know, but still quite serviceable and has worked well for me over many months.
With the latest default cpython repository, however, I can't run the regression
suite because the socket module now fails to build:
gcc -pthrea
On 07Oct2011 06:50, Glyph wrote:
| On Oct 7, 2011, at 6:40 AM, Cameron Simpson wrote:
| > I think that the build and the tests should be different security
| > scopes/zones/levels: different users or different VMs. Andrew's
| > suggestion of a VM-for-tests sounds especially good.
|
| To me, "buil
On Oct 7, 2011, at 6:40 AM, Cameron Simpson wrote:
> I think that the build and the tests should be different security
> scopes/zones/levels: different users or different VMs. Andrew's
> suggestion of a VM-for-tests sounds especially good.
To me, "build" and "test" are largely the same function,
On 07Oct2011 06:18, Glyph wrote:
| On Oct 7, 2011, at 5:10 AM, Stephen J. Turnbull wrote:
|
| > The principle here is "ran as root" without further explanation is a
| > litmus test for "not bothering about security", even today. It's
| > worth asking for explanation, or at least a comment that "
On Oct 7, 2011, at 5:10 AM, Stephen J. Turnbull wrote:
> The principle here is "ran as root" without further explanation is a
> litmus test for "not bothering about security", even today. It's
> worth asking for explanation, or at least a comment that "all the
> buildbot contributors I've talked
Andrew Bennetts writes:
> No, that just means you shouldn't trust *root*. Which is where a
> VM is a very useful tool. You can have the “as root” environment
> for your tests without the need to have anything important trust it.
Cameron acknowledges that he missed that. So maybe he was righ
2011/10/6 Petri Lehtinen :
> Lars Buitinck wrote:
>> >>> from collections import Counter
>> >>> a = Counter([1,2,3])
>> >>> b = a
>> >>> a += Counter([3,4,5])
>> >>> a is b
>> False
>
> Sounds like a good idea to me. You should open an issue in the tracker
> at http://bugs.p
Le 07/10/2011 10:07, Stefan Krah a écrit :
Victor Stinner wrote:
Yes, I wrote if (PyUnicode_READY(foo)), but I agree that it is confusing
when you read the code, especially because we have also a
PyUnicode_IS_READY(foo) macro!
if (!PyUnicode_READY(foo)) is not better, also because of
PyUnicode
Victor Stinner wrote:
> Yes, I wrote if (PyUnicode_READY(foo)), but I agree that it is confusing
> when you read the code, especially because we have also a
> PyUnicode_IS_READY(foo) macro!
>
> if (!PyUnicode_READY(foo)) is not better, also because of
> PyUnicode_IS_READY(foo).
>
> I prefer
Le 07/10/2011 00:20, "Martin v. Löwis" a écrit :
Am 06.10.11 14:57, schrieb Amaury Forgeot d'Arc:
Hi,
with the new Unicode API, there are many checks like:
+ if (PyUnicode_READY(*filename))
+ goto handle_error;
I think you are misinterpreting what you are seeing.
There are not *many* such che
Hi,
On 07/10/2011 10.02, ezio.melotti wrote:
Author: ezio.melotti
Date: Fri Oct 7 09:02:07 2011
New Revision: 88904
Log:
#422: add keyword shortcuts to navigate through the messages and to reply.
I added keyboard shortcut to navigate through the messages in the
tracker (yes, keyboard, not ke
46 matches
Mail list logo
