-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
>> If you are only measuring json encoding of a few select pieces of
>> data then it's a microbenchmark. If you are measuring the whole
>> application (or a significant part of it) then I'm not sure
>> timeit is the right tool for that.
>>
>> Reg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/14/2011 1:23 AM, Martin (gzlist) wrote:
> On 07/04/2011, Michael Foord wrote:
>> On 07/04/2011 20:18, Robert Collins wrote:
>>>
>>> Testtools did something to address this problem, but I forget what it
>>> was offhand.
>
> Some issues were worke
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
> #. ``__version_info__`` SHOULD be of the format returned by PEP 386's
>``parse_version()`` function.
The only reference to parse_version in PEP 386 I could find was the
setuptools implementation which is pretty odd:
>
> In other words, pa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/23/2011 1:23 PM, Dirkjan Ochtman wrote:
> On Wed, Mar 23, 2011 at 12:39, John Arbash Meinel
> wrote:
>> Just as an aside, and I might be wrong. But reading through what strip
>> does, (and from my knowledge of the disk layout)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/22/2011 11:05 PM, Barry Warsaw wrote:
> On Mar 23, 2011, at 07:31 AM, Nick Coghlan wrote:
>
>> On Wed, Mar 23, 2011 at 4:25 AM, Barry Warsaw wrote:
>>> It probably wouldn't be a bad idea to add a very fast "smoke test" for the
>>> case where you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/23/2011 4:30 AM, Stephen J. Turnbull wrote:
> Antoine Pitrou writes:
>
> > Now, "hg strip" should definitely be absent of any recommended or even
> > suggested workflow. It's a power user tool for the experimented
> > developer/admin. Not the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/22/2011 3:25 PM, Barry Warsaw wrote:
> On Mar 22, 2011, at 12:52 AM, Éric Araujo wrote:
>
>> Bazaar apparently has a notion of mainline whereas Mercurial believes
>> that all changesets are created equal. The tools are different.
>
> I'm curiou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/22/2011 3:22 PM, Barry Warsaw wrote:
> On Mar 22, 2011, at 12:07 PM, Adrian Buehlmann wrote:
>
>> FWIW, Mercurial's "mainline" is the branch with the name 'default'. This
>> branch name is reserved, and it implies that the head with the highest
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/21/2011 9:19 PM, Barry Warsaw wrote:
> On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
>
>> Keeping the repository clean makes it easier to use a bisection search to
>> hunt down the introduction of a bug. If every developer's intermediat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/21/2011 6:53 PM, Barry Warsaw wrote:
> On Mar 21, 2011, at 01:19 PM, R. David Murray wrote:
>
>> So you are worried about the small window between me doing an 'svn up',
>> seeing no changes, and doing an 'svn ci'? I suppose that is a legitimate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/21/2011 10:32 PM, Nick Coghlan wrote:
> On Tue, Mar 22, 2011 at 3:16 AM, Raymond Hettinger
> wrote:
>> I don't think that is the main source of complexity.
>> The more difficult and fragile part of the workflows are:
>> * requiring commits to be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/22/2011 2:05 AM, Terry Reedy wrote:
> On 3/21/2011 7:14 AM, Nick Coghlan wrote:
>
>> hg broadens the check and complains if *any* files are not up to date
>> on any of the branches being pushed, thus making it a requirement to
>> do a hg pull and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/21/2011 10:48 PM, "Martin v. Löwis" wrote:
>> It does so at the *tree* level, not at an individual file level.
>
> Thanks - I stand corrected. I was thinking about the file level only (at
> which it doesn't do server-side merging - right?).
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/21/2011 10:44 AM, "Martin v. Löwis" wrote:
>> My understanding is that svn does not detect fast forwards, only lack
>> of conflicts, and therefore in case of concurrent development it is
>> possible that the repository contains a version that neve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/20/2011 5:06 AM, R. David Murray wrote:
> On Thu, 17 Mar 2011 14:33:00 +0100, wrote:
>> On Thu, 17 Mar 2011 09:24:26 -0400
>> "R. David Murray" wrote:
>>>
>>> It would be great if rebase did work with share, that would make a
>>> push race basic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
> I have always felt uncomfortable with *any* kind of optimization --
> whether AST-based or bytecode-based. I feel the cost in code
> complexity is pretty high and in most cases the optimization is not
> worth the effort. Also I don't see the po
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/7/2011 3:56 AM, Terry Reedy wrote:
> On 3/6/2011 6:09 PM, Barry Scott wrote:
>> I see that PyCObject_AsVoidPtr has been removed from python 3.2.
>> The 3.2 docs do not seem to explain this has happened and what
>> to replace it with.
>>
>> I searc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/22/2011 9:41 AM, anatoly techtonik wrote:
> On Fri, Feb 18, 2011 at 4:00 PM, Dirkjan Ochtman wrote:
>> On Fri, Feb 18, 2011 at 14:41, anatoly techtonik wrote:
>>> Do you have a public list of stuff to be done (i.e. Roadmap)?
>>> BTW, what is the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/15/2011 8:03 AM, Benjamin Peterson wrote:
> 2011/2/15 Victor Stinner :
>> Le mardi 15 février 2011 à 09:30 +0100, "Martin v. Löwis" a écrit :
>>> I'm going to perform a Debian upgrade of svn.python.org on Friday,
>>> between 9:00 UTC and 11:00 UTC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/19/2010 7:50 AM, Nick Coghlan wrote:
> On Fri, Nov 19, 2010 at 5:43 PM, Georg Brandl wrote:
>> Am 19.11.2010 03:23, schrieb Benjamin Peterson:
>>> 2010/11/18 Jesus Cea :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18/11/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...
> * that said, Windows seems much slower than Linux on equivalent
>hardware, perhaps attempting to open files is intrinsically more
>expensive there? Certainly it's not safe to assume conclusions drawn
>on Linux will apply equally we
I'm trying to determine if this is intended behavior:
>>> r"\""
'\\"'
>>> r'\''
"\\'"
Normally, the quote would end the string, but it gets escaped by the
preceding '\'. However, the preceding slash is interpreted as 'not a
backslash' because of the raw indicator, so it gets left in verbatim.
N
Scott Dial wrote:
> On 6/30/2010 2:53 PM, Barry Warsaw wrote:
>> It might be amazing, but it's still a significant overhead. As I've
>> described, multiply that by all the py files in all the distro packages
>> containing Python source code, and then still try to fit it on a CDROM.
>
> I decided
...
>> IOW, if you're producing output that has to go into another system
>> that doesn't take unicode, it doesn't matter how
>> theoretically-correct it would be for your app to process the data in
>> unicode form. In that case, unicode is not a feature: it's a bug.
>>
> This is not always true.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Quinlan wrote:
> The PEP is here:
> http://www.python.org/dev/peps/pep-3148/
>
> I think the PEP is ready for pronouncement, and the code is pretty much
> ready for submission into py3k (I will have to make some minor changes
> in the patch like
Brian Quinlan wrote:
> The PEP is here:
> http://www.python.org/dev/peps/pep-3148/
>
> I think the PEP is ready for pronouncement, and the code is pretty much
> ready for submission into py3k (I will have to make some minor changes
> in the patch like changing the copyright assignment):
> http://c
Giampaolo Rodolà wrote:
class A:
> ... def echo(self, x):
> ... return x
> ...
a = A()
a.echo()
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: echo() takes exactly 2 arguments (1 given)
>
> I bet my last 2 cents this has already been raise
Stephen J. Turnbull wrote:
> David Abrahams writes:
> >
> > This is a bug report. bugs.python.org seems to be down.
> >
> > >>> from urlparse import *
> > >>> urlunsplit(urlsplit('git+file:///foo/bar/baz'))
> > git+file:/foo/bar/baz
> >
> > Note the dropped slashes after the colon
> Right now the Python programmer looking to aggressively delete elements from
> the top of a list has to consider the tradeoff that the operation takes O(N)
> time and would possibly churn his memory caches with the O(N) memmove
> operation. In some cases, the Python programmer would only hav
Collin Winter wrote:
> Hey Jake,
>
...
>> Hmm. So cProfile doesn't break, but it causes code to run under a
>> completely different execution model so the numbers it produces are
>> not connected to reality?
>>
>> We've found the call graph and associated execution time information
>> from cProf
sstein...@gmail.com wrote:
> On Jan 21, 2010, at 11:32 PM, Chris Bergstresser wrote:
>
>> On Thu, Jan 21, 2010 at 9:49 PM, Tres Seaver wrote:
>> Generally, that's not going to be the case. But the broader
>> point--that you've no longer got an especially good idea of what's
>> taking time to r
Martin v. Löwis wrote:
>> There is "freeze":
>> http://wiki.python.org/moin/Freeze
>>
>> Which IIRC Robert Collins tried in the past, but didn't see a huge gain.
>> It at least tries to compile all of your python files to C files and
>> then build an executable out of that.
>
> "to C files" is a b
Collin Winter wrote:
> Hi Dirkjan,
>
> On Wed, Jan 20, 2010 at 10:55 PM, Dirkjan Ochtman wrote:
>> On Thu, Jan 21, 2010 at 02:56, Collin Winter wrote:
>>> Agreed. We are actively working to improve the startup time penalty.
>>> We're interested in getting guidance from the CPython community as t
MRAB wrote:
> Hi,
>
> I've been wondering whether it's possible to release the GIL in the
> regex engine during matching.
>
> I know that it needs to have the GIL during memory-management calls, but
> does it for calls like Py_UNICODE_TOLOWER or PyErr_SetString? Is there
> an easy way to find out
Roy Hyunjin Han wrote:
> While debugging a network algorithm in Python 2.6.2, I encountered
> some strange behavior and was wondering whether it has to do with some
> sort of code optimization that Python does behind the scenes.
>
>
>
> After initialization: defaultdict(, {1: set([1]
...
> A moratorium isn't cost-free. With the back-end free to change, patches
> will go stale over 2+ years. People will lose interest or otherwise
> move on. Those with good ideas but little patience will be discouraged.
> I fully expect that, human nature being as it is, those proposing a
>
geremy condra wrote:
> On Thu, Nov 5, 2009 at 4:09 PM, Alexander Belopolsky
> wrote:
>> On Thu, Nov 5, 2009 at 3:43 PM, Chris Bergstresser
>> wrote:
>>> .. and "x = iter(s).next()" raises a StopIteration
>>> exception.
>> And that's why the documented recipe should probably recommend
>> next(ite
Sturla Molden wrote:
> Antoine Pitrou skrev:
>> It certainly is.
>> But once again, I'm no Windows developer and I don't have a native
>> Windost host
>> to test on; therefore someone else (you?) has to try.
>>
> I'd love to try, but I don't have VC++ to build Python, I use GCC on
> Windows.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin v. Löwis wrote:
>> Hmm, perhaps when using sets as work queues?
>
> A number of comments:
>
> - it's somewhat confusing to use a set as a *queue*, given
> that it won't provide FIFO semantics.
> - there are more appropriate and direct contai
Adam Olsen wrote:
> On Fri, Oct 23, 2009 at 11:04, Vitor Bosshard wrote:
>> I see this as being useful for frozensets as well, where you can't get
>> an arbitrary element easily due to the obvious lack of .pop(). I ran
>> into this recently, when I had a frozenset that I knew had 1 element
>> (it
Terry Reedy wrote:
> John Arbash Meinel wrote:
>> So 'for x in s: break' is about 2x faster than next(iter(s)) and 3x
>> faster than (iter(s).next()).
>> I was pretty surprised that it was 30% faster than "for x in s: pass". I
>> assume it has som
Vitor Bosshard wrote:
> 2009/10/23 Willi Richert :
>> Hi,
>>
>> recently I wrote an algorithm, in which very often I had to get an arbitrary
>> element from a set without removing it.
>>
>> Three possibilities came to mind:
>>
>> 1.
>> x = some_set.pop()
>> some_set.add(x)
>>
>> 2.
>> for x in some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Antoine Pitrou wrote:
> Le mercredi 21 octobre 2009 à 12:42 -0500, John Arbash Meinel a écrit :
>> You can use time.clock() instead to get <15ms resolution. Changing all
>> instances of 'time.time' to 'time.clo
Antoine Pitrou wrote:
> Sturla Molden molden.no> writes:
>> It does not crash the interpreter, but it seems it can deadlock.
>
> Kristján sent me a patch which I applied and is supposed to fix this.
> Anyway, thanks for the numbers. The GIL does seem to fare a bit better (zero
> latency with the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kristján Valur Jónsson wrote:
...
> This depends entirely on the platform and primitives used to implement the
> GIL.
> I'm interested in windows. There, I found this article:
> http://fonp.blogspot.com/2007/10/fairness-in-win32-lock-objects.html
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Antoine Pitrou wrote:
>> I don't really know how this test works, so I won't claim to understand
>> the results either. However, here you go:
>
> Thanks.
>
> Interesting results. I wonder what they would be like on a multi-core
> machine. The GIL see
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Withers wrote:
> Michael Foord wrote:
>> D'oh. For 2.5 I mean. It may be *possible* though - just as you *can*
>> build extensions for Python 2.5 on windows with mingw (with the
>> appropriate distutils configuration), but there are pitfalls with
Mark Hammond wrote:
> On 5/08/2009 8:14 PM, Dirkjan Ochtman wrote:
>> endings. Typically, in my case, that was either Notepad2 (an awesomely
>> light-weight Notepad replacement) or Komodo (Edit). That solved all of
>> my issues, so I haven't had a need for win32text so far.
>
> FWIW, I use komodo
Andrew Bennetts wrote:
> Antoine Pitrou wrote:
>> Robert Kern gmail.com> writes:
>>> Since one may have more than one filesystem side-by-side, this can't be just
>> be
>>> a system-wide boolean somewhere. One would have to query the target
>>> directory
>>> for this information. I am not aware
...
>> Somewhat true, though I know it happens 25k times during startup of
>> bzr... And I would be a *lot* happier if startup time was 100ms instead
>> of 400ms.
>
> I don't want to quash your idealism too severely, but it is extremely
> unlikely that you are going to get anywhere near that kind
Greg Ewing wrote:
> John Arbash Meinel wrote:
>> And the way intern is currently
>> written, there is a third cost when the item doesn't exist yet, which is
>> another lookup to insert the object.
>
> That's even rarer still, since it only happens the first
Martin v. Löwis wrote:
>> I don't have numbers on how much that would improve CPU times, I would
>> imagine improving 'intern()' would impact import times more than run
>> times, simply because import time is interning a *lot* of strings.
>>
>> Though honestly, Bazaar would really like this, becaus
...
> I like your rationale (save memory) much more, and was asking in the
> tracker for specific numbers, which weren't forthcoming.
>
...
> Now that you brought up a specific numbers, I tried to verify them,
> and found them correct (although a bit unfortunate), please see my
> test script b
Alexander Belopolsky wrote:
> On Thu, Apr 9, 2009 at 11:02 AM, John Arbash Meinel
> wrote:
> ...
>> a) Don't keep a double reference to both key and value to the same
>> object (1 pointer per entry), this could be as simple as using a
>> Set() instea
Christian Heimes wrote:
> John Arbash Meinel wrote:
>> When I looked at the actual references from interned, I saw mostly
>> variable names. Considering that every variable goes through the python
>> intern dict. And when you look at the intern function, it doesn't u
...
>> Anyway, I the internals of intern() could be done a bit better. Here are
>> some concrete things:
>>
>
> [snip]
>
> Memory usage is definitely something we're interested in improving.
> Since you've already looked at this in some detail, could you try
> implementing one or two of your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been doing some memory profiling of my application, and I've found
some interesting results with how intern() works. I was pretty surprised
to see that the "interned" dict was actually consuming a significant
amount of total memory.
To give the sp
57 matches
Mail list logo
