Mailman 3 May 2000 - Python-Dev

Python 3000 is going to be *really* different
by Jeremy Hylton 30 May '00

30 May '00

http://www.autopreservers.com/autope07.html Jeremy

1 0

ANNOUNCEMENT: Python Development Team Moves to BeOpen.com
by Guido van Rossum 30 May '00

30 May '00

FYI, here's an important announcement that I just sent to c.l.py. I'm very excited that we can finally announce this! I'll be checking mail sporadically until Thursday morning. Back on June 19. --Guido van Rossum (home page: http://www.python.org/~guido/) To all Python users and developers: Python is growing rapidly. In order to take it to the next level, I've moved with my core development group to a new employer, BeOpen.com. BeOpen.com is a startup company with a focus on open source communities, and an interest in facilitating next generation application development. It is a natural fit for Python. At BeOpen.com I am the director of a new development team named PythonLabs. The team includes three of my former colleagues at CNRI: Fred Drake, Jeremy Hylton, and Barry Warsaw. Another familiar face will joins us shortly: Tim Peters. We have our own website (www.pythonlabs.com) where you can read more about us, our plans and our activities. We've also posted a FAQ there specifically about PythonLabs, our transition to BeOpen.com, and what it means for the Python community. What will change, and what will stay the same? First of all, Python will remain Open Source. In fact, everything we produce at PythonLabs will be released with an Open Source license. Also, www.python.org will remain the number one website for the Python community. CNRI will continue to host it, and we'll maintain it as a community project. What changes is how much time we have for Python. Previously, Python was a hobby or side project, which had to compete with our day jobs; at BeOpen.com we will be focused full time on Python development! This means that we'll be able to spend much more time on exciting new projects like Python 3000. We'll also get support for website management from BeOpen.com's professional web developers, and we'll work with their marketing department. Marketing for Python, you ask? Sure, why not! We want to grow the size of the Python user and developer community at an even faster pace than today. This should benefit everyone: the larger the community, the more resources will be available to all, and the easier it will be to find Python expertise when you need it. We're also planning to make commercial offerings (within the Open Source guidelines!) to help Python find its way into the hands of more programmers, especially in large enterprises where adoption is still lagging. There's one piece of bad news: Python 1.6 won't be released by June 1st. There's simply too much left to be done. We promise that we'll get it out of the door as soon as possible. By the way, Python 1.6 will be the last release from CNRI; after that, we'll issue Python releases from BeOpen.com. Oh, and to top it all off, I'm going on vacation. I'm getting married and will be relaxing on my honeymoon. For all questions about PythonLabs, write to pythonlabs-info(a)beopen.com. --Guido van Rossum (home page: http://www.python.org/~guido/)

5 6

inspect.py
by Ka-Ping Yee 30 May '00

30 May '00

I just posted the HTML document generator script i promised to do at IPC8. It's at http://www.lfw.org/python/ (see the bottom of the page). The reason i'm mentioning this here is that, in the course of doing that, i put all the introspection work in a separate module called "inspect.py". It's at http://www.lfw.org/python/inspect.py It tries to encapsulate the interface provided by func_*, co_*, et al. with something a little richer. It can handle anonymous (tuple) arguments for you, for example. It can also get the source code of any function, method, or class for you, as long as the original .py file is still available. And more stuff like that. I think most of this stuff is quite generally useful, and it seems good to wrap this up in a module. I'd like your thoughts on whether this is worth including in the standard library. -- ?!ng "To be human is to continually change. Your desire to remain as you are is what ultimately limits you." -- The Puppet Master, Ghost in the Shell

3 2

unicode regex quickie: should a newline be the same thing as a linebreak?
by Fredrik Lundh 30 May '00

30 May '00

in the current 're' engine, a newline is chr(10) and nothing else. however, in the new unicode aware engine, I used the new LINEBREAK predicate instead, but it turned out to break one of the tests in the current test suite: sre.match('a\rb', 'a.b') => None (unicode adds chr(13), chr(28), chr(29), chr(30), and also unichr(133), unichr(8232), and unichr(8233) to the list of line breaking codes) what's the best way to deal with this? I see three alter- natives: a) stick to the old definition, and use chr(10) also for unicode strings b) use different definitions for 8-bit strings and unicode strings; if given an 8-bit string, use chr(10); if given a 16-bit string, use the LINEBREAK predicate. c) use LINEBREAK in either case. I think (c) is the "right thing", but it's the only that may break existing code... </F>

6 12

Extending locale.py
by M.-A. Lemburg 30 May '00

30 May '00

To make moving into the direction of making the string encoding depend on the locale settings a little easier, I've started to hack away at an extension of the locale.py module. The module provides enough information to be able to set the string encoding in site.py at startup. Additional code for _localemodule.c would be nice for platforms which use other APIs to get at the active code page, e.g. on Windows and Macs. Please try it on your platform and tell me what you think of the APIs. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

3 4

SRE snapshot broken
by Jeremy Hylton 30 May '00

30 May '00

I believe I'm looking at the current version. (It's a file called snapshot.zip with no version-specific identifying info that I can find.) The sre module changed one line in _fixflags from the CVS version. def _fixflags(flags): # convert flag bitmask to sequence assert flags == 0 return () The assert flags == 0 is apparently wrong, because it gets called with an empty tuple if you use sre.search or sre.match. Also, assuming that simply reverting to the previous test "assert not flags" fix this bug, is there a test suite that I can run? Guido asked me to check in the current snapshot, but it's hard to tell how to do that correctly. It's not clear which files belong in the Python CVS tree, nor is it clear how to test that the build worked. Jeremy

1 0

Q: join vs. __join__ ?
by Fredrik Lundh 30 May '00

30 May '00

(re: yet another endless thread on comp.lang.python) how about renaming the "join" method to "__join__", so we can argue that it doesn't really exist. </F> <project name="sre" complete="97.1%" />

1 0

Re: [Python-Dev] String encoding
by Martin v. Loewis 30 May '00

30 May '00

Fred L. Drake wrote > I recall a fair bit of discussion about wchar_t when it was > introduced to ANSI C, and the character set and encoding were > specifically not made part of the specification. Making a > requirement that wchar_t be Unicode doesn't make a lot of sense, and > opens up potential portability issues. In ISO (!) C99, an implementation may define __STDC_ISO_10646__ to indicate that wchar_t is Unicode. The exact wording is # A decimal constant of the form yyyymmL (for example, 199712L), # intended to indicate that values of type wchar_t are the coded # representations of the characters defined by ISO/IEC 10646, along # with all amendments and technical corrigenda as of the specified # year and month. Of course, at the moment, there are few, if any, implementations that define this macro. Regards, Martin

2 1

importing .pyc-files generated by Python 1.5.2 in Python 1.6. Why not?
by pf＠artcom-gmbh.de 30 May '00

30 May '00

Python 1.6 reports a bad magic error, when someone tries to import a .pyc file compiled by Python 1.5.2. AFAIK only new features have been added. So why it isn't possible to use these old files in Python 1.6? Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)

10 24

Guido is offline
by Jeremy Hylton 29 May '00

29 May '00

FYI: Guido's cable modem service is giving him trouble and he's unable to read email at the moment. He wanted me to let you know that lack of response isn't for lack of interest. I imagine he won't be fully responsive until after the holiday weekend :-). Jeremy

2 1