"Michael Hoffman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Another nice thing about having a next() built-in is that it makes
> getting the first item of a generator expression a lot more elegant,
> I think this:
> next(item for item in items if item > 3)
> is a lot clearer t
Guido van Rossum wrote:
> On 3/6/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> [Neil Schemenauer]
>>> I occasionally need dictionaries or sets that use object identity
>>> rather than __hash__ to store items. Would it be appropriate to add
>>> these to the collections module?
>> Why not deco
Alex Martelli wrote:
> On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
> ...
> > I think that adding parentheses would help, by at least signalling
> > that the logic is longer than just the next (single) expression.
> >
> > level = (0 if "absolute_import" in self.futures else -1)
>
> +1 (ju
see subject and http://python.org/sf/1368955
comments ?
(note sure how my previous attempt to post this ended up on
comp.lang.python instead, but I'll blame it on gmane... ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
On 3/6/06, Michael Hoffman <[EMAIL PROTECTED]> wrote:
> Another nice thing about having a next() built-in is that it makes
> getting the first item of a generator expression a lot more elegant,
> IMHO.
>
> I think this:
>
> next(item for item in items if item > 3)
>
> is a lot clearer than this:
>
[Jim Jewett]
>>> I think that adding parentheses would help, by at least signalling that
>>> the logic is longer than just the next (single) expression.
>>>
>>> level = (0 if "absolute_import" in self.futures else -1)
[Steve Holden]
>> Contrast with the bleeding obvious:
>>
>> level = 0
>>
"Steve Holden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Jim Jewett wrote:
>> I think that adding parentheses would help, by at least signalling that
>> the logic is longer than just the next (single) expression.
>>
>> level = (0 if "absolute_import" in self.futures else -
On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
...
> I think that adding parentheses would help, by at least signalling
> that the logic is longer than just the next (single) expression.
>
> level = (0 if "absolute_import" in self.futures else -1)
+1 (just because I can't give it +3.1415
On Mar 6, 2006, at 10:17 AM, Tim Peters wrote:
...
> How's everyone doing, BTW?
Swimmingly, thanks! Too busy to breathe, or come to pycon:-(, but,
happy as a lark.
> I think I picked up the Texas Mystery
> Disease from Holger Krekel -- bed-ridden 20 hours Saturday, and most
> of Sunday, w
Another nice thing about having a next() built-in is that it makes
getting the first item of a generator expression a lot more elegant,
IMHO.
I think this:
next(item for item in items if item > 3)
is a lot clearer than this:
(item for item in items if item > 3).next()
or alternatives that woul
On Mar 6, 2006, at 4:43 PM, Bob Ippolito wrote:
>
> On Mar 6, 2006, at 4:14 PM, Guido van Rossum wrote:
...
>> I wonder if this use case and the frequently requested
>> case-insensitive dict don't have some kind of generalization in
>> common
>> -- perhaps a dict that takes a key function a
On Mar 6, 2006, at 4:14 PM, Guido van Rossum wrote:
> On 3/6/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> [Neil Schemenauer]
>>> I occasionally need dictionaries or sets that use object identity
>>> rather than __hash__ to store items. Would it be appropriate to add
>>> these to the colle
On Mon, Mar 06, 2006, Guido van Rossum wrote:
> On 3/6/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > [Neil Schemenauer]
> > >I occasionally need dictionaries or sets that use object identity
> > > rather than __hash__ to store items. Would it be appropriate to add
> > > these to the collect
On 3/6/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Neil Schemenauer]
> >I occasionally need dictionaries or sets that use object identity
> > rather than __hash__ to store items. Would it be appropriate to add
> > these to the collections module?
>
> Why not decorate the objects with a cla
[Neil Schemenauer]
>I occasionally need dictionaries or sets that use object identity
> rather than __hash__ to store items. Would it be appropriate to add
> these to the collections module?
Why not decorate the objects with a class adding a method:
def __hash__(self):
return id(self)
On Mon, 2006-03-06 at 23:30 +, Neil Schemenauer wrote:
> Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > There are two patches on SF to add a couple of features to the gc
> > module. Skip wrote one (which I reviewed) and I wrote the other.
> > Neither is earth shattering, but they're helpful when
Barry Warsaw <[EMAIL PROTECTED]> wrote:
> There are two patches on SF to add a couple of features to the gc
> module. Skip wrote one (which I reviewed) and I wrote the other.
> Neither is earth shattering, but they're helpful when debugging gc
> issues.
I have no major objections to either patch.
There are two patches on SF to add a couple of features to the gc
module. Skip wrote one (which I reviewed) and I wrote the other.
Neither is earth shattering, but they're helpful when debugging gc
issues.
Skips adds some timing output when DEBUG_STATS is set:
https://sourceforge.net/tracker/ind
On 3/6/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> I occasionally need dictionaries or sets that use object identity
> rather than __hash__ to store items. Would it be appropriate to add
> these to the collections module?
Yeah, that would be the place for them. But would it be more helpful
Morel Xavier wrote:
> Steve Holden wrote:
>
>> Contrast with the bleeding obvious:
>>
>> level = 0
>> if "absolute_import" in self.futures:
>> level = -1
>>
>> regards
>> Steve
>
> >
> The issue that spawned the necessity of a ternary operator in the first
> place was that
On 3/6/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
>
>
> On 3/6/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > > Didn't we set up a "security swat team" some time ago? If not, we
> > > should. Regardless, since I have more free time these days, I'd like
> > > to be on it.
> >
> > Yep, it's c
Jim Jewet writes:
> I can't imagine [a conditional] expression small enough that [requiring]
> parentheses really hurt.
>
> var = t if c else f
> var = (t if c else f)
This is a good example. I'm now +1 on adding this to PEP 8. I'm +0 on
adding it to the grammer... in the long run it's unl
I occasionally need dictionaries or sets that use object identity
rather than __hash__ to store items. Would it be appropriate to add
these to the collections module?
Neil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailm
Jim Jewett wrote:
> Now that we have started to see conditional expressions ... I would
> like to see them parenthesized. The parens aren't as important as they
> are with generator expressions, but ... they matter.
>
> From a recent checkin --
>
> level = 0 if "absolute_import" in self
FWIW, coverity has been busy marketing this already:
http://www.pcpro.co.uk/news/84465/key-opensource-code-passes-muster.html
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
On Mon, 6 Mar 2006, Barry Warsaw wrote:
> On Mon, 2006-03-06 at 14:26 -0500, Tim Peters wrote:
> > [Ben Chelf <[EMAIL PROTECTED]>]
> > > ...
> > > I'd ask that if you are interested in really digging into the results a
> > > bit
> > > further for your project, please have a couple of core maintai
[Barry]
> Yep, it's called [EMAIL PROTECTED] (with a semi-secret backing mailing
> list, which I'd be happy for you to join!).
If guessing the right Mailman URL was the semi-secret test, I passed :-)
> I definitely think that group of folks at the least should review the results.
Yup!
_
On 3/6/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On 3/6/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > level = 0 if "absolute_import" in self.futures else -1
> > Mentally, I can't help parsing that as "level = 0" plus
> > comments that turn out to be code that triggers
> > backtracking.
On 3/6/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Didn't we set up a "security swat team" some time ago? If not, we> should. Regardless, since I have more free time these days, I'd like> to be on it.Yep, it's called
[EMAIL PROTECTED] (with a semi-secret backing mailinglist, which I'd be happy
On Mon, 2006-03-06 at 14:26 -0500, Tim Peters wrote:
> [Ben Chelf <[EMAIL PROTECTED]>]
> > ...
> > I'd ask that if you are interested in really digging into the results a bit
> > further for your project, please have a couple of core maintainers (or
> > group nominated individuals) reach out to me
[Ben Chelf <[EMAIL PROTECTED]>]
> ...
> I'd ask that if you are interested in really digging into the results a bit
> further for your project, please have a couple of core maintainers (or
> group nominated individuals) reach out to me to request access.
Didn't we set up a "security swat team" som
On 3/6/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
From a recent checkin --
level = 0 if "absolute_import" in self.futures else -1Mentally, I can't help parsing that as "level = 0" plus comments that turn out to be code that triggers backracking.When the expressions (particularly the true case) a
[Anna Ravenscroft]
I think this is a really good point. next() is supposed to get used, by
coders, in regular code - so it shouldn't be __next__. I can understand the
desire for both forms, although that seems it would clutter things up
unnecessarily - particularly if the two do
Now that we have started to see conditional expressions ... I would like to see them parenthesized. The parens aren't as important as they are with generator expressions, but ... they matter.From a recent checkin --
level = 0 if "absolute_import" in self.futures else -1Mentally, I can't hel
Hello Python Developers,
I'm the CTO of Coverity, Inc., a company that does static source code
analysis to look for defects in code. You may have heard of us or of our
technology from its days at Stanford (the "Stanford Checker"). The
reason I'm writing is because we have set up a framework
Oleg Broytmann <[EMAIL PROTECTED]> wrote:
>> I just wanted to point out that one of the things I *LOVE* about Python
>> is that the design of name resolution in Python ensures that no
>> programmer need suffer from the size of the builtin namespace. If you
>> never use certain builtins, perhaps "h
On Mon, Mar 06, 2006 at 05:33:23AM -0800, Michael Chermside wrote:
> Oleg Broytmann writes that he thinks methods are inherently "better" than
> methods.
"...better than *functions*."
> In defense of functions, my first exhibit is the following snippet of Java
> code:
>
> /** Returns b^2 -
Oleg Broytmann writes that he thinks methods are inherently "better" than
methods. He asks for advantages of a function over a method, after first
presenting his arguments for methods over functions:
> -- a method is a more natural way to query or manipulate objects;
> -- a direct method call is f
> "Anthony" == Anthony Baxter <[EMAIL PROTECTED]> writes:
Anthony> It's probably worth mentioning that right now, we don't
Anthony> even come close to compiling with a C++ compiler. A bunch
Anthony> of the bugs are shallow (casting result from malloc, that
Anthony> sort of thin
39 matches
Mail list logo
