Things are getting better, but we still have some really important
outstanding issues. PLEASE CONTINUE TESTING AS MUCH AS POSSIBLE.
Also, it would be great to use as many tools as possible to find bugs
and improve quality. It would be especially nice to run Purify on
Windows.
I've updated PEP 35
On 8/3/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> As an alternate idea, rather than attempting to .decode('ascii') when
> strings and unicode compare, why not .decode('latin-1')? We lose the
> unicode decoding error, but "the right thing" happens (in my opinion)
> when u'\xa1' and '\xa1' comp
The trunk is unfrozen now. Sorry about the delay - combination of a laptop
motherboard replacement and a DSL provider with a network that was .. ahem...
slightly slow.
I'm still planning to branch at 2.5c1, the next release. That then opens the
trunk up for all the bad craziness that's planned
On Thu, 03 Aug 2006 21:34:04 -0700, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
>Bob Ippolito <[EMAIL PROTECTED]> wrote:
>> On Aug 3, 2006, at 6:51 PM, Greg Ewing wrote:
>>
>> > M.-A. Lemburg wrote:
>> >
>> >> Perhaps we ought to add an exception to the dict lookup mechanism
>> >> and continue to s
On behalf of the Python development team and the Python
community, I'm happy to announce the third BETA release
of Python 2.5.
This is an *beta* release of Python 2.5. As such, it is not
suitable for a production environment. It is being released
to solicit feedback and hopefully discover bugs, as
On Aug 4, 2006, at 12:34 AM, Josiah Carlson wrote:
> As an alternate idea, rather than attempting to .decode('ascii') when
> strings and unicode compare, why not .decode('latin-1')? We lose the
> unicode decoding error, but "the right thing" happens (in my opinion)
> when u'\xa1' and '\xa1' compa
Bob Ippolito <[EMAIL PROTECTED]> wrote:
> On Aug 3, 2006, at 6:51 PM, Greg Ewing wrote:
>
> > M.-A. Lemburg wrote:
> >
> >> Perhaps we ought to add an exception to the dict lookup mechanism
> >> and continue to silence UnicodeErrors ?!
> >
> > Seems to be that comparison of unicode and non-unicod
On Tue, Aug 01, 2006, Ron Adam wrote:
>
> I'm -1 on implicitly converting to an int when rounding.
>
> One reason is if your rounded (to int type) number is then used in an
> equation you my end up with a integer result when you wanted a floating
> point result.
>
> >>> 23.5/5.2
> 4.5192307692
On Aug 3, 2006, at 6:51 PM, Greg Ewing wrote:
> M.-A. Lemburg wrote:
>
>> Perhaps we ought to add an exception to the dict lookup mechanism
>> and continue to silence UnicodeErrors ?!
>
> Seems to be that comparison of unicode and non-unicode
> strings for equality shouldn't raise exceptions in t
On Aug 3, 2006, at 2:34 AM, Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>> -1 on an extra built-in just to save the time for function call
>
> The time isn't the main issue. The main issue
> is that almost all the use cases for round()
> involve doing an int() on it afterwards. At
> least nobo
On Aug 3, 2006, at 5:47 PM, M.-A. Lemburg wrote:
>> The only way this error could be the right thing is if you were
>> trying
>> to suggest that he shouldn't mix unicode and bytestrings at all.
>
> Good question. I wonder whether that's a reasonable approach for
> Python 2.x (I'd say it is for Py
M.-A. Lemburg wrote:
> Perhaps we ought to add an exception to the dict lookup mechanism
> and continue to silence UnicodeErrors ?!
Seems to be that comparison of unicode and non-unicode
strings for equality shouldn't raise exceptions in the
first place.
--
Greg
_
M.-A. Lemburg wrote:
> If you are eventually rounding to say 2 decimal
> places in the end of the calculation, you won't
> want to find yourself presenting the user 1.12
> and 1.13 as equal values :-)
Even if, before rounding, they were actually
1.124 and 1.1251? And if the
differ
On 8/3/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> > ...but in the case of dictionaries this behaviour has changed and in
> > prior versions of python dictionaries did work as I expected them to.
> > Now they don't.
>
> Let's put it this way: Python 2.5 uncovered a bug in your
> application that
"Werkhoven J.P. van (Sjaak)" <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]
> I have got a problem with importing global variables.
Questions about using Python belong on comp.lang.python or the general
python mailing list.
___
Python-Dev mail
The UUID module uses network byte order, regardless of the platform
byte order. On little-endian platforms like Windows the ".bytes"
property of UUID objects is not compatible with the memory layout of
UUIDs:
>>> import uuid
>>> import pywintypes
>>> s = '{00112233-4455-6677-8899-aabbccddeeff}'
>>
Hi,
I have got a problem with importing global variables. For instance I have
got two files:
# t1.py #t2.py
counter = 1
def counter_adder(filenr): def
show_adder():
global counte
Nick Coghlan wrote:
> Nick Coghlan wrote:
>> Armin Rigo wrote:
>>> Hi,
>>>
>>> There is an oversight in the design of __index__() that only just
>>> surfaced :-( It is responsible for the following behavior, on a 32-bit
>>> machine with >= 2GB of RAM:
>>>
>>> >>> s = 'x' * (2**100) # wor
M.-A. Lemburg wrote:
> Perhaps we ought to add an exception to the dict lookup mechanism
> and continue to silence UnicodeErrors ?!
I'd definitely consider a UnicodeError to be an indication that two
objects are not equal. At the very least, in the context of a dictionary
lookup.
Tim Delaney
___
Nick Coghlan wrote:
> Ron Adam wrote:
>> Consider an example where you are combining data that had different
>> number of significant digits. Keeping all the digits of your answer
>> gives a false since of accuracy. The extra digits are meaningless
>> because the margin of error is greater tha
Jim Jewett wrote:
> http://mail.python.org/pipermail/python-dev/2006-August/067934.html
> M.-A. Lemburg mal at egenix.com
>
>> Ralf Schmitt wrote:
>>> Still trying to port our software. here's another thing I noticed:
>
>>> d = {}
>>> d[u'm\xe1s'] = 1
>>> d['m\xe1s'] = 1
>>> print d
>
> (a 2-ele
http://mail.python.org/pipermail/python-dev/2006-August/067934.html
M.-A. Lemburg mal at egenix.com
> Ralf Schmitt wrote:
>> Still trying to port our software. here's another thing I noticed:
>> d = {}
>> d[u'm\xe1s'] = 1
>> d['m\xe1s'] = 1
>> print d
(a 2-element dictionary, because they are no
Ronald Oussoren <[EMAIL PROTECTED]> wrote:
>
> > There are algorithms where the operation of rounding (or truncation)
> > is needed, but where the value may be larger than can be held in an
> > integer, and that is not an error.
>
> Is that really true for python? Python integers are unbounded in
On Aug 3, 2006, at 9:43 PM, Nick Maclaren wrote:
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
That's my experience as well. In my opinion, the purpose of round()
is most commonly described as "to make an integer". So it should
yield an integer.
Grrk. No, that logic is flawed.
There are algori
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>
> That's my experience as well. In my opinion, the purpose of round()
> is most commonly described as "to make an integer". So it should
> yield an integer.
Grrk. No, that logic is flawed.
There are algorithms where the operation of rounding (or truncat
On Thu, 3 Aug 2006, Greg Ewing wrote:
> The time isn't the main issue. The main issue
> is that almost all the use cases for round()
> involve doing an int() on it afterwards.
That's my experience as well. In my opinion, the purpose of round()
is most commonly described as "to make an integer".
John J Lee wrote:
> On Thu, 3 Aug 2006, M.-A. Lemburg wrote:
> [...]
>> It's actually a good preparation for Py3k where 1 == u'abc' will
>> (likely) also raise an exception.
>
> I though I'd heard (from Guido here or on the py3k list) that it was only
> 1 < u'abc' that would raise an exception, a
Martin v. Löwis wrote:
> Ralf Schmitt schrieb:
>> I've been trying to port our software to python 2.5.
>> unfortunately I'm getting constantly hit by segfaults.
>
> I understand it's unfortunate for you, but it is fortunate
> for us that you have been trying to port your application
> before 2.5 w
On Thu, 3 Aug 2006, M.-A. Lemburg wrote:
[...]
> It's actually a good preparation for Py3k where 1 == u'abc' will
> (likely) also raise an exception.
I though I'd heard (from Guido here or on the py3k list) that it was only
1 < u'abc' that would raise an exception, and that 1 == u'abc' would stil
Ralf Schmitt wrote:
Still trying to port our software. here's another thing I noticed:
d = {}
d[u'm\xe1s'] = 1
d['m\xe1s'] = 1
print d
With python 2.5 I get:
$ python2.5 t2.py
Traceback (most recent call last):
File "t2.py", line 3, in
Greg Ewing wrote:
> The time isn't the main issue. The main issue
> is that almost all the use cases for round()
> involve doing an int() on it afterwards. At
> least nobody has put forward an argument to
> the contrary yet.
Or, more accurately, they *should* involve an int
afterwards, but often
M.-A. Lemburg wrote:
> Ralf Schmitt wrote:
>> Ralf Schmitt wrote:
>>> Still trying to port our software. here's another thing I noticed:
>>>
>>> d = {}
>>> d[u'm\xe1s'] = 1
>>> d['m\xe1s'] = 1
>>> print d
>>>
>>> With python 2.4 I can add those two keys to the dictionary and get:
>>> $ python2.4 t2
Ralf Schmitt schrieb:
> I've been trying to port our software to python 2.5.
> unfortunately I'm getting constantly hit by segfaults.
I understand it's unfortunate for you, but it is fortunate
for us that you have been trying to port your application
before 2.5 was released, and reported the bug w
On Aug 3, 2006, at 9:51 AM, M.-A. Lemburg wrote:
> Ralf Schmitt wrote:
>> Ralf Schmitt wrote:
>>> Still trying to port our software. here's another thing I noticed:
>>>
>>> d = {}
>>> d[u'm\xe1s'] = 1
>>> d['m\xe1s'] = 1
>>> print d
>>>
>>> With python 2.4 I can add those two keys to the dictiona
Ralf Schmitt wrote:
> Ralf Schmitt wrote:
>> Still trying to port our software. here's another thing I noticed:
>>
>> d = {}
>> d[u'm\xe1s'] = 1
>> d['m\xe1s'] = 1
>> print d
>>
>> With python 2.4 I can add those two keys to the dictionary and get:
>> $ python2.4 t2.py
>> {u'm\xe1s': 1, 'm\xe1s': 1
Duncan Booth <[EMAIL PROTECTED]> writes:
> Does Coverity recognise objects on Python's internal pools as deallocated?
Coverity doesn't work on that level; it analyzes source code, and
knows about Python's INCREFs and DECREFs.
> The moral is to regard the reference counting rules as law: no matt
Ralf Schmitt wrote:
> Still trying to port our software. here's another thing I noticed:
>
> d = {}
> d[u'm\xe1s'] = 1
> d['m\xe1s'] = 1
> print d
>
> With python 2.4 I can add those two keys to the dictionary and get:
> $ python2.4 t2.py
> {u'm\xe1s': 1, 'm\xe1s': 1}
>
> With python 2.5 I get:
Still trying to port our software. here's another thing I noticed:
d = {}
d[u'm\xe1s'] = 1
d['m\xe1s'] = 1
print d
With python 2.4 I can add those two keys to the dictionary and get:
$ python2.4 t2.py
{u'm\xe1s': 1, 'm\xe1s': 1}
With python 2.5 I get:
$ python2.5 t2.py
Traceback (most recent ca
Duncan Booth wrote:
>
>
> The moral is to regard the reference counting rules as law: no matter how
> sure you are that you can cheat, don't or you'll regret it.
>
Or someone else will regret it, just like in this case. :)
- Ralf
___
Python-Dev mai
Thomas Heller <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
>> /* if no docstring given and the getter has one, use that one */
>> if ((doc == NULL || doc == Py_None) && get != NULL &&
>> PyObject_HasAttrString(get, "__doc__")) {
>> if (!(get_doc = PyObject_Ge
> /* if no docstring given and the getter has one, use that one */
> if ((doc == NULL || doc == Py_None) && get != NULL &&
> PyObject_HasAttrString(get, "__doc__")) {
> if (!(get_doc = PyObject_GetAttrString(get, "__doc__")))
> return -1;
>
Ralf Schmitt schrieb:
> Hi all,
>
> I've been trying to port our software to python 2.5.
> unfortunately I'm getting constantly hit by segfaults.
>
> I've boiled it down to the following code:
>
> [EMAIL PROTECTED]:~/bug$ cat t.py
> import array
>
> class Indexer(object):
> maximumForwardS
Hi all,
I've been trying to port our software to python 2.5.
unfortunately I'm getting constantly hit by segfaults.
I've boiled it down to the following code:
[EMAIL PROTECTED]:~/bug$ cat t.py
import array
class Indexer(object):
maximumForwardSize = property(array.array.fromstring)
[EMAIL
Ron Adam wrote:
> Consider an example where you are combining data that had different
> number of significant digits. Keeping all the digits of your answer
> gives a false since of accuracy. The extra digits are meaningless
> because the margin of error is greater than any of the digits that
Nick Maclaren <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Christian Tanzer) wrote:
> > Greg Ewing <[EMAIL PROTECTED]> wrote:
> >
> > > What's the feeling about this? If, e.g. int()
> > > were changed in Py3k to round instead of truncate,
> > > would it cause anyone substantial pain?
> >
> > G
James Y Knight <[EMAIL PROTECTED]> wrote:
>
> I'd be happy to see floats lose their __int__ method entirely,
> replaced by an explicit truncate function.
Come back Algol - all is forgiven :-) Yes, indeed. I have favoured
that view for 35 years - anything that can lose information quietly
shoul
Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>> -1 on an extra built-in just to save the time for function call
>
> The time isn't the main issue. The main issue
> is that almost all the use cases for round()
> involve doing an int() on it afterwards. At
> least nobody has put forward an argume
Greg Ewing wrote:
> M.-A. Lemburg wrote:
>
>> Believe me: you have to if you want to do more
>> advanced calculus related to pricing and risk
>> analysis of derivatives.
>
> When you do things like that, you're treating
> money as though it were a continuous quantity.
> This is an approximation,
48 matches
Mail list logo
