Mailman 3 February 2005 - Python-Dev

JOB OPENING: Implementor for Python and Search
by burt＠dfki.de 04 Feb '05

04 Feb '05

I hope posting job vacancies does not violate established list netiquette. The job in question is mainly to do with the PyPy EU project. -- Alastair --- ---- Alastair Burt German Centre for AI (DFKI), Stuhlsatzenhausweg 3 Saarbruecken 66123, Germany Email: burt(a)dfki.de Tel: +49 681 302 2565 Fax: +49 681 302 5338 DFKI-LT - Job Opening The German Research Center for Artificial Intelligence (DFKI GmbH) is seeking for its Language Technology Lab a researcher/software developer with a strong background in Computer Science, who is interested in working on industrial R&D in the area of language implementation and support for the semantic web. The contract will be for approx. two years, with extensions being subject to availability of funding. Description of work The successful candidate will carry on research and collaborate on software design and implementation in the following areas: - Investigation of search in constraint and logic programming languages. - Investigation of query languages for the semantic web. - Design of conceptual framework for search in Python. - Implementation of search in Python using the facilities offered by PyPy. - Application of the new search functionality to support queries in ontology driven web sites. Requirements: - Good programming skills, particularly in the Python programming language. - Knowledge of semantic web technologies. - Excellent communication skills in English. - Working with high motivation in a team. Additional assets: - Knowledge of the implementation of Python. - Knowledge of constraint programming. Additional Information DFKI GmbH is located on the campus of Saarland University in Saarbrücken, Germany. The university's research groups and curricula in the fields of Computational Linguistics and Computer Science are internationally renowned. The LT-Lab offers excellent working conditions in a well-established research group. The position provides opportunities to collaborate in a variety of international projects. The competitive salary is calculated according to qualifications based on DFKI GmbH scales. The successful candidate will have opportunities for improving their qualification. Please send your electronic application (preferably in PDF format) to lt-jobs(a)dfki.de, referring to job opening No. 200501, not later than February 15, 2005. A meaningful application should include a cover letter, a CV, a brief summary of research interests, a statement of interest in the position offered, and contact information for three references.

3 2

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser 03 Feb '05

03 Feb '05

Patch / Bug Summary ___________________ Patches : 284 open ( +4) / 2748 closed ( +1) / 3032 total ( +5) Bugs : 804 open ( +1) / 4812 closed (+13) / 5616 total (+14) RFE : 167 open ( +0) / 142 closed ( +1) / 309 total ( +1) New / Reopened Patches ______________________ Patch for Lib/bsddb/__init__.py to work with modulefinder (2005-01-31) http://python.org/sf/1112812 opened by Tony Meyer New tutorial tests in test_generators.py (2005-01-31) http://python.org/sf/1113421 opened by Francis Girard Add SSL certificate validation (2005-02-01) http://python.org/sf/1114345 opened by James Eagan support PY_LONGLONG in structmember (2005-02-02) http://python.org/sf/1115086 opened by Sam Rushing Add SSL certificate validation (2005-02-03) http://python.org/sf/1115631 opened by James Eagan Patches Closed ______________ Make history recall a-cyclic (2004-03-11) http://python.org/sf/914546 closed by kbk New / Reopened Bugs ___________________ Cannot ./configure on FC3 with gcc 3.4.2 (2005-01-26) CLOSED http://python.org/sf/1110007 reopened by liturgist cgi.FieldStorage memory usage can spike in line-oriented ops (2005-01-30) http://python.org/sf/1112549 opened by Chris McDonough patch 1079734 broke cgi.FieldStorage w/ multipart post req. (2005-01-31) http://python.org/sf/1112856 opened by Irmen de Jong ioctl has problems on 64 bit machines (2005-01-31) http://python.org/sf/1112949 opened by Stephen Norris move_file()'s return value when dry_run=1 unclear (2005-01-31) http://python.org/sf/1112955 opened by Eelis Please add do-while guard to Py_DECREF etc. (2005-01-31) http://python.org/sf/1113244 opened by Richard Kettlewell OSATerminology still semi-broken (2005-01-31) http://python.org/sf/1113328 opened by has document {m} regex matcher wrt empty matches (2005-01-31) http://python.org/sf/1113484 opened by Wummel keywords in keyword_arguments not possible (2005-02-01) CLOSED http://python.org/sf/1113984 opened by Christoph Zwerschke inicode.decode (2005-02-01) CLOSED http://python.org/sf/1114093 opened by Manlio Perillo copy.py bug (2005-02-02) http://python.org/sf/1114776 opened by Vincenzo Di Somma webbrowser doesn't start default Gnome browser by default (2005-02-02) http://python.org/sf/1114929 opened by Jeremy Sanders eval ! (2005-02-02) CLOSED http://python.org/sf/1115039 opened by Andrew Collier Built-in compile function with PEP 0263 encoding bug (2005-02-03) http://python.org/sf/1115379 opened by Christoph Zwerschke os.path.splitext don't handle unix hidden file correctly (2005-02-04) http://python.org/sf/1115886 opened by Jeong-Min Lee Bugs Closed ___________ broken link in tkinter docs (2005-01-24) http://python.org/sf/1108490 closed by jlgijsbers recursion core dumps (2005-01-26) http://python.org/sf/1110055 closed by tim_one install_lib fails under Python 2.1 (2004-11-02) http://python.org/sf/1058960 closed by loewis Double __init__.py executing (2004-06-22) http://python.org/sf/977250 closed by loewis Cannot ./configure on FC3 with gcc 3.4.2 (2005-01-26) http://python.org/sf/1110007 closed by liturgist IDLE hangs due to subprocess (2004-12-28) http://python.org/sf/1092225 closed by kbk Empty curses module is loaded in win32 (2004-07-12) http://python.org/sf/989333 closed by tebeka Tab / Space Configuration Does Not Work in IDLE (2003-08-05) http://python.org/sf/783887 closed by kbk Negative numbers to os.read() cause segfault (2004-12-01) http://python.org/sf/1077106 closed by mwh Time module missing from latest module index (2005-01-25) http://python.org/sf/1109523 closed by montanaro keywords in keyword_arguments not possible (2005-02-01) http://python.org/sf/1113984 closed by rhettinger unicode.decode (2005-02-01) http://python.org/sf/1114093 closed by lemburg eval ! (2005-02-02) http://python.org/sf/1115039 closed by rhettinger New / Reopened RFE __________________ All Statements Should Have Return Values (Syntax Proposal) (2005-02-01) CLOSED http://python.org/sf/1114404 opened by Lenny Domnitser RFE Closed __________ All Statements Should Have Return Values (Syntax Proposal) (2005-02-01) http://python.org/sf/1114404 closed by goodger

1 0

python-dev Summary for 2005-01-01 through 2005-01-15 [draft]
by Brett C. 03 Feb '05

03 Feb '05

Wow, another summary out the same week as the previous one! Perk of keeping things short and to the point. Then again keeping them this simple and short begs the question of whether the summaries are worth it still at that point. Regardless, probably will send this one out Saturday or Sunday so corrections need to get in by then. ------------------------------------- ===================== Summary Announcements ===================== PyCon_ will be upon us come late March! Still time to plan to go. A warning on the thoroughness off this summary is in order. While trying to delete a single thread of email I managed to accidentally delete my entire python-dev mailbox. I did the best I could to retrieve the emails but it's possible I didn't resuscitate all of my emails, so I may have overlooked something. .. _PyCon: http://www.pycon.org/ ======= Summary ======= ------------- PEP movements ------------- .. tip:: PEP updates by email are available as a topic from the `Python-checkins`_ mailing list. `PEP 246`_ was a major topic of discussion during the time period covered by this summary. This all stemmed from `Guido's blog`_ entries on optional type checking. This led to a huge discussion on many aspects of protocols, interfaces, and adaptation and the broadening of this author's vocabulary to include "Liskov violation". "Monkey typing" also became a new term to know thanks to Phillip J. Eby's proto-PEP on the topic (found at http://peak.telecommunity.com/DevCenter/MonkeyTyping). Stemming from the phrase "monkey see, monkey do", it's Phillip version of taking PEP 246 logically farther (I think; the whole thing is more than my currently burned-out-on-school brain can handle right now). .. _Python-checkins: http://mail.python.org/mailman/listinfo/python-checkins .. _PEP 246: http://www.python.org/peps/pep-0246.html .. Guido's blog: http://www.artima.com/weblogs/index.jsp?blogger=guido Contributing threads: - `getattr and __mro__ <>`__ - `Son of PEP 246, redux <>`__ - `PEP 246: lossless and stateless <>`__ - `PEP 246: LiskovViolation as a name <>`__ - `"Monkey Typing" pre-PEP, partial draft <>`__ ------------------------------------------------------------------------------------ Optional type checking: how to inadvertently cause a flame war worse than decorators ------------------------------------------------------------------------------------ `Guido's blog`_ had comments on the idea of adding optional static type checking to Python. While just comments in a blog, it caused a massive response from people, mostly negative from what I gathered. After Guido discussed things some more it culminated in a blog entry found at http://www.artima.com/weblogs/viewpost.jsp?thread=87182 that lays out what his actual plans are. I highly recommend reading it since it suggests adding optional run-time type checking for function arguments along with some other proposals. All of this led to `PEP 246`_ getting updated. For some more details on that see the `PEP movements`_ section of this summary. And if there is a lesson to be learned from all of this, it's that when Alex Martelli and Phillip J. Eby start a technical discussion it's going to be long, in-depth, complex, and lead to my inbox being brimming in python-dev email. ------------------------------ Let's get the AST branch done! ------------------------------ Guido posted an email to the list stating he would like to to make progress towards integrating "things like type inferencing, integrating PyChecker, or optional static type checking" into Python. In order to make that easier he put out a request that people work on the AST branch and finish it. For those that don't know about Python's back-end, the compiler as it stands now takes the parse tree from the parser and emits bytecode directly from that. This is far from optimal since the parse tree is more verbose than needed and it is not the easiest thing to work with. The AST branch attempts to fix this by taking a more traditional approach to compiling. This means the parse tree is used to generate an AST (abstract syntax tree; and even more technically could be considered a control flow graph in view of how it is implemented) which in turn is used to emit bytecode. The AST itself is much easier to work with when compared to the parse tree; better to know you are working with an 'if' guard thanks to it being an 'if' node in the AST than checking if the parse tree statement you are working with starts with 'if' and ends with a ':'. While all of this sounds great, the issue is the AST branch is not finished yet. It is not entirely far off, but new features from 2.4 (decorators and generator expressions) need to be added along with more bug fixing and clean up. This means the AST branch is going to get finished for 2.5 somehow. But help is needed. While the usual suspects who have previously contributed to the branch are hoping to finish it, more help is always appreciated. If you care to get involved, check out the AST branch (tagged as 'ast-branch' in CVS; see the `python-dev FAQ`_ on how to do a tagged branch checkout), read Python/compile.txt and just dive in! There will also be a sprint on the AST branch at PyCon. .. _python-dev FAQ: http://www.python.org/dev/devfaq.html Contributing threads: - `Please help complete the AST branch <>`__ - `Will ASTbranch compile on windows yet? <>`__ - `ast branch pragmatics <>`__ - `Re: [Python-checkins] python/dist/src/Python pythonrun.c, 2.161.2.15, 2.161.2.16 <>`__ -------------------------------- Ditching unbound methods in Py3k -------------------------------- Guido suggested removing unbound methods from Python since their usefulness of checking their first argument and other slight differences from functions just didn't seem worth keeping around and complicating the language. So the idea seems sound. But then people with uses for the extra information kept in unbound methods (im_func and im_self) popped up. To make the long thread short, enough people stepped up mentioning uses they had for the information for Guido to retract the suggestion in the name of backwards compatibility. But unbound methods are now on the list of things to go in Python 3000. Contributing threads: - `Let's get rid of unbound methods <>`__ - `Getting rid of unbound methods: patch available <>`__ - `PEP 246 - concrete assistance to developers of new adapter classes <>`__ ------------------------------------------ Getting exceptions to be new-style classes ------------------------------------------ A patch to allow exceptions to be new-style classes is currently at http://www.python.org/1104669 . The plan is to get that patch in order, apply it, and as long as a ton of code does not break from exceptions moving from classic to new-style classes it will be made permanent in 2.5 . This in no way touches on the major changes as touched upon in a `previous summary <http://www.python.org/dev/summary/2004-09-01_2004-09-15.html#cleaning-the-e…>`__ which will need a PEP to get the hierarchy cleaned up and discuss any possible changes to bar 'except' statements. Contributing threads: - `Exceptions *must*? be old-style classes? <>`__ =============== Skipped Threads =============== - Mac questions - 2.3.5 schedule, and something I'd like to get in - csv module TODO list - an idea for improving struct.unpack api - Minor change to behaviour of csv module - PATCH/RFC for AF_NETLINK support - logging class submission - Recent IBM Patent releases - frame.f_locals is writable - redux: fractional seconds in strptime - Darwin's realloc(...) implementation never shrinks allocations

1 0

Is msvcr71.dll re-redistributable?
by Thomas Heller 03 Feb '05

03 Feb '05

The 2.4 python.org installer installs msvcr71.dll on the target system. If someone uses py2exe or a similar tool to create a frozen application, is he allowed to redistribute this msvcr71.dll to other users together with his application or not, even if he doesn't own MSVC? This was asked on the py2exe users list, but I could not answer this question. Googling for msvcr71.dll finds some site which offer to download it, and they pretend that they are not violating any license, but I wasn't able to find definite words from MS about that. Thanks, Thomas

3 3

RE: [Python-Dev] Is msvcr71.dll re-redistributable?
by Phillip J. Eby 03 Feb '05

03 Feb '05

At 01:23 PM 2/3/05 +1300, Tony Meyer wrote: >(Users giving the software directly to someone else, rather than downloading >from the official site, is probably covered by: > >"""You also agree not to permit further distribution of the Redistributables >by your end users except you may permit further redistribution of the >Redistributables by your distributors to your end-user customers if your >distributors only distribute the Redistributables in conjunction with, and >as part of, the Licensee Software and you and your distributors comply with >all other terms of this EULA.""" > >Where the users become our redistributors.) Sounds like this puts all Python users in the clear, since Python is the Licensee Software in that case. So, anybody can distribute msvcr71 as "part of" Python. OTOH, the other wording sounds like Python itself has to have a click-wrap, tear-open, or signature EULA! IOW, the EULA appears to prohibit free distribution of the runtime with a program that has no EULA. So, in an amusing turn of events, the EULA actually appears to forbid the current offering of Python for Windows, since it does not have such a EULA. This is a much bigger worry than the original question. If we're actually allowed to distribute Python with the runtime at all, then py2exe and such are perfectly safe, since it's in conjunction with permitted redistribution. If distribution of the runtime is not allowed, on the other hand, then use of MSVC 7 for Python becomes altogether impossible without adding some kind of click-wrap licensing scheme.

3 2

redux: fractional seconds in strptime
by Skip Montanaro 03 Feb '05

03 Feb '05

A couple months ago I proposed (maybe in a SF bug report) that time.strptime() grow some way to parse time strings containing fractional seconds based on my experience with the logging module. I've hit that stumbling block again, this time in parsing files with timestamps that were generated using datetime.time objects. I hacked around it again (in miserable fashion), but I really think this shortcoming should be addressed. A couple possibilities come to mind: 1. Extend the %S format token to accept simple decimals that match the re pattern "[0-9]+(?:\.[0-9]+)". 2. Add a new token that accepts decimals as above to avoid overloading the meaning of %S. 3. Add a token that matches integers corresponding to fractional parts. The Perl DateTime module uses %N to match nanoseconds (wanna bet that was added by a physicist?). Arbitrary other units can be specified by sticking a number between the "%" and the "N". I didn't see an example, but I presume "%6N" would match integers that are interpreted as microseconds. The advantage of the third choice is that you can use anything as the "decimal" point. The logging module separates seconds from their fractional part with a comma for some reason. (I live in the USofA where decimal points are usually represented by a period. I would be in favor of replacing the comma with a locale-specific decimal point in a future version of the logging module.) I'm not sure I like the optional exponent thing in Perl's DateTime module but it does make it easy to interpret integers representing fractions of a second when they occur without a decimal point to tell you where it is. I'm open to suggestions and will be happy to implement whatever is agreed to. Skip

6 13

Returned mail: Data format error
by anthony＠interlink.com.au 03 Feb '05

03 Feb '05

Your message was not delivered due to the following reason: Your message could not be delivered because the destination computer was unreachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message could not be delivered within 7 days: Mail server 190.102.237.222 is not responding. The following recipients could not receive this message: <python-dev(a)python.org> Please reply to postmaster(a)interlink.com.au if you feel this message to be in error.

1 0

RE: [Python-Dev] Is msvcr71.dll re-redistributable?
by Tony Meyer 02 Feb '05

02 Feb '05

(I should point out the thread that starts here, too: <http://mail.python.org/pipermail/python-dev/2004-November/050101.html> in case anyone isn't aware of it). > Sounds like this puts all Python users in the clear, since > Python is the Licensee Software in that case. So, anybody can > distribute msvcr71 as "part of" Python. I guess it would really take a lawyer (well, probably several) to say whether distributing a frozen application is distributing Python or not. > OTOH, the other wording sounds like Python itself has to have > a click-wrap, tear-open, or signature EULA! IOW, the EULA > appears to prohibit free distribution of the runtime with a > program that has no EULA. > > So, in an amusing turn of events, the EULA actually appears > to forbid the current offering of Python for Windows, since > it does not have such a EULA. I presume that adding a "click-wrap" EULA to the Python .msi would not be difficult. Lots of other .msi's have "click-wrap" licenses, so there must be some sample code that can be used. The license is already in the distribution, it would just be displayed at an additional time. The EULA has to be no less restrictive than the MSVC one (presumably only in relation to the bits of MSVC that are being redistributed), so I guess a section at the end of the PSF license that duplicates the relevant bits of the MSVC one would work. (Of course, IANAL). =Tony.Meyer

1 0

RE: [Python-Dev] Is msvcr71.dll re-redistributable?
by Tony Meyer 02 Feb '05

02 Feb '05

[Thomas Heller] >> For the spambayes binary, maybe there should be another >> person adding the msvcr71.dll to the distribution that Tony >> builds? Someone who has a MSVC license, and also is developer >> on the spambayes project? [Tim Peters] > To the best of my knowledge, Tony is distributing my duly > licensed copy of msvcr71.dll with spambayes. And so long as > I remain totally ignorant of what Tony actually does, that > will remain my best knowledge. Win-win <wink>. That solves the specific SpamBayes problem. It still seems like this is somewhat of a PITA for people wanting to build frozen Windows apps with Python 2.4, though. OTOH, I can't personally think of anything (apart from the it'll-never-fly go back to VC6 solution or the bound-to-be-terrible static linking solution) that the Python developers can do about it. (Well, there's that chap from Microsoft at PyCon, right? How about one of you convince him to convince Microsoft to give all Python developers a licence to redistribute msvcr71.dll? <wink>). BTW, this bit of the EULA isn't great: ""(iii) to distribute the Licensee Software containing the Redistributables pursuant to an end user license agreement (which may be "break-the-seal", "click-wrap" or signed), with terms no less protective than those contained in this EULA;""" The PSF licence is probably somewhat less protective than that one. I suppose the PSF licence really applies to the source, though, and not the built binary. Or something like that :) (Users giving the software directly to someone else, rather than downloading from the official site, is probably covered by: """You also agree not to permit further distribution of the Redistributables by your end users except you may permit further redistribution of the Redistributables by your distributors to your end-user customers if your distributors only distribute the Redistributables in conjunction with, and as part of, the Licensee Software and you and your distributors comply with all other terms of this EULA.""" Where the users become our redistributors.) =Tony.Meyer

1 0

A proposal: built in support for abstract methods
by Noam Raphael 02 Feb '05

02 Feb '05

Hello, I would like to suggest a new method decorator: abstractmethod. I'm definitely not the only one who've thought about it, but I discussed this on c.l.py, and came to think that it's a nice idea. An even Pythonic! This has nothing to do with type checking and adaptation - or, to be more precise, it may be combined with them, but it will live happily without them. I don't understand these issues a great deal. What was my situations? I had to write a few classes, all with the same interface but with a different implementation, that were meant to work inside some infrastructure. The specific class that would be used would be selected by what exactly the user wanted. Some methods of these classes were exactly the same in all of the classes, so naturally, I wrote a base class with an implementation of these methods. But then came the question: and what about the other methods? I wanted to document that they should exist in all the classes of that family, and that they should do XYZ; otherwise, they won't fit the infrastructure. So I wrote something like: def get_changed(self): """This method should return the changed keys since last call.""" raise NotImplementedError But I wasn't happy about it. I thought that @abstractmethod def get_changed(self): """This methods should ...""" would have been nicer. Why? 1. "Beautiful is better than ugly." - Who was talking here about errors? I just wanted to say what the method should do! 2. "Explicit is better than implicit." - This is really the issue. I *meant* to declare that a method should be implemented in subclasses, and what it should do, but I *was* actually defining a method which raises NotImplementedError when called with no arguments. I am used to understanding NotImplementedError as "We should really implement this some day, when we have the time", not as "In order to be a proud subclass of BaseClass, you should implement this method". 3. "There should be one-- and preferably only one --obvious way to do it." - I could have written this in a few other ways: def get_changed(self): """This method should return the changed keys since last call. PURE VIRTUAL. """ def get_changed(self): """This method should return the changed keys since last call.""" raise NotImplementedError, "get_changed is an abstract methods. Subclasses of BaseClass should implement it." What's good about the last example is that when the exception occurs, it would be easier to find the problem. What's bad about it, is that it's completely redundent, and very long to write. Ok. Now another thing: I want classes that contain abstractmethods be uninstantiable. One (and the main) reason is that instantiating that class of mine doesn't make sense. It doesn't know how to do anything useful, and doesn't represent any consistent object that you can have instances of. The other reason is that it will help the programmer to find out quickly methods he forgot to implement in his subclasses. You may say that it suits "Errors should never pass silently." The basic reason why I think this is fitting is that abstract classes are something which is natural when creating class hierarchies; usually, when I write a method, all subclasses must inherit it, or implement another version with a compatible behaviour. Sometimes there is no standard behaviour, so all subclasses must choose the second option. This concept is already in use in Python's standard library today! "basestring" was created as the base class of "str" and "unicode". What I'm proposing is just to make this possible also in code written in Python. George Sakkis has posted a very nice Python implementation of this: http://groups-beta.google.com/group/comp.lang.python/msg/597e9ffa7b1f709b To summarize, I think that abstract methods are simply not regular functions, since by definition they don't specify actions, and so they deserves an object of their own. And if it helps with testing the subclasses - then why not? What do you say? Noam

1 0