[Python-Dev] A Reminder : A Survey on Defect Management Practices in Free/Open Source Software
Sir/Madam I seek help from designers, developers, testers,defect fixers,project managers or playing any other key role in Free/Open Source software development or maintenence in carrying out a study to identify practices and problems of defect management in various Free/Open Source Software projects. The insights gained from the study can further help us to extract publicly accessible defect data and determine impact of defect management practices on software quality. Please spend a few minutes of your precious time to fill up the Questionnaire. The most of the questions follow multiple choice formats and are quite easy to answer. To have the Online Questionnaire, please visit: http://anu.puchd.ac.in/phpESP/public/survey.php?name=FOSS_Defect_Survey (You can also copy and paste this link into your browser, and hit the 'Return' key.) I hope you will find all the questions interesting and thought-provoking. Your answers will be kept anonymous.The data thus collected will only be used for research purpose.It would be nice if you may further refer this mail to others actively engaged with Free/Open Source Software development. If you have any query or suggestions then feel free to contact. Thank You With regards, Anu Gupta Senior Lecturer Department of Computer Science and Applications, Panjab University, Chandigarh. INDIA In case of any problem in accessing/using the above mentioned link please contact: E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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] Bundling decimal.py with Django
Apologies if this is a little off-topic for python-dev, but it seemed like the best place to ask and get the attention of those needed. I am championing a patch to improve Django's support for numeric types by using Decimals with numeric columns and floats with double precision columns, rather than the current rather unpredictable behaviour (which depends on the particular python version and database backend being used). It has been proposed[1] to include decimal.py from the Python 2.5 distribution with Django, to ensure consistent and compatible behaviour between Python 2.3 and Python >= 2.4[2]. Jacob Kaplan-Moss wrote in response to this proposal """ In order for this to be accepted, we need to know: * What is the license for the decimal module, and is said license compatible with the BSD license that Django uses? * Are the authors of the decimal module OK with us distributing it with Django? Our policy for including third party libraries requires an answer to both those questions. We won't include anything if it's not legal to do so, and we won't include anything that the original author doesn't want included. """ I'm addressing the second of Jacob's points here; would it be acceptable if the decimal module was distributed with Django? Andrew [1] http://groups.google.com/group/django-developers/msg/230892a9f9a71472 [2] Python's _threading_local.py module is already included with Django for the same compatibility reasons. ___ 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] Bundling decimal.py with Django
> What is the license for the decimal module, > and is said license compatible > with the BSD license that Django uses? It is the the same license as Python itself: http://www.python.org/psf/license/ > Are the authors of the decimal module OK > with usdistributing it with Django? You don't need my okay, but you've got it anyway. Per the source file, the listed authors are: # Written by Eric Price #and Facundo Batista #and Raymond Hettinger #and Aahz #and Tim Peters ___ 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] bool conversion wart?
>>> int ('4')
4
>>> bool ('False')
True
___
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] bool conversion wart?
On 2/23/07, Neal Becker <[EMAIL PROTECTED]> wrote:
> >>> bool ('False')
> True
>
Non-empty strings are considered True, empty strings are considered
False. This is not a wart, as the behaviour matches that of other
sequences.
cheers,
jml
___
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] bool conversion wart?
Jonathan Lange wrote:
> On 2/23/07, Neal Becker <[EMAIL PROTECTED]> wrote:
>> >>> bool ('False')
>> True
>>
>
> Non-empty strings are considered True, empty strings are considered
> False. This is not a wart, as the behaviour matches that of other
> sequences.
>
Well consider this:
>>>str (4)
'4'
>>>int(str (4))
4
>>>str (False)
'False'
>>>bool(str(False))
True
Doesn't this seem a bit inconsisent?
___
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] bool conversion wart?
On 2/22/07, Neal Becker <[EMAIL PROTECTED]> wrote:
> Well consider this:
> >>>str (4)
> '4'
> >>>int(str (4))
> 4
> >>>str (False)
> 'False'
>
> >>>bool(str(False))
> True
>
> Doesn't this seem a bit inconsisent?
Virtually no python objects accept a stringified version of themselves
in their constructor:
>>> str({})
'{}'
>>> dict('{}')
Traceback (most recent call last):
File "", line 1, in
ValueError: dictionary update sequence element #0 has length 1; 2 is required
>>> str([])
'[]'
>>> list('[]')
['[', ']']
Python is not Perl.
-Mike
___
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] bool conversion wart?
Mike Klaas wrote:
> On 2/22/07, Neal Becker <[EMAIL PROTECTED]> wrote:
>
>> Well consider this:
>> >>>str (4)
>> '4'
>> >>>int(str (4))
>> 4
>> >>>str (False)
>> 'False'
>>
>> >>>bool(str(False))
>> True
>>
>> Doesn't this seem a bit inconsisent?
>
> Virtually no python objects accept a stringified version of themselves
> in their constructor:
>
str({})
> '{}'
dict('{}')
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: dictionary update sequence element #0 has length 1; 2 is
> required
str([])
> '[]'
list('[]')
> ['[', ']']
>
> Python is not Perl.
>
Except, all the numeric types do, including int, float, and complex. But
not bool. In fact, this is not just academic. The fact that other numeric
types act this way leaves a reasonable expectation that bool will.
Instead, bool fails in _the worst possible way_: it silently gives a _wrong
result_.
___
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] bool conversion wart?
On 2/22/07, Neal Becker <[EMAIL PROTECTED]> wrote: > Except, all the numeric types do, including int, float, and complex. But > not bool. Oh? In [5]: str(complex(1, 2)) Out[5]: '(1+2j)' In [6]: complex(str(complex(1, 2))) --- : complex() arg is a malformed string > In fact, this is not just academic. The fact that other numeric > types act this way leaves a reasonable expectation that bool will. > Instead, bool fails in _the worst possible way_: it silently gives a _wrong > result_. I'd debate the assertion that 'bool' is a numeric type (despite being a subclass of int). For bool() to return anything other than the value of the python expression evaluated in boolean context would be _lunacy_ and there is absolutely no chance it that will be changed. -Mike ___ 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] bool conversion wart?
On 2/22/07, Neal Becker <[EMAIL PROTECTED]> wrote:
Mike Klaas wrote:
> On 2/22/07, Neal Becker <[EMAIL PROTECTED]> wrote:
>
>> Well consider this:
>> >>>str (4)
>> '4'
>> >>>int(str (4))
>> 4
>> >>>str (False)
>> 'False'
>>
>> >>>bool(str(False))
>> True
>>
>> Doesn't this seem a bit inconsisent?
>
> Virtually no python objects accept a stringified version of themselves
> in their constructor:
>
str({})
> '{}'
dict('{}')
> Traceback (most recent call last):
> File "", line 1, in
> ValueError: dictionary update sequence element #0 has length 1; 2 is
> required
str([])
> '[]'
list('[]')
> ['[', ']']
>
> Python is not Perl.
>
Except, all the numeric types do, including int, float, and complex. But
not bool. In fact, this is not just academic. The fact that other
numeric
types act this way leaves a reasonable expectation that bool will.
Instead, bool fails in _the worst possible way_: it silently gives a
_wrong
result_.
i agree with mike; it would just be asking for trouble. (have you ever been
bitten by the Perl behavior where the string '0' is considered false? it's
a nasty, nasty problem to debug.)
neal, you may be confusing the concepts of "convert data from one type to
another" and "read the printed representation of data".
ben
___
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] bool conversion wart?
Neal Becker wrote:
Instead, bool fails in _the worst possible way_: it silently gives a
_wrong result_.
I disagree with the word "fail" there; Python is working correctly. The
behavior of converting expressions to a boolean is well-defined:
http://docs.python.org/ref/Booleans.html
Perhaps the behavior is unexpected or unwelcome--but it is *correct*.
It's just one of those things about Python that one has to get used to;
this is a side-effect of another, much more important principle.
If you really want to turn the string "True" into True, use "eval".
eval("4") -> 4
eval("True") -> True
eval("{}") -> {}
Perhaps it would be safest to cast the output of eval to bool:
bool(eval("True")) -> True
bool(eval("")) -> False
Cheers,
/larry/
___
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] bool conversion wart?
Neal Becker writes: > Well consider this: > >>>str (4) > '4' > >>>int(str (4)) > 4 > >>>str (False) > 'False' > > >>>bool(str(False)) > True > > Doesn't this seem a bit inconsisent? The former case is a *conversion* from an expression that *does not* have an interpretation in a numerical context to an integer. The latter case is a *canonicalization* from an expression that *does* have an interpretation in a boolean context to the equivalent boolean constant. I don't have a problem with that. YMMV. ___ 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] bool conversion wart?
Larry Hastings wrote:
> Neal Becker wrote:
>> Instead, bool fails in _the worst possible way_: it silently gives a
>> _wrong result_.
>
> I disagree with the word "fail" there; Python is working correctly. The
> behavior of converting expressions to a boolean is well-defined:
> http://docs.python.org/ref/Booleans.html
> Perhaps the behavior is unexpected or unwelcome--but it is *correct*.
> It's just one of those things about Python that one has to get used to;
> this is a side-effect of another, much more important principle.
>
> If you really want to turn the string "True" into True, use "eval".
> eval("4") -> 4
> eval("True") -> True
> eval("{}") -> {}
> Perhaps it would be safest to cast the output of eval to bool:
> bool(eval("True")) -> True
> bool(eval("")) -> False
>
>
> Cheers,
>
> /larry/
In most cases like this you would not use string "True" or "False" but
instead values True or False.
In cases where you do have such strings You would probably be doing string
comparisons anyway because there will most likely be other values to consider.
if S == "True":
Or use a dictionary to get predetermined values of expected strings.
if svalues_dict["True"]: ...
To Neal:
Instead of being consistent with numeric types, bool is consistent in a
different way. Think of it as len() having precedence over value if that
helps.
>>> bool('')
False
>>> bool([])
False
>>> bool(())
False
>>> bool({})
False
>>> bool('anything')
True
>>> bool(['anything'])
True
>>> bool(('anything',))
True
>>> bool({'any':'thing'})
True
This is really useful because you can do simple if tests to see if
containers have anything in them.
if somestring: ...
if sometuple: ...
if somelist: ...
if somedict: ...
If they do have contents of some some type, you then need to test the
contents to see what is in them. Which might be a True or False values of
some type.
I suggest you take this to comp.lang.python to get further help with using
bool. It is a good idea to test thoughts like this out there first.
Cheers,
Ron
___
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] r53860 - peps/trunk/pep-0000.txt peps/trunk/pep-0358.txt
[-python-checkins, +python-dev]
On 2/22/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > __setitem__
> > __setslice__
> > append
> > count
> > +decode
> > +endswith
> > extend
> > +find
> > index
> > insert
> > +join
> > +partition
> > remove
> > +replace
> > +rindex
> > +rpartition
> > +split
> > +startswith
> > +rfind
> > +rindex
> > +rsplit
> > +translate
>
> What sort of arguments do they take?
You should be able to infer this from what the corresponding str or
list methods do -- always substituting bytes for those, and int for
the single element.
> Other bytes objects? (Then the literal is more important.)
>
> Unicode? With an extra decoding argument?
The only way to use unicode is to use bytes(, ).
The others methods barf on Unicode.
> Sequences of integers? Is startswith(500) False or a ValueException?
TypeError.
> Single integers? startswith(ord('A'))
TypeError (this is the same as the previous.)
> +Note the conspicuous absence of .isupper(), .upper(), and friends.
>
> This does force the use of more regular expressions, by ruling out
>
> data.upper().startswith("ERROR:")
Yeah, over dinner we started leaning towards perhaps supporting at
least lower() and upper() (but acting only on the 2x26 ASCII letters).
--
--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] bool conversion wart?
This won't change so just get used to it. Please move any further discussion to c.l.py. -- --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
