Alexander Belopolsky wrote:
> Odd indeed. My first reaction was: it is not needed because lists
> support slicing, but when I tried to construct a list.get() using
> slicing the best I could come up with was the following hack
>
def lget(l, i, v): return (l[i:] or [v])[0]
> ...
lget(ra
Guido van Rossum wrote:
> My gut tells me it is bad API design to collapse these two use cases.
> Probably because the implementations won't have much in common: (1)
> should just pick the first valid element, while (2) should use the
> normal hash lookup algorithm (shared with 'in', .add() etc.).
2009/10/22 "Martin v. Löwis" :
> What use has such a stepping stone? Why, and (more importantly) when
> would anybody currently supporting 2.x give up 2.6 and earlier, and
> only support 2.7? And, if they chose to do so, why would they not move
> the code base to 3.x right away?
Python 2 support i
On Thu, 22 Oct 2009 10:20:03 + (UTC), Antoine Pitrou
wrote:
> (*) Remember, however, that Tarek and work on Distribute, and also on
> bringing pieces of setuptools/Distribute functionality into distutils.
But if that's the case then why not work on any third party tool..? like
pip or setupto
On Tue, Oct 27, 2009 at 3:49 PM, Raymond Hettinger wrote:
>
> [geremy condra]
>>
>> Was it ever decided whether this would fall under the moratorium?
>
> Decided isn't the right word:
> http://mail.python.org/pipermail/python-dev/2009-October/093373.html
>
I'm unclear- does that imply that this
On Oct 27, 2009, at 11:02 PM, Terry Reedy wrote:
sstein...@gmail.com wrote:
This topic needs its own flippin' newsgroup.
You could have said just that, appropriate or not, without dumping
on anyone in particular.
I was not trying to dump on you in particular, I picked a random
message
sstein...@gmail.com wrote:
On Oct 27, 2009, at 2:50 PM, Terry Reedy wrote more and more and more
and more and more and more and more and more and more:
Actually, I wrote 7 succinct lines that summarized and made a proposal.
In general, I snip when quoting and write concisely as possible.
Th
Hello,
Since the addition of PEP 370, (per-user site packages), site.py and
distutils/command/install.py are *both* providing the various
installation directories for Python,
depending on the system and the Python version.
We have also started to discuss lately in various Mailing Lists the
additi
[geremy condra]
Was it ever decided whether this would fall under the moratorium?
Decided isn't the right word:
http://mail.python.org/pipermail/python-dev/2009-October/093373.html
FWIW, I'm a strong -1 on both proposals.
Just add a short get_one() function and a get_equivalent() recipe
to y
On Tue, Oct 27, 2009 at 3:13 PM, Guido van Rossum wrote:
> On Tue, Oct 27, 2009 at 11:50 AM, Terry Reedy wrote:
>> There are two ideas of set.get floating about:
>> 1) get an arbitrary object
>> 2) get the object in the set with the same 'value'(hash+eq) as an input arg
>> (the intern case). In t
On Tue, Oct 27, 2009 at 11:50 AM, Terry Reedy wrote:
> There are two ideas of set.get floating about:
> 1) get an arbitrary object
> 2) get the object in the set with the same 'value'(hash+eq) as an input arg
> (the intern case). In this case, there is a 'key', even if it is somewhat
> abstract ra
On Tue, Oct 27, 2009 at 3:06 PM, sstein...@gmail.com
wrote:
>
> On Oct 27, 2009, at 2:50 PM, Terry Reedy wrote more and more and more and
> more and more and more and more and more and more:
>
> This topic needs its own flippin' newsgroup.
>
> S
Don't like it? Mute the conversation (thank you gma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
> On behalf of the Python community, I'm happy to announce the
> availability of Python 2.6.4. This is the latest production-ready
> version in the Python 2.6 series.
>
> We had a little trouble with the Python 2.6.3 release;
On Oct 27, 2009, at 2:50 PM, Terry Reedy wrote more and more and more
and more and more and more and more and more and more:
This topic needs its own flippin' newsgroup.
S
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
On Tue, Oct 27, 2009 at 12:47 PM, Raymond Hettinger wrote:
> [Chris Bergstresser]
> Still, I think my
>>
>> point stands--it's a clear extrapolation from the existing dict.get().
>
> Not really. One looks-up a key and supplies a default value if not found.
> The other, set.get(), doesn't have a
Raymond Hettinger wrote:
A dict.get() can be meaningfully used in a loop (because the key can vary).
A set.get() returns the same value over and over again (because there is
no key).
There are two ideas of set.get floating about:
1) get an arbitrary object
2) get the object in the set with th
On Tue, Oct 27, 2009 at 02:20:04PM -0400, geremy condra wrote:
> On Tue, Oct 27, 2009 at 1:59 PM, Antoine Pitrou wrote:
> > Raymond Hettinger rcn.com> writes:
> > set.getone() then ?
>
> ugh- other spellings much preferred.
set[] ? (Just kidding, really.)
Oleg.
--
Oleg Broytman
On Tue, Oct 27, 2009 at 1:59 PM, Antoine Pitrou wrote:
> Raymond Hettinger rcn.com> writes:
>>
>> [Chris Bergstresser]
>> Still, I think my
>> > point stands--it's a clear extrapolation from the existing dict.get().
>>
>> Not really. One looks-up a key and supplies a default value if not found
Raymond Hettinger rcn.com> writes:
>
> [Chris Bergstresser]
> Still, I think my
> > point stands--it's a clear extrapolation from the existing dict.get().
>
> Not really. One looks-up a key and supplies a default value if not found.
> The other, set.get(), doesn't have a key to lookup.
set.g
On Tue, Oct 27, 2009 at 1:33 PM, Chris Bergstresser wrote:
> On Tue, Oct 27, 2009 at 11:06 AM, Georg Brandl wrote:
>> Sorry to nitpick, but there is no list.get().
>
> No? How ... odd.
Odd indeed. My first reaction was: it is not needed because lists
support slicing, but when I tried to cons
[Chris Bergstresser]
Still, I think my
point stands--it's a clear extrapolation from the existing dict.get().
Not really. One looks-up a key and supplies a default value if not found.
The other, set.get(), doesn't have a key to lookup.
A dict.get() can be meaningfully used in a loop (becaus
Chris Bergstresser schrieb:
> On Tue, Oct 27, 2009 at 11:06 AM, Georg Brandl wrote:
>> Sorry to nitpick, but there is no list.get().
>
>No? How ... odd. I guess it wouldn't have come up, but I was sure
> there was a .get method which took an optional default parameter if
> the index didn't
On Tue, Oct 27, 2009 at 11:06 AM, Georg Brandl wrote:
> Sorry to nitpick, but there is no list.get().
No? How ... odd. I guess it wouldn't have come up, but I was sure
there was a .get method which took an optional default parameter if
the index didn't exist, mirroring the dict method. Stil
Chris Bergstresser schrieb:
>I like the proposed set.get() method, personally. list.get(index)
> gets the item at that index, dict.get(key) gets the item associated
> with that key, set.get() gets an item, but doesn't place any
> guarantees on which item is returned.
Sorry to nitpick, but th
Right, how do developers benefit from a buildbot?
>From my experience (five large buildbots with many developers plus two
with only a couple of developers), a buildbot does little good unless
the tests are reliable and not too noisy. "Reliable" is best achieved
by having tests be deterministic an
Martin v. Löwis v.loewis.de> writes:
>
> It's not really reproducible. I think it sometimes happens when I
> restart the master; sometimes, some clients fail to reconnect
> (properly).
Another common problem is that some buildbot fails in the middle of the test
suite, with the following kind of
26 matches
Mail list logo
