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 thing) but a
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
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 - 4ac */
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 hex or
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
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 help
[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 the same thing
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) are
[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 some time
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 to request
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 for you
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.
I think that
[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 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 maintainers (or
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
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.futures
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
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
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 called [EMAIL
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 this syntax is not
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
to
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:
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. The
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
[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 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 class adding
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 collections module?
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 collections
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 la
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 would
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, with
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
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 -1)
Contrast
[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
if
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:
(item for
see subject and http://python.org/sf/1368955
comments ?
/F
(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
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 (just because I
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 decorate the
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 than this:
39 matches
Mail list logo
