Re: starting to dive into python package bugs

2013-07-17 Thread Stéphane Blondon
2013/7/16 Thomas Kluyver tho...@kluyver.me.uk:
 I would be inclined *not* to use BaseException for this - the intention is
 that 'except Exception:' should catch all normal exceptions, and only
 KeyboardInterrupt and SystemExit are outside that. I don't know the
 specifics of the string exceptions you're updating, but almost anything that
 Python code explicitly raises should inherit from Exception.

I agree. I sent a new patch on the same bug report (#585291) to raise Exception.


-- 
Imprimez ce message en A2 et en couleur au moins 500 fois!
Brûlez des arbres!!

-- envoyé depuis ma centrale à charbon
Stéphane


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caoy+up7-nguvao-4bqtwrgymr-vnusayta2k+v-+znraxso...@mail.gmail.com



Re: starting to dive into python package bugs

2013-07-16 Thread Thomas Kluyver
On 16 July 2013 22:25, Stéphane Blondon stephane.blon...@gmail.com wrote:

  I checked the string exceptions in the code and they are not catched
  (see shell commands used at this end of this message).
  So I plan to wrap the string with an exception (Exception ou
  TypeError). To me, the errors raised are not TypeError so it's not the
  appropriate exception but if someone catched TypeError in another
  software (outside Debian) it will work. It would not work with
  Exception class. However, I still prefer raising Exception. Does
  anyone have an opinion about that point?
 

 Finally, I used BaseException. I added a patch to the bug report (#585291):


I would be inclined *not* to use BaseException for this - the intention is
that 'except Exception:' should catch all normal exceptions, and only
KeyboardInterrupt and SystemExit are outside that. I don't know the
specifics of the string exceptions you're updating, but almost anything
that Python code explicitly raises should inherit from Exception.

Thomas


Re: starting to dive into python package bugs

2013-07-06 Thread Stéphane Blondon
Thanks for your replies Barry and Thomas!

According to apt-rdepends, there are no packages depending on python-forgetsql:

$ apt-rdepends --reverse python-forgetsql
Reading package lists... Done
Building dependency tree
Reading state information... Done
python-forgetsql

So it will simpler to fix! :-)


2013/7/3 Thomas Kluyver tho...@kluyver.me.uk:
 On 3 July 2013 19:36, Barry Warsaw ba...@debian.org wrote:
 except 'error message'

 this will fail if the raise site is changed.

 In fact it will already fail - recent Python 2 versions throw a TypeError if
 you attempt to raise a bare string (from at least 2.6 - I don't have older
 versions to check). Changing the exception could still lead to it getting
 caught by an except: clause which previously missed it, though.

I checked the string exceptions in the code and they are not catched
(see shell commands used at this end of this message).
So I plan to wrap the string with an exception (Exception ou
TypeError). To me, the errors raised are not TypeError so it's not the
appropriate exception but if someone catched TypeError in another
software (outside Debian) it will work. It would not work with
Exception class. However, I still prefer raising Exception. Does
anyone have an opinion about that point?


Other infos about this package:
 - I sent a bug report about the 404 error on the homepage of the
project (#715148).
 - I think other infos in control file are outdated:
Conflicts: python2.3-forgetsql
Replaces: python2.3-forgetsql
Provides: python2.5-forgetsql, python2.6-forgetsql

python2.3 are not in the repository anymore so the Conflicts and
Replaces lines could be deleted. I suppose we should add a
'python2.7-forgetsql' element to the Provides line.
What do you think about this point too?


Search with the shell:
$ grep -R raise .
./share/doc/python-forgetsql/TODO:   raise TimeOutException ?
./share/doc/python-forgetsql/TODO:   Try a passive reload, and only
raise exception if something has
./share/pyshared/forgetSQL.py:  raise cursor method undefined, no
database connection could be made
./share/pyshared/forgetSQL.py:raise NotFound
./share/pyshared/forgetSQL.py:raise NotFound
./share/pyshared/forgetSQL.py:raise NotFound
./share/pyshared/forgetSQL.py:raise 'Not enough id fields,
required: %s' % len(self._sqlPrimary)
./share/pyshared/forgetSQL.py:  raise 'Not enough id fields,
required: %s' % len(self._sqlPrimary)
./share/pyshared/forgetSQL.py:  raise Unsupported: Part %s of
%s primary key is a reference to %s, with multiple-primary-key %s  %
(key, self.__class__, value.__class__, value)
./share/pyshared/forgetSQL.py:  raise AttributeError, key
./share/pyshared/forgetSQL.py:raise ERROR: No fields
defined, cannot create SQL.
./share/pyshared/forgetSQL.py:raise REALITY ERROR: No tables defined
./share/pyshared/forgetSQL.py:  raise Unknown operation, operation
./share/pyshared/forgetSQL.py:raise Could not guess sequence
name for multi-primary-key
./share/pyshared/forgetSQL.py:  raise NotFound, self._getID()
./share/pyshared/forgetSQL.py:  raise NotFound, self._getID()
./share/pyshared/forgetSQL.py:  raise Unsupported: Can't
reference multiple-primary-key: %s % value
./share/pyshared/forgetSQL.py:raise Bad sqlPrimary, should be
a list or tupple: %s % cls._sqlPrimary
./share/pyshared/forgetSQL.py:  raise No field found, check
forgetter's _userClasses
./share/pyshared/forgetSQL.py:  raise Can't reference
multiple-primary-key: %s % value
./share/pyshared/forgetSQL.py: raise Can't retrieve
auto-inserted ID for multiple-primary-key

$ grep -R Not enough id fields, required:  .
./share/pyshared/forgetSQL.py:raise 'Not enough id fields,
required: %s' % len(self._sqlPrimary)
./share/pyshared/forgetSQL.py:  raise 'Not enough id fields,
required: %s' % len(self._sqlPrimary)
$ grep -R Unsupported: Part  .
./share/pyshared/forgetSQL.py:  raise Unsupported: Part %s of
%s primary key is a reference to %s, with multiple-primary-key %s  %
(key, self.__class__, value.__class__, value)
$ grep -R ERROR: No fields defined, cannot crea .
./share/pyshared/forgetSQL.py:raise ERROR: No fields
defined, cannot create SQL.
$ grep -R REALITY ERROR: No tables defined .
./share/pyshared/forgetSQL.py:raise REALITY ERROR: No tables defined
$ grep -R Unknown operation .
./share/pyshared/forgetSQL.py:  raise Unknown operation, operation
$ grep -R Could not guess sequence name for multi-primary-key .
./share/pyshared/forgetSQL.py:raise Could not guess sequence
name for multi-primary-key
$ grep -R Unsupported: Can't reference multiple-primary-ke .
./share/pyshared/forgetSQL.py:  raise Unsupported: Can't
reference multiple-primary-key: %s % value
$ grep -R Bad sqlPrimary, should be a list or tupple .
./share/pyshared/forgetSQL.py:raise Bad sqlPrimary, should be
a list or tupple: %s % cls._sqlPrimary
$ grep 

Re: starting to dive into python package bugs

2013-07-03 Thread Thomas Kluyver
On 3 July 2013 19:36, Barry Warsaw ba...@debian.org wrote:

 The reason is that if some code is trying to:

 except 'error message'

 this will fail if the raise site is changed.


In fact it will already fail - recent Python 2 versions throw a TypeError
if you attempt to raise a bare string (from at least 2.6 - I don't have
older versions to check). Changing the exception could still lead to it
getting caught by an except: clause which previously missed it, though.

Thomas