Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method
John Arbash Meinel wrote: Because you wouldn't want to have A.echo() Say that it takes 1 argument and (-1 given) ? Something like "1 argument in addition to 'self'" would be reasonably clear and would cover both situations. +1 on fixing this from me, too. Even when you understand exactly what's going on, it's annoying having to make the mental adjustment every time. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method
Greg Ewing writes: > John Arbash Meinel wrote: > > > Because you wouldn't want to have > > > > A.echo() > > > > Say that it takes 1 argument and (-1 given) ? > > Something like "1 argument in addition to 'self'" would be reasonably > clear and would cover both situations. Except that there's nothing special to the syntax or parser about the name ‘self’. > +1 on fixing this from me, too. Even when you understand exactly > what's going on, it's annoying having to make the mental adjustment > every time. Would it help if the traceback showed the ‘repr()’ of each of the arguments received? That way it would be much clearer when the instance was received as the first argument. -- \ “Any sufficiently advanced bug is indistinguishable from a | `\ feature.” —Rich Kulawiec | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method
On Thu, May 20, 2010 at 11:55:02AM +0900, Stephen J. Turnbull wrote: > Giampaolo Rodolà writes: > > >>> class A: > > ... def echo(self, x): > > ... return x > > ... > > >>> a = A() > > >>> a.echo() > > Traceback (most recent call last): > > File "", line 1, in > > TypeError: echo() takes exactly 2 arguments (1 given) > > >>> > > > > I bet my last 2 cents this has already been raised in past but I want > > to give it a try and revamp the subject anyway. > > Is there a reason why the error shouldn't be adjusted to state that > > *1* argument is actually required instead of 2? > > As a function, it does take two arguments, and can be called > explicitly that way, no? Adjustment is not enough, the message needs > to be substantially rewritten. Something like > > TypeError: invoked as a method, echo() takes exactly 1 argument (0 given) > > captures the semantics, but is perhaps too verbose. How about: TypeError: bound method echo() takes exactly 1 argument (0 given) That way you can also have: "unbound method echo() ...". And it's as semantically correct as the short "echo() takes ..." Not having looked at the code I don't know how hard it is for the code that raises this traceback to notice if it's a bound or unbound method tough. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unordered tuples/lists
Hi, Guido. On Wed, May 19, 2010 at 12:11 AM, Guido van Rossum wrote: > This is typically called a "bag". Maybe searching for that will help > you find a recipe? > A bag/multiset is close to what I need, except for one thing: I need to iterate over the elements in the original order, not in a random order. The data structure I'm proposing is basically a list/tuple, and the only thing that changes is comparison with another unordered list/tuple: If they both have the same elements with the same multiplicity, they are equivalent (regardless of the order). Cheers, - Gustavo. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unordered tuples/lists
Hello, Oleg. > class UnorderedList(list): >def __eq__(self, other): >if not isinstance(other, UnorderedList): >return False >return sorted(self) == sorted(other) > >def __ne__(self, other): >return not self.__eq__(other) > > Do you need more than that? > > Oleg. That's what I had in mind. I think it'd be useful enough to go in the standard library. Now that there's a sample implementation, should I still try to demonstrate why I believe it's worth adding to the stdlib and get support? Cheers, - Gustavo. On Tue, May 18, 2010 at 11:13 PM, Gustavo Narea wrote: > Hello, everybody. > > I've been searching for a data structure like a tuple/list *but* unordered > -- > like a set, but duplicated elements shouldn't be removed. I have not even > found a recipe, so I'd like to write an implementation and contribute it to > the "collections" module in the standard library. > > This is the situation I have: I have a data structure that represents an > arithmetic/boolean operation. Operations can be commutative, which means > that > the order of their operands don't change the result of the operation. This > is, > the following operations are equivalent: >operation(a, b, c) == operation(c, b, a) == operation(b, a, c) >operation(a, b, a) == operation(a, a, b) == operation(b, a, a) >operation(a, a) == operation(a, a) > > So, I need a type to store the arguments/operands so that if two of these > collections have the same elements with the same multiplicity, they are > equivalent, regardless of the order. > > A multiset is not exactly what I need: I still need to use the elements in > the > order they were given. For example, the logical conjuction (aka "and" > operator) has a left and right operands; I need to evaluate the first/left > one > and, if it returned True, then call the second/right one. They must not be > evaluated in a random order. > > To sum up, it would behave like a tuple or a list, except when it's > compared > with another object: They would be equivalent if they're both unordered > tuples/lists, and have the same elements. There can be mutable and > immutable > editions (UnorderedList and UnorderedTuple, respectively). > > I will write a PEP to elaborate on this if you think it'd be nice to have. > Or, > should I have written the PEP first? > > Cheers, > -- > Gustavo Narea . > | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method
2010/5/20 John Arbash Meinel : > Giampaolo Rodolà wrote: > class A: >> ... def echo(self, x): >> ... return x >> ... > a = A() > a.echo() >> Traceback (most recent call last): >> File "", line 1, in >> TypeError: echo() takes exactly 2 arguments (1 given) >> >> I bet my last 2 cents this has already been raised in past but I want >> to give it a try and revamp the subject anyway. >> Is there a reason why the error shouldn't be adjusted to state that >> *1* argument is actually required instead of 2? >> > > Because you wouldn't want to have > > A.echo() > > Say that it takes 1 argument and (-1 given) ? > > John > =:-> > > I see that as a different error type: what you're doing there is calling a method of a class which you haven't instantiated in the first place. Actually the error message returned in this other case is not very clear as well: "unbound method echo() must be called with A instance as first argument (got nothing instead)" It talks about "arguments" while no arguments are actually involved in the problem: just a class I forgot to initialize. --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unordered tuples/lists
On Wed, May 19, 2010 at 09:56:03AM +0100, Gustavo Narea wrote: > I think it'd be useful enough to go in the standard library. Now that > there's a sample implementation, should I still try to demonstrate why I > believe it's worth adding to the stdlib and get support? I think yes. How many developers would find it useful?.. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method
On 20/05/2010 10:49, Giampaolo Rodolà wrote: 2010/5/20 John Arbash Meinel: Giampaolo Rodolà wrote: class A: ... def echo(self, x): ... return x ... a = A() a.echo() Traceback (most recent call last): File "", line 1, in TypeError: echo() takes exactly 2 arguments (1 given) I bet my last 2 cents this has already been raised in past but I want to give it a try and revamp the subject anyway. Is there a reason why the error shouldn't be adjusted to state that *1* argument is actually required instead of 2? Because you wouldn't want to have A.echo() Say that it takes 1 argument and (-1 given) ? John =:-> I see that as a different error type: what you're doing there is calling a method of a class which you haven't instantiated in the first place. Actually the error message returned in this other case is not very clear as well: "unbound method echo() must be called with A instance as first argument (got nothing instead)" It talks about "arguments" while no arguments are actually involved in the problem: just a class I forgot to initialize. Although the pattern of calling an unbound method with an instance as the first argument (self) is not uncommon - and if you're doing Class.method() that not only looks like what you're doing but is also an accurate error message. I would also expect that accidentally calling unbound methods is a much less common error than calling bound methods with the wrong number of arguments... All the best, Michael Foord --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unordered tuples/lists
On Thu, 20 May 2010 08:40:25 pm Oleg Broytman wrote: > On Wed, May 19, 2010 at 09:56:03AM +0100, Gustavo Narea wrote: > > I think it'd be useful enough to go in the standard library. Now > > that there's a sample implementation, should I still try to > > demonstrate why I believe it's worth adding to the stdlib and get > > support? > >I think yes. How many developers would find it useful?.. Adding classes to the standard library doesn't come without cost. There's the maintenance and testing burden, and the cognitive burden of having to choose between similar classes with slight variations of behaviour. I don't think the benefit of this proposed subclass is great enough to outweigh the costs. It is a trivial subclass -- Oleg gave a seven line subclass of list -- with a fairly specialist use-case (it is a regular ordered list except for the purposes of equality comparisons). I don't believe it is a burden on developers to add it to their own application should they need it. -1 for this. If anyone wishes to support this proposal, please come up with a less misleading name than "UnorderedList". -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unordered tuples/lists
On Wed, May 19, 2010 at 1:56 AM, Gustavo Narea wrote: > Hello, Oleg. > >> >> class UnorderedList(list): >> def __eq__(self, other): >> if not isinstance(other, UnorderedList): >> return False >> return sorted(self) == sorted(other) >> >> def __ne__(self, other): >> return not self.__eq__(other) >> >> Do you need more than that? >> >> Oleg. > > That's what I had in mind. > > I think it'd be useful enough to go in the standard library. Now that > there's a sample implementation, should I still try to demonstrate why I > believe it's worth adding to the stdlib and get support? > > Cheers, > > - Gustavo. I'm generally in favor of adding more data structures to Python, but I'm at best -0 on this. Besides being trivial to code and questionably useful, a much better implementation could be written using heap. Maybe with a better implementation I would go +0, but I'm hard pressed to see a case where this would be needed and could not be trivially written. Geremy Condra ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method
On Thu, 20 May 2010 11:49:02 +0200, =?ISO-8859-1?Q?Giampaolo_Rodol=E0?= wrote: > 2010/5/20 John Arbash Meinel : > > a.echo() > >> Traceback (most recent call last): > >> =A0 File "", line 1, in > >> TypeError: echo() takes exactly 2 arguments (1 given) > >> > >> I bet my last 2 cents this has already been raised in past but I want > >> to give it a try and revamp the subject anyway. > >> Is there a reason why the error shouldn't be adjusted to state that > >> *1* argument is actually required instead of 2? > > > > Because you wouldn't want to have > > > > A.echo() > > > > Say that it takes 1 argument and (-1 given) ? > > I see that as a different error type: what you're doing there is > calling a method of a class which you haven't instantiated in the > first place. > Actually the error message returned in this other case is not very > clear as well: > > "unbound method echo() must be called with A instance as first > argument (got nothing instead)" > > It talks about "arguments" while no arguments are actually involved in > the problem: just a class I forgot to initialize. That second message is entirely accurate and IMO should not be changed. As Michael said, calling an unbound method is not that uncommon. The problem with fixing the first message (as you will see if you read issue 2516) is that it turns out to be non-trivial to do it right. Otherwise I think it would have been fixed already. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unordered tuples/lists
On 20/05/2010 17:02, geremy condra wrote: On Wed, May 19, 2010 at 1:56 AM, Gustavo Narea wrote: Hello, Oleg. class UnorderedList(list): def __eq__(self, other): if not isinstance(other, UnorderedList): return False return sorted(self) == sorted(other) def __ne__(self, other): return not self.__eq__(other) Do you need more than that? Oleg. That's what I had in mind. I think it'd be useful enough to go in the standard library. Now that there's a sample implementation, should I still try to demonstrate why I believe it's worth adding to the stdlib and get support? Cheers, - Gustavo. I'm generally in favor of adding more data structures to Python, but I'm at best -0 on this. Besides being trivial to code and questionably useful, a much better implementation could be written using heap. -1 from me, a trivial implementation of an uncommon use case. At this point the discussion belongs on python-ideas anyway. (The trouble with sorted is how it breaks with un-orderable types. There are at least two places now in the py3k standard library that have techniques for comparing sequences of heterogenous types - both prettyprint and unittest I believe. Perhaps a standard recipe for comparing or sorting such containers *does* belong somewhere more obvious.) All the best, Michael Maybe with a better implementation I would go +0, but I'm hard pressed to see a case where this would be needed and could not be trivially written. Geremy Condra ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] bug or feature? fixing argparse's default help value for version actions
Sorry I haven't had time to get around to the argparse issues. I
should have time this weekend. I need a release manager call on one of
the issues though. Two things I assume are fine to fix at this stage:
* In the documentation, the '--version' example should either not use
a shorthand, or should use the conventional '-V'
* In the documentation, the difference between the argparse and
optparse ways of specifying versions needs to be mentioned in the
section on migrating from optparse.
One thing I'm not sure about:
* Right now, the default help value for the version action is None,
which is pretty useless since it means that everyone has to type in
the same help="show program's version number and exit" when they use
the version action. Instead, the string "show program's version number
and exit" should have been the default value for the help argument. To
be explicit, right now everyone who adds a version to their argument
parser has to write:
parser.add_argument('-V', action='version', version='',
help="show program's version number and exit")
With the fixed default value you would only have to write:
parser.add_argument('-V', action='version', version='')
Can this be considered a bug, i.e. something that can be committed
before the RC? Or does it need to be considered a feature, i.e. at
this point can never be added to Python 2.7?
Thanks, and sorry again for not having time for this until now,
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method
On 5/20/2010 4:02 AM, Floris Bruynooghe wrote: TypeError: invoked as a method, echo() takes exactly 1 argument (0 given) captures the semantics, but is perhaps too verbose. How about: TypeError: bound method echo() takes exactly 1 argument (0 given) That way you can also have: "unbound method echo() ...". And it's as semantically correct as the short "echo() takes ..." Not having looked at the code I don't know how hard it is for the code that raises this traceback to notice if it's a bound or unbound method tough. In 3.x, there are no unbound method objects, just functions. But that should make the difference *easier* to detect, as bound/unbound method objects were actually the same class, differing only in an attribute. I notice >>> list.append() Traceback (most recent call last): File "", line 1, in list.append() TypeError: descriptor 'append' of 'list' object needs an argument So here the message is specific to the type of the callable. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug or feature? fixing argparse's default help value for version actions
On Thu, May 20, 2010 at 09:18, Steven Bethard wrote:
> Sorry I haven't had time to get around to the argparse issues. I
> should have time this weekend. I need a release manager call on one of
> the issues though. Two things I assume are fine to fix at this stage:
>
> * In the documentation, the '--version' example should either not use
> a shorthand, or should use the conventional '-V'
> * In the documentation, the difference between the argparse and
> optparse ways of specifying versions needs to be mentioned in the
> section on migrating from optparse.
>
> One thing I'm not sure about:
>
> * Right now, the default help value for the version action is None,
> which is pretty useless since it means that everyone has to type in
> the same help="show program's version number and exit" when they use
> the version action. Instead, the string "show program's version number
> and exit" should have been the default value for the help argument. To
> be explicit, right now everyone who adds a version to their argument
> parser has to write:
>
> parser.add_argument('-V', action='version', version='',
> help="show program's version number and exit")
>
> With the fixed default value you would only have to write:
>
> parser.add_argument('-V', action='version', version='')
>
> Can this be considered a bug, i.e. something that can be committed
> before the RC? Or does it need to be considered a feature, i.e. at
> this point can never be added to Python 2.7?
In the end it's Benjamin's call, but my vote is to make the change.
The chances someone wanted None as their help message is so bloody
small and this is such a good UX change that I'm +1 on making the
change.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug or feature? fixing argparse's default help value for version actions
Brett Cannon wrote: In the end it's Benjamin's call, but my vote is to make the change. The chances someone wanted None as their help message is so bloody small and this is such a good UX change that I'm +1 on making the change. I completely agree. -- Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unordered tuples/lists
> I think it'd be useful enough to go in the standard library. Now that > there's a sample implementation, should I still try to demonstrate why I > believe it's worth adding to the stdlib and get support? Most definitely. Just in case it isn't clear: nobody else seems to think this is useful (let alone useful enough to go into the standard library). In addition, it's trivial to implement, more reason not to add it. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unordered tuples/lists
Martin said: > Most definitely. Just in case it isn't clear: nobody else seems to think > this is useful (let alone useful enough to go into the standard > library). In addition, it's trivial to implement, more reason not to add > it. Yeah, fair enough. Thanks for your responses! :) -- Gustavo Narea . | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding a new C API function in 2.6
Hello, I would like to check that it's possible to a new C API function in the 2.6 branch, on the basis that it would help solve what seems to be reported as a security problem by several vendors (including Linux distributions) -- see http://bugs.python.org/issue5753 for a thorough discussion. The change is rather minimal at the code level; it adds a new function PySys_SetArgvEx which has an additional flag telling it whether to update sys.path or not. The existing PySys_SetArgv function unconditionally updates sys.path, which can allow shadowing of stdlib or third-party library modules by an attacker. Thank you Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a new C API function in 2.6
Sounds good to me, since this is (a) a security fix that will make some vendors happy, and (b) only a C-level API. I expect that some apps embedding Python will use this API unconditionally and this break with earlier Python versions; this could be intentional because of the vulnerability (else why would they change their code to call the new API), or they can use an #if to check for a version >= 2.6.6. --Guido On Thu, May 20, 2010 at 12:32 PM, Antoine Pitrou wrote: > > Hello, > > I would like to check that it's possible to a new C API function in the > 2.6 branch, on the basis that it would help solve what seems to be > reported as a security problem by several vendors (including Linux > distributions) -- see http://bugs.python.org/issue5753 for a thorough > discussion. > > The change is rather minimal at the code level; it adds a new function > PySys_SetArgvEx which has an additional flag telling it whether to > update sys.path or not. The existing PySys_SetArgv function > unconditionally updates sys.path, which can allow shadowing of stdlib > or third-party library modules by an attacker. > > Thank you > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Incorrect length of collections.Counter objects / Multiplicity function
Anyone? Gustavo said: > Hello, everyone. > > I've checked the new collections.Counter class and I think I've found a bug: > > >>> from collections import Counter > > >>> c1 = Counter([1, 2, 1, 3, 2]) > > >>> c2 = Counter([1, 1, 2, 2, 3]) > > >>> c3 = Counter([1, 1, 2, 3]) > > >>> c1 == c2 and c3 not in (c1, c2) > > > > True > > > > >>> # Perfect, so far. But... There's always a "but": > > ... > > > > >>> len(c1) > > > > 3 > > The length of a Counter is the amount of unique elements. But the length > must be the cardinality, and the cardinality of a multiset is the total > number of elements (including duplicates) [1] [2]. The source code > mentions that the recipe on ActiveState [3] was one of the references, but > that recipe has this right. > > Also, why is it indexed? The indexes of a multiset call to mind the > position of its elements, but there's no such thing in sets. I think this > is inconsistent with the built-in set. I would have implemented the > multiplicity function as a method instead of the indexes: > c1.get_multiplicity(element) > # instead of > c1[element] > > Is this the intended behavior? If so, I'd like to propose a proper multiset > implementation for the standard library (preferably called "Multiset"; > should I create a PEP?). If not, I can write a patch to fix it, although > I'm afraid it'd be a backwards incompatible change. > > Cheers, > > [1] http://en.wikipedia.org/wiki/Multiset#Overview > [2] http://preview.tinyurl.com/smalltalk-bag > [3] http://code.activestate.com/recipes/259174/ -- Gustavo Narea . | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Incorrect length of collections.Counter objects / Multiplicity function
On Thu, May 20, 2010 at 5:59 PM, Gustavo Narea wrote: > Anyone? The best place to post a bug is the bug tracker [0]: you'll surely receive proper attention there. Regards, [0] http://bugs.python.org/ -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Incorrect length of collections.Counter objects / Multiplicity function
On Tue, May 18, 2010 at 11:00 PM, Gustavo Narea wrote: > I've checked the new collections.Counter class and I think I've found a bug: > >> >>> from collections import Counter >> >>> c1 = Counter([1, 2, 1, 3, 2]) >> >>> c2 = Counter([1, 1, 2, 2, 3]) >> >>> c3 = Counter([1, 1, 2, 3]) >> >>> c1 == c2 and c3 not in (c1, c2) >> True >> >>> # Perfect, so far. But... There's always a "but": >> ... >> >>> len(c1) >> 3 This is the intended behaviour; it also agrees with what you get when you iterate over a Counter object: >>> list(c1) [1, 2, 3] As I understand it, there are other uses for Counter objects besides treating them as multisets; I think the choices for len() and iter() reflected those other uses. > Is this the intended behavior? If so, I'd like to propose a proper multiset > implementation for the standard library (preferably called "Multiset"; should > I create a PEP?). Feel free! The proposal should probably go to python-list or python-ideas rather than here, though. See also this recent thread on python-list, and in particular the messages from Raymond Hettinger in that thread: http://mail.python.org/pipermail/python-list/2010-March/thread.html Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Incorrect length of collections.Counter objects / Multiplicity function
On Thu, May 20, 2010 at 10:18 PM, Mark Dickinson wrote: > See also this recent thread on python-list, and in particular the messages > from Raymond Hettinger in that thread: > > http://mail.python.org/pipermail/python-list/2010-March/thread.html Sorry, bad thread link. Try: http://mail.python.org/pipermail/python-list/2010-March/1238730.html instead. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a new C API function in 2.6
On May 20, 2010, at 12:53 PM, Guido van Rossum wrote: >Sounds good to me, since this is (a) a security fix that will make >some vendors happy, and (b) only a C-level API. I expect that some >apps embedding Python will use this API unconditionally and this break >with earlier Python versions; this could be intentional because of the >vulnerability (else why would they change their code to call the new >API), or they can use an #if to check for a version >= 2.6.6. I concur, as long as the new API availability is clearly spelled out in the release notes, NEWS, and C API documentation. Maybe even provide an example #ifdef in the latter. Should we start thinking about releasing 2.6.6 soonish? -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a new C API function in 2.6
On 5/20/2010 5:52 PM, Barry Warsaw wrote: On May 20, 2010, at 12:53 PM, Guido van Rossum wrote: Sounds good to me, since this is (a) a security fix that will make some vendors happy, and (b) only a C-level API. I expect that some apps embedding Python will use this API unconditionally and this break with earlier Python versions; this could be intentional because of the vulnerability (else why would they change their code to call the new API), or they can use an #if to check for a version>= 2.6.6. I concur, as long as the new API availability is clearly spelled out in the release notes, NEWS, and C API documentation. Maybe even provide an example #ifdef in the latter. Should we start thinking about releasing 2.6.6 soonish? By tradition, it should come out soon after 2.7 and be the last bugfix (except for security patches). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a new C API function in 2.6
On May 20, 2010, at 06:01 PM, Terry Reedy wrote: >On 5/20/2010 5:52 PM, Barry Warsaw wrote: >> On May 20, 2010, at 12:53 PM, Guido van Rossum wrote: >> >>> Sounds good to me, since this is (a) a security fix that will make >>> some vendors happy, and (b) only a C-level API. I expect that some >>> apps embedding Python will use this API unconditionally and this break >>> with earlier Python versions; this could be intentional because of the >>> vulnerability (else why would they change their code to call the new >>> API), or they can use an #if to check for a version>= 2.6.6. >> >> I concur, as long as the new API availability is clearly spelled out in the >> release notes, NEWS, and C API documentation. Maybe even provide an example >> #ifdef in the latter. >> >> Should we start thinking about releasing 2.6.6 soonish? > >By tradition, it should come out soon after 2.7 and be the last bugfix >(except for security patches). I guess what I mean is, should we have (at least) one more point release before the post-2.7 last-bug-fix-release? -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a new C API function in 2.6
Should we start thinking about releasing 2.6.6 soonish? By tradition, it should come out soon after 2.7 and be the last bugfix (except for security patches). I guess what I mean is, should we have (at least) one more point release before the post-2.7 last-bug-fix-release? Because it's a security fix? No. This issue has been sitting in the tracker for more than a year now, so it's not really relevant (IMO) whether the bug fix arrives two weeks earlier. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug or feature? fixing argparse's default help value for version actions
2010/5/20 Steven Bethard : > Sorry I haven't had time to get around to the argparse issues. I > should have time this weekend. I need a release manager call on one of > the issues though. Two things I assume are fine to fix at this stage: > > * In the documentation, the '--version' example should either not use > a shorthand, or should use the conventional '-V' > * In the documentation, the difference between the argparse and > optparse ways of specifying versions needs to be mentioned in the > section on migrating from optparse. Documentation changes are always okay. > Can this be considered a bug, i.e. something that can be committed > before the RC? Or does it need to be considered a feature, i.e. at > this point can never be added to Python 2.7? That sounds fine to me. > > Thanks, and sorry again for not having time for this until now, -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method
Ben Finney wrote: Something like "1 argument in addition to 'self'" would be reasonably clear and would cover both situations. Except that there's nothing special to the syntax or parser about the name ‘self’. That's true, but the use of the word 'self' here isn't meant to refer to the name of a parameter. The message is aimed at the caller of the function, who doesn't necessarily know or care what the parameter is actually called. The important thing is that it represents the object the method is being called for, and 'self' is the traditional term used when talking about that. I can't think of anything that would be more accurate without being excessively verbose or pedantic. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method
Floris Bruynooghe wrote: Not having looked at the code I don't know how hard it is for the code that raises this traceback to notice if it's a bound or unbound method tough. The way things currently work, it would be quite difficult. The exception is raised when attempting to call the function underlying the bound method, at which point it can't be distinguished from any other way of calling it. However, it could be made to raise a special subclass of TypeError that the bound method wrapper could catch and replace with its own exception. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method
Giampaolo Rodolà wrote: "unbound method echo() must be called with A instance as first argument (got nothing instead)" It talks about "arguments" while no arguments are actually involved in the problem: just a class I forgot to initialize. It's hard to see how this could be improved. If you had been intending to call an unbound method, the comment about arguments would have been relevant -- you were supposed to supply one but didn't. Python is unable to read your mind and figure out that you really meant something else altogether. BTW, unbound methods no longer exist in Py3, so you would get the standard message about incorrect number of arguments instead. Not sure whether that's better or worse in this situation. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method
On 20May2010 17:46, Ben Finney wrote: | Would it help if the traceback showed the ‘repr()’ of each of the | arguments received? That way it would be much clearer when the instance | was received as the first argument. I've occasionally passed large or deep dicts etc to functions and foolishly printed their repr in debug statements. They can be... wordy. Maybe a cropped repr, or the .__class__ attribute? -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ Every technical corrigendum is met by an equally troublesome new defect report. - Norman Diamond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method
Cameron Simpson writes: > On 20May2010 17:46, Ben Finney wrote: > | Would it help if the traceback showed the ‘repr()’ of each of the > | arguments received? That way it would be much clearer when the instance > | was received as the first argument. > > I've occasionally passed large or deep dicts etc to functions and > foolishly printed their repr in debug statements. They can be... > wordy. Maybe a cropped repr, or the .__class__ attribute? Okay. My main point is that I'm offering this as a way of avoiding a special-case message for method calls versus non-method calls. In Python, all function calls are essentially the same, and I think it's too complicated for the message to differ depending on the syntax used. Emitting the arguments in some form, or even the types of each argument, in the message would make it clearer without a special case. -- \ “We now have access to so much information that we can find | `\ support for any prejudice or opinion.” —David Suzuki, 2008-06-27 | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3148 ready for pronouncement
The PEP is here: http://www.python.org/dev/peps/pep-3148/ I think the PEP is ready for pronouncement, and the code is pretty much ready for submission into py3k (I will have to make some minor changes in the patch like changing the copyright assignment): http://code.google.com/p/pythonfutures/source/browse/#svn/branches/ feedback/python3/futures%3Fstate%3Dclosed The tests are here and pass on W2K, Mac OS X and Linux: http://code.google.com/p/pythonfutures/source/browse/branches/feedback/python3/test_futures.py The docs (which also need some minor changes) are here: http://code.google.com/p/pythonfutures/source/browse/branches/feedback/docs/index.rst Cheers, Brian___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reasons behind misleading TypeError message when passing the wrong number of arguments to a method
On Fri, 21 May 2010 10:53:16 am Greg Ewing wrote:
> Ben Finney wrote:
> >>Something like "1 argument in addition to 'self'" would be
> >> reasonably clear and would cover both situations.
> >
> > Except that there's nothing special to the syntax or parser about
> > the name ‘self’.
>
> That's true, but the use of the word 'self' here isn't meant
> to refer to the name of a parameter. The message is aimed at
> the caller of the function, who doesn't necessarily know or
> care what the parameter is actually called.
And who doesn't necessarily know that:
> The important thing is that it represents the object the method
> is being called for, and 'self' is the traditional term used
> when talking about that.
Referring to self in any such error message is going to confuse newbies,
and occasional Python programmers who use it without learning about
object oriented code. E.g. sys admins who use Python as a scripting
language without ever writing their own classes.
Error messages should be aimed at the least capable users (within
reason!) rather than the most capable, since the most capable are:
(1) less likely to make the error in the first place;
(2) more able to interpret the error message correctly;
(3) more likely to understand if the error relates to something "under
the hood"; and
(4) better able to debug the error even in the absence of a useful error
message.
Given this, it is better for the error message to relate to what
the "average" user most likely has in his source code (i.e. a bound
method) rather than what the better-than-average user occasionally uses
(an unbound method).
> I can't think of anything that would
> be more accurate without being excessively verbose or pedantic.
In Python 3.1, strings seem to behave more sensibly IMO:
>>> 'abc'.find()
Traceback (most recent call last):
File "", line 1, in
TypeError: find() takes at least 1 argument (0 given)
That looks right to me. I'm calling a *method* with zero arguments
inside the parentheses when I need to call it with one.
If I call it as an unbound method (yes, I know it's actually a function)
I get something more confusing:
>>> str.find('abc')
Traceback (most recent call last):
File "", line 1, in
TypeError: find() takes at least 1 argument (0 given)
While calling unbound methods isn't exactly rare, it is a more advanced
thing to do than calling bound methods. If we're stuck with confusing
messages, better to have it occur for the users who are more likely to
be able to interpret it, that is, those advanced enough to use unbound
methods rather than "ordinary" users.
Note that str avoids the "-1 argument" trap:
>>> str.find()
Traceback (most recent call last):
File "", line 1, in
TypeError: descriptor 'find' of 'str' object needs an argument
Classes behave in the opposite manner: the error message is technically
correct for the less common, more advanced case, but misleading for the
more common, simple case:
>>> class C:
... def method(self, x):
... return x+1
...
>>> C.method()
Traceback (most recent call last):
File "", line 1, in
TypeError: method() takes exactly 2 positional arguments (0 given)
This is exactly right, since C.method is a function object which takes
two arguments, self and x. Because this is a function, we can't change
this (not that we want to!) without impacting the errors you get when
calling functions not associated with a class.
>>> C().method()
Traceback (most recent call last):
File "", line 1, in
TypeError: method() takes exactly 2 positional arguments (1 given)
This is misleading, since C().method is a bound method which takes one
argument, x, not two. I find myself wishing that Python distinguished
between ArgumentError and other TypeErrors, so that the method wrapper
of bound methods could simply catch ArgumentError and subtract 1 from
each argument count.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documenting [C]Python's Internals
> > This link has all post concatenated together in reverse order of how they >> should be read. The tags link returns the same page. Does your blog software >> allow you to make a master post and update with new links as available? > > Ugh, either it doesn't or I couldn't find the feature (I'm using wordpress.com, if someone has advice, let me know). I can clumsily suggest scrolling from the end. Also see below about reworking this into a single multi-chapter document with coherent form. I would if I were qualified, but I an mot. One way to get people to help > with details is to publish mistakes. This happens all the time on > python-list ;-). Pre-review would be nice though. > I don't mind so much the 'humiliation' of published mistakes, but since I want this to be perceived as reference grade material, I prefer pre-review. Yesterday my first mistake was found (ugh), I published an 'Errata Policy' and will stick to it from now on (see the blog itself for details of the mistake). Thankfully, I've been approached already about pre-review, we'll see how this develops (this doesn't mean other people can't also offer themselves, six eyeballs are better than four). People have asked for an internals-doc since I started over a decade ago. A > coherent CPython3.2 Internals would be nice to have with the 3.2 release > next December or so, whether or not it was made 'official'. > I'm targeting py3k anyway, and while I expect a bug lull in my writing between early June and early September, I think December is a realistic date for me to have good coverage CPython 3.2's core and rework the content into a more reference-material-ish form. That said, working things into reference-material form could be significant work, so if python-dev doesn't show interest in this I think the blog posts are good enough. Other people, this is your queue to chime in and state your opinion about this appearing on python.org somewhere. Cheers! - Yaniv ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
