Mailman 3 June 2004 - Python-Dev

RE: [Python-Dev] Comparing heterogeneous types
by Batista, Facundo 24 Jun '04

24 Jun '04

#- > I maintain that when comparing a long with a float #- > where the exponent is larger than the precision, that the #- > float should be treated as if it were EXACTLY EQUAL TO #- > <coefficient>*2^<exponent>, instead of trying to treat it as #- > some sort of a range. Similarly, if we implemented a Rational #- > type, I would suggest that instances of float (or of Facundo's #- > Decimal) where <exponent> is LESS than the digits of #- > <coefficient> should be treated as if they were EXACTLY EQUAL #- > TO the corresponding fraction-over-a-power-of-two. Don't get to understand this. Could you send please an example of Decimal to this case? Thank you! . Facundo

1 0

Windows/CE Python integration into development Python source tree
by David L. Kashtan 24 Jun '04

24 Jun '04

I am the person who has been doing the Windows/CE Python 2.3.4 port. Happily, the changes are minimal -- but I would like to get them into the source tree so Windows/CE can be a fully supported Python platform. I have a patch kit for 2.3.4 that adds Windows/CE support. How do I get this integrated? I would also be VERY happy to do the work to integrate with the head of the developement tree. David Kashtan Validus Medical Systems

2 1

Building strings with +=
by Raymond Hettinger 24 Jun '04

24 Jun '04

What is wrong with the following code? def join(*iterable): s = "" for e in iterable: s = s + e return s What if that code could run as fast as ''.join(iterable)? How much existing code would start to perform better? In particular, would XML code laden with += loops run faster? Would Python be easier to teach and write? Would the resulting code look more natural and obvious? Without expanding the size of the string structure, I think it is possible to implement something equivalent to the following proposal (which for clarity, does add two words to the structure). Roughly, the idea is: Add two PyObject pointers to the structure, component0 and component1, and initialize them to NULL. Alter string_concat(a, b) to return a new string object with: ob_sval = '\0' ob_size = len(a) + len(b) component0 = a // be sure to INCREF(a) component1 = b // be sure to INCREF(b) To the start of every string method except string_len() and string_concat(), add a macro that expands to: if (self->component0 != NULL) _autojoin(self); Write an _autojoin(self) method who's goal in life is to recursively fill-out the string from the components: * resize self to be big enough for an ob_sized string * treat component0 and component1 as a binary tree (with only the leaves holding real strings) and recursively (in-order) find the leaves and copy their string data into self->ob_sval. DECREF each component after traversing it. * set self->component0 to NULL to mark self as being fully joined. The recursion depth should not be worrisome. In the typical case, one side of the tree will be a leaf and will not recurse further. It gets more interesting if the user writes things like b=a+a or has a nested series like c=a+b; f=d+e; g=c+f. The recursion and reference counting trivializes the handling of those cases. An actual implementation striving to save the two additional structure fields could use the ob_sstate field to indicate a deferred string (my name for a string that has not yet had ob_sval filled out). The ob_sval array itself would be given room to hold two object pointers for the components and access to those pointers would be cast to (PyObject *). If this works out, it would be an innovation. The join([a,b,c,d]) versus a+b+c+d problem also exists in several other languages. AFAICT, Python would have been the first to solve it. As a nice side benefit, __builtin__.sum() would no longer need to reject the case where the inputs were strings. There is a proof-of-concept patch for this at: www.python.org/sf/976162 Using UserString, the patch demonstrates a simplified implementation that converts the O(n**2) string addition process into an O(n) process like str.join(). Since the patch passes the test suite, it seems likely that the above could be implemented in a way that is transparent to the user. Raymond Hettinger P.S. This is a repeat post. I don't think the first one made it through mailman this week.

2 1

HTML side by side diff patch 914575
by Dan Gass 24 Jun '04

24 Jun '04

Jim, I appreciate your feedback, based on it I'm currently tinkering with the HTML to figure out a better way. Would you (and RH?) be interested in reviewing it when I'm done to see if you can think of any improvements? After I'm done mocking up some HTML I'll implement it and go ahead and resubmit the patch. I think I figured out how to use tables to do what you want but still have the look I want. I'm also going to switch to utilize the viewCVS color scheme. Please note that some of your "next" alignment problems may be caused by the text size setting. I've seen certain text size settings in Microsoft Internet Explorer that don't work as well. I typically select the smallest text size and never have problems. I'm hoping to make this a non-issue with what I'm going to propose. Thanks, Dan Gass

3 4

thread priority
by Patrick Stinson 24 Jun '04

24 Jun '04

I am trying to create a thread that runs with real-time priority, while the others do not. Any way to do this from the python level.

2 1

Another possible itertools candidate
by Scott David Daniels 24 Jun '04

24 Jun '04

One candidate for itertools I'd like feedback on is "ilines": a universal newlines iterator. The idea is to take an iterator that produces input blocks and yield lines as universal newlines would produce them if the reads from a binary-opened file produced the same blocks. This allows things like decompression to iterate in parts rather than perform a full expansion. It would also make pseudo-files from zipfile a later possibility. For the curious, I have a Python version with tests at: http://members.dsl-only.net/~daniels/ilines.html If people think this is a good idea, I could turn it into an itertools patch. -- -Scott David Daniels Scott.Daniels(a)Acm.Org

1 1

NOP
by Raymond Hettinger 24 Jun '04

24 Jun '04

Any objections to my adding a NOP instruction to support additional code generation improvements in Python/compile.c? Raymond

2 1

RE: [Python-Dev] Possible addition to itertools
by Raymond Hettinger 24 Jun '04

24 Jun '04

> Aahz wrote: > > ... I don't think it belongs in itertools. If/when we create > > the semi-mythical text/string package, it should go there. > Maybe the text line filling code can be re-cast in this form to > beef the module size up. With Barry about to make additions to the string module, perhaps ilines() could go there. Alternately, I could see it as a static method for file objects. Raymond

1 0

python-dev Summary for 2004-06-01 through 2004-06-15 [draft]
by Brett 23 Jun '04

23 Jun '04

I plan on sending this summary out this weekend, so please get any edits in by then. And don't get too used this level of turn-around; I just haven't started work yet and I am not in the mood to start coding my thesis. =) ---------------------------------------------------------------- Summary Announcements ===================== Wow, two summaries written in a single week. Hell has not frozen over, don't worry; work has just not started yet. =) Summaries ========= -------------------------------- New PEP on bytecode verification -------------------------------- As it stands now, unless you are running a debug build of Python, there are no checks that the bytecode being executed by the interpreter is valid. It is not terribly difficult to crash the interpreter with blatently invalid bytecode. In an attempt to resolve this, `PEP 330`_ has been written in hopes of coming up with a Python module in the stdlib that can have bytecode passed to it and attempt to perform some basic verification on it. .. _PEP 330: http://python.org/peps/pep-0300.html Contributing threads: - `PEP 330 Python bytecode verification <http://mail.python.org/pipermail/python-dev/2004-June/045082.html>`__ -------------------- 2.4a1 coming up soon -------------------- Python 2.4a1 should be coming out early July. If you have some bugs or patches you want to see in 2.4 then reads Anthony's announcement email for general guidelines on how to go about this. Jeremy Hylton pointed out that since the AST branch did not make it in before this announcement it would not be included in 2.4 (thus guaranteeing a sprint topic for PyCON 2005). Generator expressions *are* in this alpha with late bindings; if early binding would work better in your code after trying late binding then speak up since the semantics can change. Contributing threads: - `pre-announce: Python 2.4a1 is about a month away <http://mail.python.org/pipermail/python-dev/2004-May/045028.html>`__ -------------------------------------------------- The shaky courtship of 2.4 and function decorators -------------------------------------------------- With 2.4a1 ominously approaching on the horizon, Guido asked what people thought of holding off on including function decorators for 2.5. Some people said to put it in and if that meant using Guido's, then so be it. Others said to wait and let Guido have more time since he wanted to consider Java 1.5's syntax. Guido said he would ask at EuroPython_ for more opinions. .. EuroPython: http://www.europython.org/ Contributing threads: - `functions decorators in 2.4? <http://mail.python.org/pipermail/python-dev/2004-June/045124.html>`__ - `Dropping decorator syntax for 2.4? <http://mail.python.org/pipermail/python-dev/2004-June/045125.html>`__ ----------------------------------------------------------- Why Stackless is not about to be incorporated into the core ----------------------------------------------------------- Someone asked why Stackless_ is still not part of the Python core. After a bunch of talking, Guido spelled out a couple of reasons. One was a lack of a clear spec; if it is not obvious how it will behave it can't go in. Another was whether it could reasonably work on Jython; Python the language needs to be portable enough to be coded in C or Java. A third point was not wanting to rely on platform hacks in order for something to work; Stackless doesn't use the C stack and that can complicate things (and Guido put longjmp() from ISO C in this category so don't ever think of using it in a patch). In other words Stackless is not going to be integrated into the core at this time. .. _Stackless: http://www.stackless.com/ Contributing threads: - `Stackless Python <http://mail.python.org/pipermail/python-dev/2004-June/045074.html>`__ - `Re: Stackless Python <http://mail.python.org/pipermail/python-dev/2004-June/045098.html>`__ ------------------------------------------------------ Remember, some stdlib modules are maintained elsewhere ------------------------------------------------------ Greg Ward reminded python-dev that optparse is maintained as Optik_ and as a separate project. Some other modules are also maintained like this, so it is something to keep an eye out for if you are writing patches or reporting a bug. .. _Optik: http://optik.sf.net/ Contributing threads: - `Reminder: optparse.py is auto-generated <http://mail.python.org/pipermail/python-dev/2004-June/045176.html>`__ -------------- Python Bug Day -------------- The First Python Bug Day took place on June 5th, led by AM Kuchling. The end results are listed at http://www.python.org/moin/PythonBugDayStatus and look very good. Since SF troubles cropped up during the day (both frustration with people not being able to add files to bugs and patches created by other people and SF CVS going down), discussion of getting off of SF came up (this was also mentioned in several other minor threads). The desire to host off-site were brought up, but the issue of having enough volunteers to handle the load of managing a CVS or Subbversion repository was brought up. Also moving over to Roundup or GForge on a server under out control was also brought up. Nothing looks like it is going to happen any time soon, though (at least not until 2.4 is out the door). The next Bug Day has been tentatively scheduled for July 10. Contributing threads: - `Python bug day? <http://mail.python.org/pipermail/python-dev/2004-June/045090.html>`__ - `Bug day outcome <http://mail.python.org/pipermail/python-dev/2004-June/045235.html>`__ ---------------------------------------------------------- What it takes to have something to support weak references ---------------------------------------------------------- (should have been in last summary) Why don't strings and such support weak references? Turns out that variable-sized objects (i.e., tp_itemsize specified) cannot support them without direct support hard-coded in the struct. Since it would require more space and extra code for deallocation to add support for things such as strings and tuples, it is not going to be added to them, especially since they are immutable already. Contributing threads: - `Why aren't more things weak referencable <http://mail.python.org/pipermail/python-dev/2004-May/045006.html>`__ ------------------------- Heterogeneous comparisons ------------------------- The list was reminded that in the future at some point, comparisons between heterogeneous types will raise TypeError sans '==' and '!='. This brought up the discussion of comparing floats to longs. Guido said he is going to make sure that they can still be compared without issue (part of the reason true division was introduced). People talked about the best way to go about it, but it was mostly just talk since this is not about to go into the core. Contributing threads: - `Comparing heterogeneous types <http://mail.python.org/pipermail/python-dev/2004-June/045111.html>`__ ----------------------- Finalizing Decimal type ----------------------- Facundo Batista posted an email summing up the last nagging features for the Decimal type and `PEP 327`_. He said he would send another draft to Tim Peters for a quick look and then post basically the final PEP (doesn't look like that has happened, though .. _PEP 327: http://python.org/peps/pep-0327.html Contributing threads: - `Decimal issues - Conclusion <http://mail.python.org/pipermail/python-dev/2004-June/045209.html>`__ --------------- Free Icon books --------------- Tim Peters posted links to links to PDFs of three significant books on Icon_ (see the email for the links). Why would Python programmers care about the Icon programming language? Well, Python got the idea of generators from Icon. Plus it never hurts to know more languages, if anything just for new ideas for Python or to be able to emphatically state Python is better. =) .. _Icon: http://www.cs.arizona.edu/icon/ Contributing threads: - `Free Icon books <http://mail.python.org/pipermail/python-dev/2004-June/045231.html>`__ ---------------------------------------- Documenting undocumented C API functions ---------------------------------------- Thomas Heller updated Doc/tools/undoc_symbols.py (which finds out what C API code is undocumented) and ran it. The list of undocumented C code is listed at http://starship.python.net/crew/theller/moin.cgi/ Documenting_25CorePythonApiFunctions . If you would like to help with documenting, helping with documenting what is listed at the wiki would be great. Contributing threads: - `undocumented api functions <http://mail.python.org/pipermail/python-dev/2004-June/045308.html>`__ --------------------------------------------- Tool for side-by-side diffs outputted in HTML --------------------------------------------- http://www.python.org/sf/914575 has a patch that adds the necessary code and a tool script for side-by-side diffs using difflib that output in a nice HTML format. While the code has not been accepted yet, I personally know how useful this functionality can be so I thought I would just let people know about the code. And if you find this code helpful, then doing a code review and adding a comment on the patch would be helpful in getting the code accepted. Contributing threads: - `Side by Side Differencing Patch <http://mail.python.org/pipermail/python-dev/2004-June/045304.html>`__ - `HTML side by side diff patch 914575 <http://mail.python.org/pipermail/python-dev/2004-June/045361.html>`__ ----------------------------------- Removing CLRFs in PCbuild directory ----------------------------------- Martin v. Lowis fixed the vcproj files in the PCbuild directory to have the proper line endings. Problem is that you must run ``cvs update -A`` on your PCbuild directory to add the -kb tag on the files since it is a sticky tag. Contributing threads: - `Changing PCBuild/*.vcproj to text mode <http://mail.python.org/pipermail/python-dev/2004-June/045401.html>`__ -------------------------------------------------------- Bounding free list creation for ints and such ain't easy -------------------------------------------------------- Bounding the size of the memory used by ints and other built-ins that have a custom allocator was brought up. The suggestion of moving them to pymalloc was suggested, but it was pointed out it would make it slower and waste more space on some platforms. And the ideas on how to deal with this all seemed difficult. No code was committed in the end. Contributing threads: - `Object free lists <http://mail.python.org/pipermail/python-dev/2004-June/045403.html>`__ ------------------------------------- How to search the python-dev archives ------------------------------------- One idea is to use gmane.org to do your searches since they index the mailing list. The one that I (and apparently Tim Peters) use is to do a Google search with ``site:mail.python.org python-dev`` at the beginning. I actually search the python-dev archives using the same technique; ``site:www.python.org "python-dev Summary"``. Contributing threads: - `python-dev archive searching ? <http://mail.python.org/pipermail/python-dev/2004-June/045325.html>`__

4 3

python-list to news gateway busted?
by Brad Clements 23 Jun '04

23 Jun '04

Sorry to post here. I sent email to python-list-owner(a)python.org two days ago but did not receive a response. I read the python-list via gmane.comp.python.general. There have been no new posts there since 6/18/2004. However if I post to this newsgroup, my post does appear in the python-list archive (ie, the meta confusion new.instance() argument 1 must be classobj, not type ) post. I do not know if this is a gmane specific problem (I don't have access to another news server) or if its a python-list to news gateway problem. -- Brad Clements, bkc(a)murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements

1 0