Mailman 3 November 2005 - Python-Dev

dev FAQ updated with day-to-day svn questions
by Brett Cannon 10 Nov '05

10 Nov '05

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 10 Nov '05

10 Nov '05

> > >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 like to write #f. I want to stay with decimals by default. (and I want decimals written in C) But it just an opinion of young inexperienced/unpractised man. Excuse my English.

1 0

(no subject)
by Michael Chermside 10 Nov '05

10 Nov '05

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 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

1 0

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

10 Nov '05

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 >point of zipimport. It's not done (usually) for the compression but >for the index. Finding a name in the zipfile index is much more >efficient than doing a directory search; and the zip index can be >cached. zipimport also helps distribution convenience - a large and elaborate package can be distributed in a single zipfile (such as is built by setuptools' "bdist_egg" command) and simply placed on PYTHONPATH or directly on sys.path. And tools like py2exe can also append all an application's modules to an executable file in zipped form.

6 10

Inconsistent behaviour in import/zipimport hooks
by Osvaldo Santana Neto 10 Nov '05

10 Nov '05

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: No module named module_c >>> import module_o $ rm *.pyc *.pyo $ PYTHONPATH=modules.zip python >>> import module_c module_c >>> import module_o module_o $ PYTHONPATH=modules.zip python -O >>> import module_c module_c >>> import module_o module_o I've create a patch suggestion to remove this inconsistency[3] (*I* think zipimport behaviour is better). [1] http://pymaemo.sf.net/ [2] http://www.maemo.org/ [3] http://python.org/sf/1346572 -- Osvaldo Santana Neto (aCiDBaSe) icq, url = (11287184, "http://www.pythonbrasil.com.br")

7 16

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

10 Nov '05

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 either patch this to a plain jump, or compact the bytecode to remove the jumped-over part(s). By the way, while we're on this subject, can we make the optimization options be part of the compile() interface? Right now the distutils has to actually exec another Python process whenever you want to compile code with a different optimization level than what's currently in effect, whereas if it could pass the desired level to compile(), this wouldn't be necessary.

2 1

Unifying decimal numbers.
by Sokolov Yura 09 Nov '05

09 Nov '05

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) interpret float constants with suffix 'f' as float (like 1.5f 345.2e-5f etc) c) result of operation with decimal operands should be decimal >>> 1.0/3.0 0.33333333333333333 d) result of operation with float operands should be float >>> 1.0f/3.0f 0.33333333333333331f 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

1 0

PEP submission broken?
by Bryan Olson 08 Nov '05

08 Nov '05

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 SourceForge; the resolution was to document the actual behavior. Next I worked out what behavior I think would eliminate the wart, wrote it up as a pre-PEP, and sent it peps(a)python.org on 27 Aug of this year. I promptly received an automated response from Barry Warsaw, saying, in part, "I get so much email that I can't promise a personal response." I gathered that he is a PEP editor. I did not infer from his reply that PEP's are simply ignored, but this automated reply was the only response I ever received. I subscribed to the Python-dev list, and watched, and waited; nothing on my concern appeared. One response on the comp.lang.python newsgroup noted that a popular extention module would have difficulty maintaining consistency with my proposed PEP. My proposal does not break how the extension currently works, but still, that's a valid point. There are variations which do not have that problem, and I think I can see a course that will serve the entire Python community. From what I can tell, We need to address fixing the PEP process before there is any point in working on PEP's, -- --Bryan

3 2

Re: [Python-Dev] PEP submission broken?
by David Goodger 08 Nov '05

08 Nov '05

[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 08 Nov '05

08 Nov '05

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