Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)
> "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 bunch more look a tad uglier. Is Anthony> this something worth trying to fix? Um ... I really only know the results for XEmacs. C++ warnings and errors do catch a number of "real bugs". But most of the *work* was done before I got really involved in the C code. Martin Buchholz <[EMAIL PROTECTED]> probably knows best, although he's been inactive for a couple of years. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .len() instead of __len__() (was: iterator API inPy3.0)
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 faster than two-level call (len() => .__len__());
> -- unnecessary cluttering of builtin namespace; the namespace should(1)
>contains only really global functions (__import__(), eval(), etc.)
Responding to your first point, "a more natural way" is not an argument...
it's an expression of your personal preference.
Your second point (performance) has some merit -- although one would hope
the difference is small in a good implementation. And your third point
(cluttering the builtin namespace) is a valid and real reason to prefer
methods.
In defense of functions, my first exhibit is the following snippet of Java
code:
/** Returns b^2 - 4ac */
public BigDecimal determinant(BigDecimal a, BigDecimal b, BigDecimal c) {
return b.multiply(b).subtract(new BigDecimal(4).multiply(a).multiply(c));
}
In other words, some things are less clear when written using the notation
used for method invocation. That is particularly true when there are
multiple objects involved and no clear reason to prefer one over another
as the "object performing the action". In languages with multiple dispatch,
like CLOS, everything looks like a function for exactly this reason.
My second exhibit is also some Java code:
public int numItems(Object o) {
if (o instanceof Collection) { // includes List, Set
return ((Collection) o).size();
} else if (o instanceof Dictionary) {
return ((Dictionary) o).size();
} else if (o instanceof CharSequence) { // includes String, StringBuffer
return ((CharSequence) o).length();
} else if (o instanceof Object[]) {
return ((Object[]) o).length;
} else {
throw new IllegalArgumentException();
}
}
The inconsistancy here is amazing... length, length(), size(). You could
put it down to poor interface design by the Java team, but you must
admit, individual objects are designed in isolation, but when there
exists a common lanugage protocol like Python's builtin len() and __len__,
that developers of individual objects go out of their way to make them
conform with the common protocol... and in the end that makes them more
usable.
I'm sure there are additional arguments, but these are the first few I
came up with. Of course, in nearly all cases, I prefer using methods...
but len() is such a powerful concept applicable across MANY diverse
kinds of objects, that I have no objection to granting it space in the
builtin namespace.
By the way... you write:
> (1) I am a perfectionist and I partially disagree with "practicality beats
> purity"; I would really love a small uncluttered builtin namespace in
> Python.
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 "super", then go ahead
and use those as identifiers in your code. Avoid only that portion of
the builtin namespace that you feel is worth keeping.
-- Michael Chermside
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .len() instead of __len__() in Py3.0
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 */
> public BigDecimal determinant(BigDecimal a, BigDecimal b, BigDecimal c) {
> return b.multiply(b).subtract(new BigDecimal(4).multiply(a).multiply(c));
> }
I never said methods are better than operators. Though to some extent
they are. For example, if you want to grep your sources for ".addArray("
you have much better chances to find what you are looking for comparing
with the case when you grep for "+=". In the latter case you will find too
much.
But I do not propose to get rid of operator overloading and always use
methods.
> public int numItems(Object o) {
> if (o instanceof Collection) { // includes List, Set
> return ((Collection) o).size();
> } else if (o instanceof Dictionary) {
> return ((Dictionary) o).size();
> } else if (o instanceof CharSequence) { // includes String, StringBuffer
> return ((CharSequence) o).length();
> } else if (o instanceof Object[]) {
> return ((Object[]) o).length;
> } else {
> throw new IllegalArgumentException();
> }
> }
>
> The inconsistancy here is amazing...
The same can easily be written in Python. In absence of builtin function
has_key() and documented method __has_key__() one can write
class MyDict(object):
def hasKey(self, key):
...
other can spell it .has_key() or .haskey(). Still those who want to emulate
dictionaries (to implement mapping protocol) spell it .has_key().
A real life example. SQLObject has a class SelectResults that partially
implements sequence/iterator protocol. But it doesn't have __len__(),
instead it has method .count(). Look at the first question at
http://svn.colorstudy.com/SQLObject/docs/FAQ.txt , "Why there is no
__len__?" So instead of len(sresults) one must write sresults.count().
So even the known protocol "len() => __len__()" doesn't prevent the
inconsistency. Sometimes one really needs the inconsistency; in this
particular case because Python internally calls len() on objects, and
implementing __len__() here would be expensive.
And those who want to be consistent are. They spell .has_key() and
implement __len__(). And if __len__() becomes .len() they will write
.len(), not .size() or .count().
> len() is such a powerful concept applicable across MANY diverse
> kinds of objects
Only to those already have method __len__(), so why not .len()?
> 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 "super", then go ahead
> and use those as identifiers in your code. Avoid only that portion of
> the builtin namespace that you feel is worth keeping.
Doesn't work. For example, PyChecker/PyLint would report warnings.
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .len() instead of __len__() in Py3.0
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 "super", then go ahead >> and use those as identifiers in your code. Avoid only that portion of >> the builtin namespace that you feel is worth keeping. > >Doesn't work. For example, PyChecker/PyLint would report warnings. ... which can be obviously shut down if you are not a newbie and know what you are doing. I want PyChecker/PyLine to find bugs in my code and help me enforce *my* personal coding standard. I don't want them to tell me what it is "generically better" to do. The fact that there is a warning for builtin shadowing, to be used by people which such a coding standard, doesn't mean that everybody must agree with it. -- Giovanni Bajo ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Coverity Open Source Defect Scan of Python
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 internally to continually scan open source projects and provide the results of our analysis back to the developers of those projects. Python is one of the 32 projects currently scanned at: http://scan.coverity.com My belief is that we (Coverity) must reach out to the developers of these packages (you) in order to make progress in actually fixing the defects that we happen to find, so this is my first step in that mission. Of course, I think Coverity technology is great, but I want to hear what you think and that's why I worked with folks at Coverity to put this infrastructure in place. The process is simple -- it checks out your code each night from your repository and scans it so you can always see the latest results. Right now, we're guarding access to the actual defects that we report for a couple of reasons: (1) We think that you, as developers of Python, should have the chance to look at the defects we find to patch them before random other folks get to see what we found and (2) From a support perspective, we want to make sure that we have the appropriate time to engage with those who want to use the results to fix the code. Because of this second point, 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. As this is a new process for us and still involves a small number of packages, I want to make sure that I personally can be involved with the activity that is generated from this effort. So I'm basically asking for people who want to play around with some cool new technology to help make source code better. If this interests you, please feel free to reach out to me directly. And of course, if there are other packages you care about that aren't currently on the list, I want to know about those too. If this is the wrong list, my sincerest apologies and please let me know where would be a more appropriate forum for this type of message. Many thanks for reading this far... -ben Ben Chelf Chief Technology Officer Coverity, Inc. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] conditional expressions - add parens?
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 parsing that as "level = 0" plus comments that turn out to be code that triggers backracking.When the expressions (particularly the true case) are longer, it gets even worse. 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) -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Python humor
[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 [Phillip] >>> By this argument, we should be using ob.len() instead of len(ob), and >>> ob.iter() instead of iter(ob). [Oleg] >> Yes, I think it'd be more consistent and more object-oriented. After all >> we've switched from string.split(x, y) to x.split(y)... [Raymond Hettinger] > LOL, Shakespearean comedy on python-dev: > > * Phillip mistates Anna's position and shoots down a straw-man. > * Oleg agrees with a literal reading of Phillips note, missing the sarcasm > entirely. Then * Raymond points out those foibles in a humorous way. * Uncle Timmy replies in fashion that's hard to understand, although some suspect he's insinuating that all missed the point ;-) How's everyone doing, BTW? I think I picked up the Texas Mystery Disease from Holger Krekel -- bed-ridden 20 hours Saturday, and most of Sunday, with dry cough and high fever. Or that's just a normal outcome of sprinting :-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] conditional expressions - add parens?
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 longer, it gets even worse. 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) I'm not sure, are you suggesting the grammar/parser enforces it that way, or that it should be in PEP-8?(I still can't help but go 'yecchh' whenever I see the code. It looks like Perl's 'expr if expr' form, but it behaves quite different. Right now, removing if/else expressions still looks like the best solution, to me :-> But gauging reactions (my own and others) to the actual if-expr in use is the main reason I added those couple of lines to the compiler package.) -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Open Source Defect Scan of Python
[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 ago? If not, we should. Regardless, since I have more free time these days, I'd like to be on it. think-of-it-as-john-kelly-reaching-out-to-andy-spowicz-ly y'rs - tim ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Open Source Defect Scan of Python
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 access. > > 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 mailing list, which I'd be happy for you to join!). I definitely think that group of folks at the least should review the results. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Open Source Defect Scan of Python
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 to join!). I definitely think thatgroup of folks at the least should review the results.Well, if we start volunteering here, I'll volunteer as well. (For either group.) Can't let Tim have all the fun! -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] conditional expressions - add parens?
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 adding parentheses would help ... > > level = (0 if "absolute_import" in self.futures else -1) > I'm not sure, are you suggesting the grammar/parser > enforces it that way, or that it should be in PEP-8? I would prefer that the grammar enforce it, but putting it in PEP 8 would be a half-way measure. I can't imagine an expression small enough that the parentheses really hurt. var = t if c else f var = (t if c else f) In PEP 8, I would even go so far as to recommend parentheses around the three sub-expressions if they contain any internal whitespace, but I don't think the grammar should enforce that. > (I still can't help but go 'yecchh' whenever I see the > code. It looks like Perl's 'expr if expr' form, but it > behaves quite different. Right now, removing if/else > expressions still looks like the best solution, to me :-> Yah, that sounds uncontroversial. :D -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Open Source Defect Scan of Python
[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! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Open Source Defect Scan of Python
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 > > > group nominated individuals) reach out to me to request access. > > > > 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 mailing > list, which I'd be happy for you to join!). I definitely think that > group of folks at the least should review the results. > > -Barry > >From their open source chart: OpenVPN 7 69,842 0.100 Sign in Register Perl89 479,780 0.186 Sign in Register PHP 207 431,251 0.480 Sign in Register PostgreSQL 297 815,700 0.364 Sign in Register ProFTPD 26 89,650 0.290 Sign in Register Python 59 259,896 0.227 Sign in Register Samba 215 312,482 0.688 Sign in Register This is interesting stuff. See http://metacomp.stanford.edu for some background. The Coverty marketing droids need to be a bit less anal about getting people to register at the website. IMHO, the technology should be described openly and allowed to speak for itself. On the other hand, the policy of not disclosing discovered bugs until someone has had a chance to evaluate their significance and fix them is probably a good one. I'd also encourage Coventry to explain their business model a bit more clearly. Coventry seems to be supportive of open source projects. Coverty also seems to be targeting big companies as customers. It's not clear how arbitrary open source projects (and small companies and individuals) will be able to take advantage of Coventry's products and services. >From Ben's email: ... 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. As this is a new process for us and still involves a small number of packages, I want to make sure that I personally can be involved with the activity that is generated from this effort. So I'm basically asking for people who want to play around with some cool new technology to help make source code better. If this interests you, please feel free to reach out to me directly. And of course, if there are other packages you care about that aren't currently on the list, I want to know about those too. This looks to me to be something worth doing. I wish I had the time to be one of the designated folks, but, sadly, I don't. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Open Source Defect Scan of Python
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] conditional expressions - add parens?
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 else -1
>
Personally I think the above code exemplifies exactly why Guido was
correct in his reluctance to add conditional expressions.
> Mentally, 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 longer, it gets
> even worse.
>
> 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 with the bleeding obvious:
level = 0
if "absolute_import" in self.futures:
level = -1
or even, if a certain obscurity is desirable:
level = - ("absolute_import" in self.futures)
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd www.holdenweb.com
Love me, love my blog holdenweb.blogspot.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] collections.idset and collections.iddict?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] (no subject)
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 unlikely to make any
difference.
Steve Holden writes:
> Contrast with the bleeding obvious:
>
> level = 0
> if "absolute_import" in self.futures:
> level = -1
Comparing this to the alternative:
level = (0 if ("absolute_import" in self.futures) else -1)
In the latter, level clearly takes on values of 0 or -1. In the
former, level has a default value of 0, which is followed by what
appears to be some branching logic.
> or even, if a certain obscurity is desirable:
>
> level = - ("absolute_import" in self.futures)
The only USE I have ever seen for code obscurity was in writing
certain vote-counting software where the true behavior needed
to remain obscure even in the face of source code publication.[1]
-- Michael Chermside
[1] http://graphics.stanford.edu/~danielrh/vote/scores.html
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Open Source Defect Scan of Python
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 PROTECTED] (with a semi-secret backing mailing > > list, which I'd be happy for you to join!). I definitely think that > > group of folks at the least should review the results. > > > Well, if we start volunteering here, I'll volunteer as well. (For either > group.) Can't let Tim have all the fun! I also sent mail to Ben volunteering. I expect the scope of defects recognized is larger than just security. In particular, the compiler has a large body of code that has never been released before. It would nice to catch a few of its bugs before a release :-). Jeremy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] conditional expressions - add parens?
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 usable at all in quite a few > situations like, say, list comprehensions... > Sure, and for those uses it's good enough. This isn't really a python-dev topic, though, so I'll avoid following up further on this list. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd www.holdenweb.com Love me, love my blog holdenweb.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.idset and collections.iddict?
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 generalize this to having something in collections that worked like DSU for dicts and their hash value? -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Two gcmodule patches
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/index.php?func=detail&aid=1100294&group_id=5470&atid=305470 Mine adds gc.get_count() -- a parallel to .get_threshold() -- and also adds an optional 'generation' argument to gc.collect(). https://sourceforge.net/tracker/index.php?func=detail&aid=1443865&group_id=5470&atid=305470 The patch also cleans up a couple of gcc warnings. Thoughts? -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two gcmodule patches
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 library reference should be updated though. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two gcmodule patches
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 debugging gc > > issues. > > I have no major objections to either patch. The library reference > should be updated though. Yes, definitely. Thanks. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.idset and collections.iddict?
[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) That would seem to be more Pythonic than creating custom variants of other containers. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.idset and collections.iddict?
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 a method: >def __hash__(self): >return id(self) > > That would seem to be more Pythonic than creating custom variants of other > containers. I hate to second-guess the OP, but you'd have to override __eq__ too, and probably __ne__ and __cmp__ just to be sure. And probably that wouldn't do -- since the default __hash__ and __eq__ have the desired behavior, the OP is apparently talking about objects that override these operations to do something meaningful; overriding them back presumably breaks other functionality. 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 list.sort()? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.idset and collections.iddict?
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? > > > > Why not decorate the objects with a class adding a method: > >def __hash__(self): > >return id(self) > > > > That would seem to be more Pythonic than creating custom variants of other > > containers. > > I hate to second-guess the OP, but you'd have to override __eq__ too, > and probably __ne__ and __cmp__ just to be sure. And probably that > wouldn't do -- since the default __hash__ and __eq__ have the desired > behavior, the OP is apparently talking about objects that override > these operations to do something meaningful; overriding them back > presumably breaks other functionality. I assumed Neil wanted a container that was id() sensitive, I've done this occasionally myself to see if an object is in a container and not just an object equivalent to the one I am checking for. >>> a = set([1,2,3,4]) >>> b = set([1,2,3,4]) >>> a == b True >>> a is b False >>> container = [a] >>> b in container True >>> container = [id(a)] >>> id(b) in container False >>> -Jack ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.idset and collections.iddict?
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 module? >> >> Why not decorate the objects with a class adding a method: >>def __hash__(self): >>return id(self) >> >> That would seem to be more Pythonic than creating custom variants >> of other >> containers. > > I hate to second-guess the OP, but you'd have to override __eq__ too, > and probably __ne__ and __cmp__ just to be sure. And probably that > wouldn't do -- since the default __hash__ and __eq__ have the desired > behavior, the OP is apparently talking about objects that override > these operations to do something meaningful; overriding them back > presumably breaks other functionality. > > 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 list.sort()? +1. I've wanted such a thing a couple times, and there is some precedent in the stdlib (e.g. WeakKeyDictionary would be a lot shorter with such a base class). -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.idset and collections.iddict?
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 list.sort()? > > +1. I've wanted such a thing a couple times, and there is some > precedent in the stdlib (e.g. WeakKeyDictionary would be a lot > shorter with such a base class). Seconded -- though at least in the cases I remember better what I really needed was a _list_ with such functionality (order was significant, but I wanted 'in'-tests and find and remove calls to work by id, not by ==) -- I ended up with a somewhat more complicated solution (not just a list subclass, though that might perhaps be simpler). In the case where I needed a dict, I inherited from DictMixin and delegated some methods (with id(key) instead of key) to a self.somedict -- if a dict could be built with a key function, the solution would be both simpler and faster. Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iterator API in Py3.0
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 break this into multiple statements. [inspired by a recent python-list question] -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Python humor
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 dry cough and high fever. Or that's just a normal > outcome of sprinting :-) I got vaccinated against flu in Oct last year, and as a result haven't had to take ANY sick day so far (darn, I'm wasting Google's policy of giving unlimited sick days...!!!). Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] conditional expressions - add parens?
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.1415926...!!!). *Mandatory* parentheses make this form MUCH more readable. Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] conditional expressions - add parens?
"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 with the bleeding obvious:
>
> level = 0
> if "absolute_import" in self.futures:
> level = -1
>
> or even, if a certain obscurity is desirable:
>
> level = - ("absolute_import" in self.futures)
>
Wait a second.
I may be just a user but if the above is correct then that syntax needs to
die!
There is no logical reason for "XX if YY else ZZ" to be roughly equivlent
to:
"if (YY) then {ZZ} else {XX}" , but AFAICT that is pretty much the way you
expanded that.
I hope I misunderstood, or that there was a typo in a post.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] conditional expressions - add parens?
[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 "absolute_import" in self.futures:
>> level = -1
>>
>> or even, if a certain obscurity is desirable:
>>
>> level = - ("absolute_import" in self.futures)
In honor of Peter Naur receiving the 2005 Turing Award:
and remembering Python's Algol roots, I'd like to constrast it with
the truly obvious:
level = (if "absolute_import" in self.futures then 0 else -1)
That way also has the minor advantage of computing the same value for
`level` as Jim's code ;-)
[Joe Smith]
> Wait a second.
>
> I may be just a user but if the above is correct then that syntax needs to
> die!
> There is no logical reason for "XX if YY else ZZ" to be roughly equivlent
> to:
> "if (YY) then {ZZ} else {XX}" , but AFAICT that is pretty much the way you
> expanded that.
Ya, Steve just got it backwards. "(X if Y else Z)" is the same as
"(if Y then X else Z)", except for the excessive novelty. The obvious
spelling would require making "then" a keyword, which is actually OK
with everyone :-)
> I hope I misunderstood, or that there was a typo in a post.
You were lucky this time, bucko, but don't ever go questioning a
python-dev regular again ;-)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iterator API in Py3.0
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 item in items if item > 3).next() > > or alternatives that would break this into multiple statements. Why is putting everything on a single line considered elegant? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] how about adding ping's uuid module to the standard lib ?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] conditional expressions - add parens?
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 can't give it +3.1415926...!!!). *Mandatory*
> parentheses make this form MUCH more readable.
but which parens ?
level = 0 if "absolute_import" in self.futures else -1
level = 0 if ("absolute_import" in self.futures) else -1
level = (0 if "absolute_import" in self.futures else -1)
level = (0 if ("absolute_import" in self.futures) else -1)
level = ((0) if ("absolute_import" in self.futures) else (-1)) # ...
if you're asking me, I'd say that the second alternative is most
readable here.
at least as long as
level = if ("absolute_import" in self.futures) then 0 else -1
is not on the list...
level = 0 or -1 depending on "absolute_import" in self.futures
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.idset and collections.iddict?
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 objects with a class adding a method:
>>def __hash__(self):
>>return id(self)
>>
>> That would seem to be more Pythonic than creating custom variants of other
>> containers.
>
> I hate to second-guess the OP, but you'd have to override __eq__ too,
> and probably __ne__ and __cmp__ just to be sure. And probably that
> wouldn't do -- since the default __hash__ and __eq__ have the desired
> behavior, the OP is apparently talking about objects that override
> these operations to do something meaningful; overriding them back
> presumably breaks other functionality.
>
> 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 list.sort()?
That's what occurred to me as soon as I read Neil's post as well. I
think it would have the added benefit that it would be case insensitive
while still preserving case. Here's a rough idea of the semantics:
from UserDict import DictMixin
class KeyedDict(DictMixin):
def __init__(self, keyfunc):
self.keyfunc = keyfunc
self.data = {}
def __getitem__(self, key):
return self.data[self.keyfunc(key)][1]
def __setitem__(self, key, value):
self.data[self.keyfunc(key)] = (key, value)
def __delitem__(self, key):
del self.data[self.keyfunc(key)]
def keys(self):
return [v[0] for v in self.data.values()]
I definitely like this more than a key-normalizing dictionary -- the
normalized key is never actually exposed anywhere. I didn't follow the
defaultdict thing through to the end, so I didn't catch what the
constructor was going to look like for that; but I assume those choices
will apply here as well.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iterator API in Py3.0
"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: > (item for item in items if item > 3).next() > or alternatives that would break this into multiple statements. > [inspired by a recent python-list question] Yuck. This bug-prone one-liner was an answer to the question: how do I (the OP) get just the first item of items meeting a conditiion instead of all, as with filter, with a one-line expression instead of the obvious for loop. Bad question; bad answer. As I pointed out, this 'solution' raises StopIteration if there is no first valid item. That in turn crashes the program unless one adds more lines to deal with the possible exception. In the same post, I also suggested the OP first define his desired no-item behavior (not answered that I have seen). To me, one-liner-itis can entertain, but also distract from complete, correct coding. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
