On Wed, Oct 27, 2010 at 03:42, Antoine Pitrou wrote:
> On Tue, 26 Oct 2010 22:06:37 -0400
> Alexander Belopolsky wrote:
>>
>> While I appreciate your and Michael's eloquence, I don't really see
>> why five 400-line modules are necessarily easier to maintain than one
>> 2000-line module. Splittin
On Mon, Nov 01, 2010 at 02:37:33PM -0400, Terry Reedy wrote:
> On 10/31/2010 10:55 PM, Michael Foord wrote:
>
>> fact that sets / frozensets can't be sorted in the standard Python way
>> (their less than comparison adheres to the set definition). This is
>> something that will probably surprise man
On 10/31/2010 10:55 PM, Michael Foord wrote:
fact that sets / frozensets can't be sorted in the standard Python way
(their less than comparison adheres to the set definition). This is
something that will probably surprise many Python developers:
Any programmer who sorts (or uses functions that
Olemis Lang gmail.com> writes:
>
> > For some people, use of {} over % is more about personal taste than about
> > the
> > actual usage of str.format's flexibility;
>
> Thought you were talking about me, you only needed to say «he has
> black hair and blue eyes» ... ;o)
>
No, it was a genera
2010/11/1 Kristján Valur Jónsson :
> I've been sitting on the sideline seeing this unfold.
> We've seen some different viewpoints on the matter and I'm happy to see that
> I'm not the only one lamenting the proclaimed death of the 2.x linage.
> However, As correctly stated by Martin, I merely voic
On Tue, Nov 2, 2010 at 2:26 AM, Michael Foord wrote:
> On 01/11/2010 16:23, Nick Coghlan wrote:
>> Looking at assertItemsEqual, I'd be inclined to insert a check that
>> falls back to the "unorderable_list_difference" approach in the case
>> where "expected != sorted(reversed(expected))"
>
> If th
On Tue, Nov 2, 2010 at 2:10 AM, Hirokazu Yamamoto
wrote:
> Does this really cause resource warning? I think os.popen instance
> won't be into traceback because it's not declared as variable. So I
> suppose it will be deleted by reference count == 0 even when exception
> occurs.
Any time __del__ h
On 01/11/2010 16:23, Nick Coghlan wrote:
On Tue, Nov 2, 2010 at 1:33 AM, R. David Murray wrote:
Or, to put it another way, *if* there is a bug here it would be in set,
not sorted.
Put me in the "it's not a bug, it's a feature" camp. Providing a
"elements equal" check that doesn't rely on LT pr
On Tue, Nov 2, 2010 at 1:33 AM, R. David Murray wrote:
> Or, to put it another way, *if* there is a bug here it would be in set,
> not sorted.
Put me in the "it's not a bug, it's a feature" camp. Providing a
"elements equal" check that doesn't rely on LT providing a total
ordering is a non-trivia
On 2010/10/31 6:24, brian.curtin wrote:
Author: brian.curtin
Date: Sat Oct 30 23:24:21 2010
New Revision: 85987
Log:
Fix #10257. Clear resource warnings by using os.popen's context manager.
Modified:
python/branches/py3k/Lib/test/test_os.py
Modified: python/branches/py3k/Lib/test/test_os.
On Mon, 01 Nov 2010 15:14:36 -, Michael Foord
wrote:
> On 01/11/2010 15:10, R. David Murray wrote:
> > On Mon, 01 Nov 2010 14:26:19 -, Michael
> > Foord wrote:
> >> Well, bug is the wrong word as it is obviously an intended feature (or
> >> consequence of a feature). I still think, give
On Mon, Nov 01, 2010 at 02:55:25PM +, Steven Bethard wrote:
> On Mon, Nov 1, 2010 at 2:53 PM, Michael Foord
> wrote:
> > Isn't it better to add the missing elements - what is the problem with that
> > approach?
>
> It just requires extra synchronization, and history shows that I
> always for
On 2010/10/31 2:32, M.-A. Lemburg wrote:
M.-A. Lemburg wrote:
Hirokazu Yamamoto wrote:
Hello. I found several codes using PyMem_Free to free
allocated memory with PyMem_MALLOC (ie: PyUnicode_AsWideCharString)
Is it safe?
Within the interpreter: yes.
In extensions: depends on the platform, b
On 01/11/2010 15:10, R. David Murray wrote:
On Mon, 01 Nov 2010 14:26:19 -, Michael Foord
wrote:
On 01/11/2010 11:33, Antoine Pitrou wrote:
On Mon, 01 Nov 2010 02:55:35 +
Michael Foord wrote:
Having a more efficient 'slow-path' and moving to that by default would
fix it. The bug is
On Mon, 01 Nov 2010 14:26:19 -, Michael Foord
wrote:
> On 01/11/2010 11:33, Antoine Pitrou wrote:
> > On Mon, 01 Nov 2010 02:55:35 +
> > Michael Foord wrote:
> >> Having a more efficient 'slow-path' and moving to that by default would
> >> fix it. The bug is only a duplicate of the bug i
Ok, please see http://bugs.python.org/issue10278
K
From: Michael Foord [mailto:fuzzy...@voidspace.org.uk]
Sent: 1. nóvember 2010 22:05
To: Kristján Valur Jónsson
Cc: python-dev@python.org
Subject: Re: [Python-Dev] time.wallclock()
I think this would be helpful. Having to do platform specific che
On Tue, Nov 2, 2010 at 12:57 AM, Guido van Rossum wrote:
> It is also possible to write automated tests that flag likely missing
> symbols in __all__ (as well as symbols in __all__ missing from the
> module).
These days, test___all__ checks that everything in __all__ exists in
standard library mo
On 01/11/2010 14:57, Guido van Rossum wrote:
[snip...]
Not defining __all__ will mean that "from argparse import *" will also
export all the modules you import (copy, os, re, sys, textwrap).
Well, the copy of argparse.py that I have carefully renames those to
_copy, _os etc. to avoid this.
Ba
On Mon, Nov 1, 2010 at 2:57 PM, Guido van Rossum wrote:
> On Mon, Nov 1, 2010 at 7:53 AM, Michael Foord
> wrote:
>> On 01/11/2010 14:48, Steven Bethard wrote:
>>> But then I wonder - is __all__ considered part of the public API of a
>>> module? Or is it okay to just remove it and assume that no
On Mon, Nov 1, 2010 at 7:53 AM, Michael Foord wrote:
> On 01/11/2010 14:48, Steven Bethard wrote:
>>
>> I think the easiest and most sensible way to address
>> http://bugs.python.org/issue9353 is to simply remove the __all__
>> definition from argparse - everything that doesn't start with an
>> un
On Mon, Nov 1, 2010 at 2:53 PM, Michael Foord wrote:
> On 01/11/2010 14:48, Steven Bethard wrote:
>>
>> I think the easiest and most sensible way to address
>> http://bugs.python.org/issue9353 is to simply remove the __all__
>> definition from argparse - everything that doesn't start with an
>> un
On 01/11/2010 14:48, Steven Bethard wrote:
I think the easiest and most sensible way to address
http://bugs.python.org/issue9353 is to simply remove the __all__
definition from argparse - everything that doesn't start with an
underscore in the module is already meant to be exposed.
But then I wo
I think the easiest and most sensible way to address
http://bugs.python.org/issue9353 is to simply remove the __all__
definition from argparse - everything that doesn't start with an
underscore in the module is already meant to be exposed.
But then I wonder - is __all__ considered part of the publ
On 01/11/2010 11:33, Antoine Pitrou wrote:
On Mon, 01 Nov 2010 02:55:35 +
Michael Foord wrote:
Having a more efficient 'slow-path' and moving to that by default would
fix it. The bug is only a duplicate of the bug in sorted - caused by the
fact that sets / frozensets can't be sorted in the
On 01/11/2010 14:00, Kristján Valur Jónsson wrote:
Working on Condition variables and semaphores (see
http://bugs.python.org/issue10260) I noticed that time.time() was
being used to correctly time blocking system calls. On windows, I
would have used time.clock() but reading the documentation
On Sun, Oct 31, 2010 at 9:55 AM, Vinay Sajip wrote:
> Olemis Lang gmail.com> writes:
>>
>> On Fri, Oct 29, 2010 at 10:07 AM, Barry Warsaw python.org> wrote:
>> > I haven't played with it yet, but do you think it makes sense to add a
>> > 'style' keyword argument to basicConfig()? That would mak
Working on Condition variables and semaphores (see
http://bugs.python.org/issue10260) I noticed that time.time() was being used to
correctly time blocking system calls. On windows, I would have used
time.clock() but reading the documentation made me realize that on Unix that
would return CPU s
I've been sitting on the sideline seeing this unfold.
We've seen some different viewpoints on the matter and I'm happy to see that
I'm not the only one lamenting the proclaimed death of the 2.x linage.
However, As correctly stated by Martin, I merely voiced a suggestion and I have
gotten helpful
On Mon, 01 Nov 2010 12:33:31 +0100, Antoine Pitrou wrote:
> On Mon, 01 Nov 2010 02:55:35 +
> Michael Foord wrote:
> > Having a more efficient 'slow-path' and moving to that by default would
> > fix it. The bug is only a duplicate of the bug in sorted - caused by the
> > fact that sets / fro
On Mon, 01 Nov 2010 02:55:35 +
Michael Foord wrote:
> Having a more efficient 'slow-path' and moving to that by default would
> fix it. The bug is only a duplicate of the bug in sorted - caused by the
> fact that sets / frozensets can't be sorted in the standard Python way
> (their less tha
2010/11/1 Kristján Valur Jónsson :
> Ah, yes. There are, in my case. (why do I always seem to be doing stuff
> that is different from what you all are doing:)
I would guess that most of us aren't writing MMOs for a living. Gamers
seem to be a particularly demanding breed of user :)
Cheers,
Nic
On Mon, Nov 1, 2010 at 10:53 AM, Barry Warsaw wrote:
> On Oct 31, 2010, at 04:39 PM, Eric Smith wrote:
>
>>What are your thoughts on adding a str.format_from_mapping (or similar
>>name, maybe the suggested "format_map") to 3.2?
>
> +1 for the shorter name.
+1 for a format_map() method that takes
Ah, yes. There are, in my case. (why do I always seem to be doing stuff that
is different from what you all are doing:)
The particular piece of code is from the chunked reader. It may be reading
rather large chunks at a time (several lots of Kb.):
def recvchunk(socket):
len = socket.unpack
Stefan Behnel, 01.11.2010 09:45:
If slice object creation bothers you here, it might be worth using a
free list in PySlice_New() instead of creating new slice objects on
request.
[...]
You can take a look at how it's done in tupleoject.c if you want to
provide a patch.
Hmm, that's actually a pa
I've already created a patch. See http://bugs.python.org/issue10227.
I was working with 2.7 where slicing sequences is done differently than in 3.2,
so the difference is not that very great.
I'm going to have another go at profiling the 3.2 version later and see why
slicing a bytearray is so muc
Kristján Valur Jónsson, 27.10.2010 16:28:
Notice how a Slice object is generated. Then a PyObject_GetItem() is
done. The salient code path is from apply_slice(). A slice object must
be constructed and destroyed.
If slice object creation bothers you here, it might be worth using a free
list
Kristján Valur Jónsson, 27.10.2010 16:32:
Sorry, here the tables properly formatted:
Certainly looked better on your first try.
Stefan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
37 matches
Mail list logo