Re: [pygccxml-development] Serious bug in pygccxml (scopedef.py)

[Roman Y. <rom...@gm...>]

On 3/15/06, Matthias Baas <ba...@ir...> wrote:
> But if those special =3D=3D and !=3D operators are only required for unit
> testing, wouldn't it then be better to move them to the unit tests and
> keep the standard operators for the regular users? From what I've seen
> the operators implement rather expensive operations (copying, sorting,
> comparing several values, etc.) and if this could just as well be done
> by comparing the reference of the instance, this would be much more
> efficient.

I can argue about this point, but I understand you.

> >> But I think for someone else reading the code this is not really
> >> obvious why I have to do that...
> >
> > Matthias, it is not the first time I provide "not so user friendly" int=
erface.
> > Can you show some code you have to write now and how I think it should
> > be written.
>
> It's in the __call__() method of the ParentFilter class in
> experimental/filters.py. First, the method looked like this:
>
>      def __call__(self, decl):
>          return decl.parent=3D=3Dself.parent
>
> Because of the bug in the =3D=3D operator I had a look at the implementat=
ion
> and found out that the operator is doing quite a lot things. With the
> latest fix you've applied to scopedef.py the above code would work
> again, but it would not be as efficient as the following line:
>
>          return id(decl.parent)=3D=3Did(self.parent)

:-)  return decl.parent is self.decl.parent is it better ? :-)))))

> >> PS: I also don't understand the purpose of the (static!) method
> >> _sorted_list() as this method just calls sort() and does nothing else.
> >> Why wasn't sort() used in the first place?
> >
> > Convenience. Python sorts list in place and return value of sort
> > function is None.
> > This function allows you to write something like this:
> >
> > soorted_list ( x ) =3D=3D sorted_list( y )
> >
> > while without function you need to write
> >
> > x.sort()
> > y.sort()
> > x =3D=3D y
>
> ok, I see. But sorted_list() has the side effect of modifying its
> argument (which might not have been intentional). That's why the Python
> developers chose not to return the list from sort() (see note (7) here:
> http://docs.python.org/lib/typesseq-mutable.html)
> Maybe the semantics you actually had in mind was this:
>
>      def _sorted_list( some_list ):
>          result =3D copy.copy(some_list)
>          result.sort()
>          return result
>
> But of course, this makes the operation more expensive...

I prefer expensive and work, to quick and may be work :-)

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/