Mailman 3 November 2005 - Python-Dev

dev FAQ updated with day-to-day svn questions
by Brett Cannon Nov. 10, 2005

Nov. 10, 2005

I just finished fleshing out the dev FAQ (http://www.python.org/dev/devfaq.html) with questions covering what someone might need to know for regular usage. If anyone thinks I didn't cover something I should have, let me know. -Brett

4 6

(no subject)
by Sokolov Yura Nov. 10, 2005

Nov. 10, 2005

> > >Mixing Decimal and float is nearly ALWAYS a user error. Doing it correctly >requires significant expertise in the peculiarities of floating point >representations. > So that I think user should declare floats explicitly (###.###f) - he will fall into float space only if he wish it. >So Python protects the user by throwing exceptions when >attempts are made to mix Decimal and floats. I hate it. I want to get float when I wish to get float. In that case i would … [View More]

1 0

(no subject)
by Michael Chermside Nov. 10, 2005

Nov. 10, 2005

Sokolov Yura writes: > Excuse my English No problem. You command of english probably exceeds my command of any other language. > I think, we could just segregate tokens for decimal and real float and > make them interoperable. > Most of us works with business databases - all "floats" are really > decimals, algebraic operations > should work without float inconsistency and those operations rare so > speed is not important. > But some of us use floats for speed in … [View More]scientific and multimedia programs. I'm not sure why you say "most" (have you seen some surveys of Python programmers that I haven't seen?), but I think we all agree that there are Python users who rarely have a need for machine floats, and others who badly need them. I'll take your specific suggestions out of order: > with "from __future__ import Decimal" we could: > c) result of operation with decimal operands should be decimal > >>> 1.0/3.0 > 0.33333333333333333 This already works. > d) result of operation with float operands should be float > >>> 1.0f/3.0f > 0.33333333333333331f This already works. > e) result of operation with decimal and float should be float (decimal > converts into float and operation perfomed) > >>> 1.0f/3.0 > 0.33333333333333331f > >>> 1.0/3.0f > 0.33333333333333331f Mixing Decimal and float is nearly ALWAYS a user error. Doing it correctly requires significant expertise in the peculiarities of floating point representations. So Python protects the user by throwing exceptions when attempts are made to mix Decimal and floats. This is the desired behavior (and the experts already know how to work around it in the RARE occasions when they need to). > a) interpret regular float constants as decimal > b) interpret float constants with suffix 'f' as float (like 1.5f > 345.2e-5f etc) There are two different ideas here, which I will separate. The first is a proposal that there be a way to provide Decimal literals. The second proposal is that the ###.### be the literal for Decimals and that ###.###f be the literal for floats. I'm in favor of the first idea. Decimals are useful enough that it would be a good idea to provide some sort of literal for their use. This is well worth a PEP. But if we DO agree that we ought to have literals for both floats and Decimals, then we also need to decide which gets the coveted "unadorned decimal literal" (ie, ###.###). Performance argues in favor of floats (they run *MUCH* faster). Usability (particularly for beginners) argues in favor of Decimals (they sometimes still have surprising behavior, but less often than with binary floats). And backward compatibility argues in favor of floats. Myself, I'm an "expert" user (at least to this extent) and I could easily handle either choice. If others felt like me, then its likely that the backward compatibility argument and the need to fight the pervasive meme that "Python is slow" will win the day. -- Michael Chermside [View Less]

1 0

Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
by Phillip J. Eby Nov. 10, 2005

Nov. 10, 2005

At 11:32 AM 11/9/2005 -0800, Guido van Rossum wrote: >On 11/9/05, Osvaldo Santana <osantana(a)gmail.com> wrote: > > I've noticed this inconsistency when we stop to use zipimport in our > > Python For Maemo distribution. We've decided to stop using zipimport > > because the device (Nokia 770) uses a compressed filesystem. > >I won't comment further on the brainstorm that's going on (this is >becoming a topic for c.l.py) but I think you are misunderstanding the … [View More]

6 10

Inconsistent behaviour in import/zipimport hooks
by Osvaldo Santana Neto Nov. 9, 2005

Nov. 9, 2005

Hi, I'm working on Python[1] port for Maemo Platform[2] and I've found a inconsistent behavior in zipimport and import hook with '.pyc' and '.pyo' files. The shell section below show this problem using a 'module_c.pyc', 'module_o.pyo' and 'modules.zip' (with module_c and module_o inside): $ ls module_c.pyc module_o.pyo modules.zip $ python >>> import module_c >>> import module_o ImportError: No module named module_o $ python -O >>> import module_c ImportError: … [View More]

7 16

Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
by Phillip J. Eby Nov. 9, 2005

Nov. 9, 2005

At 03:25 PM 11/9/2005 -0800, Guido van Rossum wrote: >The only solutions I can think of that use a single file actually >*increase* the file size by having unoptimized and optimized code >side-by-side, or some way to quickly skip the assertions -- the -OO >option is a special case that probably needs to be done differently >anyway and only for final distribution. We could have a "JUMP_IF_NOT_DEBUG" opcode to skip over asserts and "if __debug__" blocks. Then under -O we could … [View More]

2 1

Unifying decimal numbers.
by Sokolov Yura Nov. 9, 2005

Nov. 9, 2005

Excuse my English I think, we could just segregate tokens for decimal and real float and make them interoperable. Motivation: Most of us works with business databases - all "floats" are really decimals, algebraic operations should work without float inconsistency and those operations rare so speed is not important. But some of us use floats for speed in scientific and multimedia programs. with from __future__ import Decimal we could: a) interpret regular float constants as decimal b) … [View More]

1 0

PEP submission broken?
by Bryan Olson Nov. 8, 2005

Nov. 8, 2005

Though I tried to submit a (pre-) PEP in the proper form through the proper channels, it has disappeared into the ether. In building a class that supports Python's slicing interface, http://groups.google.com/group/comp.lang.python/msg/8f35464483aa7d7b I encountered a Python bug, which, upon further discussion, seemed to be a combination of a wart and a documentation error. http://groups.google.com/group/comp.lang.python/browse_frm/thread/402d770b6… I submitted the bug report via … [View More]

3 2

Re: [Python-Dev] PEP submission broken?
by David Goodger Nov. 8, 2005

Nov. 8, 2005

[Bryan Olson] > Though I tried to submit a (pre-) PEP in the proper form through the > proper channels, it has disappeared into the ether. Indeed, it has; I can't find it in my mailbox. Could you re-send the latest text? I'll review it right away. > From what I can tell, We need to address fixing the > PEP process before there is any point in working on PEP's, Email is imperfect; just send it again. And "fakeaddress(a)nowhere.org" doesn't help ;-) -- David Goodger <http://python.net/~goodger>

1 0

Unifying decimal numbers.
by winlinchu Nov. 8, 2005

Nov. 8, 2005

Now, Python unified ints and long ints. For Python 3k, could be introduced a "Decimal" type (yes, Decimal, the library module!) in place of the actual float object. Of course, the Decimal type would be rewritten in C. Thanks. ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.messenger.yahoo.com

3 2