If you are addressed on this message, it means you have open issues that need to be resolved for 2.5. Some of these issues are documentation, others are code issues. This information comes from PEP 356. The best way to get me to stop bugging you is to close out these tasks. :-) Who is the owner for getting new icons installed with the new logo? Code issues: +++++++++++ Fred, Fredrik, Martin: xmlplus/xmlcore situation re: ElementTree Jeremy: AST compiler issues We should really try to get these resolved soon, especially the XML issue since that could result in some sort of API change. The AST issues should just be bug fixes AFAIK. Documentation missing: +++++++++++++++++++ Fredrik: ElementTree Gerhard: pysqlite Martin: msilib Thomas: ctypes Thomas, I know you checked in some ctypes docs. Is that everything or is there more coming? It seemed pretty short given the size of ctypes. If you don't expect to have time to finish these tasks, then it's your job to find someone else who will. n
Neal Norwitz wrote:
If you are addressed on this message, it means you have open issues that need to be resolved for 2.5. Some of these issues are documentation, others are code issues.
Documentation missing: +++++++++++++++++++ Fredrik: ElementTree Gerhard: pysqlite Martin: msilib Thomas: ctypes
Thomas, I know you checked in some ctypes docs. Is that everything or is there more coming? It seemed pretty short given the size of ctypes.
If you don't expect to have time to finish these tasks, then it's your job to find someone else who will.
I was fearing it is getting too long. How many pages do you expect or will you tolerate (yes, this is a serious question)? I could imaging three parts of the ctypes docs: 1. The tutorial, which is already checked in. 2. A reference manual, listing all the available functions and types (it will probably duplicate a lot of what is in the tutorial). 3. Some articles/howtos which cover advanced issues. I have the start of a reference manual, which is about 12 pages now. Incomplete, some sections are not yet or no longer correct, but you can take a look at it here: http://starship.python.net/crew/theller/manual/manual.html This could be completed and committed into SVN soon. Thomas
On Fri, Apr 28, 2006 at 10:27:45AM +0200, Thomas Heller wrote:
I could imagine three parts of the ctypes docs: ... 3. Some articles/howtos which cover advanced issues.
Note that there's now a Doc/howto directory, so you could put articles there. The howtos aren't built as part of the documentation set, but maybe we should work on fixing that. Also note that one existing howto is in reST, the first use of reST in the Python docs. So integrating the howtos will mean supporting reST, and you can therefore write howtos in reST if that's convenient. --amk
Thomas Heller wrote:
I was fearing it is getting too long. How many pages do you expect or will you tolerate (yes, this is a serious question)?
I don't think there should be a page limit to documentation. If it is structured into sections, then size simply doesn't matter on the Web: people can easily skip over it / ignore it if they want to. It only matters for the size of the distribution, but only slightly so: I doubt it contributes significantly to the size of the whole distribution.
2. A reference manual, listing all the available functions and types (it will probably duplicate a lot of what is in the tutorial).
I would feel that this is a must-have document, and completeness is certainly a goal here. Now, if certain parts are still undocumented, I wouldn't make creation of this documentation a release requirement, but text that already exists should be included.
3. Some articles/howtos which cover advanced issues.
I don't think they are necessary; if Andrew thinks the howto section would be a good place, I don't mind.
I have the start of a reference manual, which is about 12 pages now. Incomplete, some sections are not yet or no longer correct, but you can take a look at it here:
http://starship.python.net/crew/theller/manual/manual.html
This could be completed and committed into SVN soon.
Looks good to me. Martin
On Thu, Apr 27, 2006 at 10:58:49PM -0700, Neal Norwitz wrote:
If you are addressed on this message, it means you have open issues that need to be resolved for 2.5. Some of these issues are documentation, others are code issues. This information comes from PEP 356.
There are also these items in the 'possible features' section: ================ Modules under consideration for inclusion: - bdist_deb in distutils package (Owner: ???) http://mail.python.org/pipermail/python-dev/2006-February/060926.html - wsgiref to the standard library (Owner: Phillip Eby) - pure python pgen module (Owner: Guido) - Support for building "fat" Mac binaries (Intel and PPC) (Owner: Ronald Oussoren) ================ wsgiref is the most important one, I think. If there's anything I can do to help, please let me know. --amk
On 4/28/06, A.M. Kuchling
There are also these items in the 'possible features' section: ================ Modules under consideration for inclusion:
- bdist_deb in distutils package (Owner: ???) http://mail.python.org/pipermail/python-dev/2006-February/060926.html
Isn't that MvL?
- wsgiref to the standard library (Owner: Phillip Eby)
I still hope this can go in; it will help web framework authors do the right thing long term.
- pure python pgen module (Owner: Guido)
I'm withdrawing this for 2.5 and resubmitting it to 2.6; I have no time to clean it up. I know it is possible using this code to create a Python source-to-bytecode compiler in pure Python (using tokenizer.py for the lexer and the compiler package as the bytecode generator, and accepting the latter's imperfections) but few people have that need and those that do can download it from SF.
- Support for building "fat" Mac binaries (Intel and PPC) (Owner: Ronald Oussoren)
Yes, this would be cool.
wsgiref is the most important one, I think. If there's anything I can do to help, please let me know.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
- bdist_deb in distutils package (Owner: ???) http://mail.python.org/pipermail/python-dev/2006-February/060926.html
Isn't that MvL?
I spoke in favour of including it, but don't recall ever to committing as a "sponsor/second" of including it (and I certainly didn't write it). I can't find a patch for bdist_deb right now, so if nobody steps forward with actual code to include, this gets probably dropped from 2.5. Notice that the URL quoted actually speaks against a bdist_deb command.
- Support for building "fat" Mac binaries (Intel and PPC) (Owner: Ronald Oussoren)
Yes, this would be cool.
This is nearly committed. For some reason, SF apparently dropped my last change request for it, and Ronald's patch responding to this request, so it barely missed 2.5a2. Regardless, I guess Ronald will release his 2.5a2 binaries in the fat form. For those interested, one surprising (for me) challenge in this is that WORDS_BIGENDIAN can't be a configure-time constant anymore. It doesn't need to be a run-time thing, either, because at run-time, you know the endianness of the (current) processor. It isn't configure-time constant, because each individual gcc invocations runs *two* compiler passes (cc1) and *two* assemblers, which incidentally have different endiannesses. So WORDS_BIGENDIAN now must be a compile-time constant; fortunately, gcc defines either __BIG_ENDIAN__ or __LITTLE_ENDIAN__, depending on whether it is the PPC cc1 or the x86 cc1 that runs. To make this work with autoconf on systems which don't define either of these constants, pyconfig.h.in now has a block that derives WORDS_BIGENDIAN from __(BIG|LITTLE)_ENDIAN__ if they are defined, and makes it configure-time otherwise. So in short: WORDS_BIGENDIAN will always be right, and will have two different values in a fat binary. Regards, Martin
On 28-apr-2006, at 17:41, Martin v. Löwis wrote:
- Support for building "fat" Mac binaries (Intel and PPC) (Owner: Ronald Oussoren)
Yes, this would be cool.
This is nearly committed. For some reason, SF apparently dropped my last change request for it, and Ronald's patch responding to this request, so it barely missed 2.5a2. Regardless, I guess Ronald will release his 2.5a2 binaries in the fat form.
I hope this isn't a bad omen for this feature ;-). I've also had to resubmit one of my changes to this tracker item because SF dropped it. My 2.5a2 build will include this patch and will be a fat binary. Ronald
Here's what's left for 2.5 after the most recent go around.
There's no owner for these items. If no one takes them, they won't
get done and I will move them to deferred within a week:
* Add @decorator decorator to functional, rename to functools?
What's the benefit of @decorator? Who made functional? It's new
in 2.5, right? If so, move it or it will be functional for all 2.x.
* Remove the fpectl module?
Does anyone use this? It can probably be removed, but someone
needs to do the work.
* new icons is lost and needs a shepherd to make python look spiffy
* what's happening with these modules: timing, cl, sv?
n
On 4/28/06, A.M. Kuchling
On Thu, Apr 27, 2006 at 10:58:49PM -0700, Neal Norwitz wrote:
If you are addressed on this message, it means you have open issues that need to be resolved for 2.5. Some of these issues are documentation, others are code issues. This information comes from PEP 356.
There are also these items in the 'possible features' section: ================ Modules under consideration for inclusion:
- bdist_deb in distutils package (Owner: ???) http://mail.python.org/pipermail/python-dev/2006-February/060926.html
- wsgiref to the standard library (Owner: Phillip Eby)
- pure python pgen module (Owner: Guido)
- Support for building "fat" Mac binaries (Intel and PPC) (Owner: Ronald Oussoren) ================
wsgiref is the most important one, I think. If there's anything I can do to help, please let me know.
--amk _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com
On 4/28/06, Neal Norwitz
There's no owner for these items. If no one takes them, they won't get done and I will move them to deferred within a week:
* Add @decorator decorator to functional, rename to functools? What's the benefit of @decorator? Who made functional? It's new in 2.5, right? If so, move it or it will be functional for all 2.x.
The PEP responsible for functional (PEP 309) was written by Peter Harris, with the partial class (the module's sole member for a while) coded by Hye-Shik Chang and Raymond Hettinger. Comments in the module list Hye-Shik Chang as the maintainer. I'd very much like to see functional renamed to functools, and I've cooked up the necessary changes to handle the move (SF #1478788). Collin Winter
Collin Winter wrote:
I'd very much like to see functional renamed to functools, and I've cooked up the necessary changes to handle the move (SF #1478788).
+1 since there are utilities like "decorator" and "deprecated" which belong in such a module, but don't fit within the "functional programming" meme suggested by the current name. If we're happy with the name change, I can make sure this change goes in before alpha 3 (probably sooner, to make it easier for anyone interested to work on a patch for @decorator). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
Neal Norwitz wrote:
Here's what's left for 2.5 after the most recent go around.
There's no owner for these items. If no one takes them, they won't get done and I will move them to deferred within a week:
* Add @decorator decorator to functional, rename to functools? What's the benefit of @decorator?
Creating decorators that don't hinder introspection.
Who made functional? It's new in 2.5, right? If so, move it or it will be functional for all 2.x.
* Remove the fpectl module? Does anyone use this? It can probably be removed, but someone needs to do the work.
* new icons is lost and needs a shepherd to make python look spiffy
I've already done the work for Unixy platforms. Georg
"Neal Norwitz"
Here's what's left for 2.5 after the most recent go around.
There's no owner for these items. If no one takes them, they won't get done and I will move them to deferred within a week:
* Add @decorator decorator to functional, rename to functools? What's the benefit of @decorator? Who made functional? It's new in 2.5, right? If so, move it or it will be functional for all 2.x.
* Remove the fpectl module? Does anyone use this? It can probably be removed, but someone needs to do the work.
This was my idea; I'm not really offering to do the work now and don't think that it's terribly urgent, so I propose leaving this until 2.6. Cheers, mwh -- <dash> it's like a bicycle <dash> but with internet -- from Twisted.Quotes
Neal Norwitz wrote:
Who is the owner for getting new icons installed with the new logo?
Nobody, so far (for Windows). Somebody should contact the owner and find out what the license on this work is, and then tell me what to do with them. I assume the py and pyc icons are to be replaced, and I also assume the Vista icons are to be ignored, but what about the other(s)? For the OSX icons, I guess Ronald Oussoren owns the task of getting them into the distribution.
Fred, Fredrik, Martin: xmlplus/xmlcore situation re: ElementTree
I still hope Fred could make progress; I had no time to look into this further, so far.
Documentation missing: +++++++++++++++++++ Fredrik: ElementTree Gerhard: pysqlite Martin: msilib Thomas: ctypes
msilib is on my agenda, but I might not be able to work for it in the next weeks. Regards, Martin
On 28-apr-2006, at 17:07, Martin v. Löwis wrote:
Neal Norwitz wrote:
Who is the owner for getting new icons installed with the new logo?
For the OSX icons, I guess Ronald Oussoren owns the task of getting them into the distribution.
That's fine by me. I'll be adding them to the universal python 2.4 tree soon and to 2.5 when that's is done. Do have to wait for the contributor agreement, which the folks over at psf@python.org say is good enough, to do that? Ronald
Ronald Oussoren wrote:
That's fine by me. I'll be adding them to the universal python 2.4 tree soon and to 2.5 when that's is done. Do have to wait for the contributor agreement, which the folks over at psf@python.org say is good enough, to do that?
If the artist has informally agreed to do that (so it is just the formal signing that takes time), go ahead. Regards, Martin
Martin v. Löwis wrote:
Neal Norwitz wrote:
Who is the owner for getting new icons installed with the new logo?
Nobody, so far (for Windows). Somebody should contact the owner and find out what the license on this work is, and then tell me what to do with them. I assume the py and pyc icons are to be replaced, and I also assume the Vista icons are to be ignored, but what about the other(s)?
As I posted here previously, I contacted the owner, and he said that he didn't care about specifying a license. I guess that means that we can pick one ;) Georg
Georg Brandl wrote:
Martin v. Löwis wrote:
Neal Norwitz wrote:
Who is the owner for getting new icons installed with the new logo? Nobody, so far (for Windows). Somebody should contact the owner and find out what the license on this work is, and then tell me what to do with them. I assume the py and pyc icons are to be replaced, and I also assume the Vista icons are to be ignored, but what about the other(s)?
As I posted here previously, I contacted the owner, and he said that he didn't care about specifying a license. I guess that means that we can pick one ;)
If this is really possible (but I doubt that) I suggest we pick the license that Just had for his logo: """ .... If you do not agree with this LICENSE, you had better not looked at THE LOGO. """ http://starship.python.net/~just/pythonpowered/ Thomas
Georg Brandl wrote:
As I posted here previously, I contacted the owner, and he said that he didn't care about specifying a license. I guess that means that we can pick one ;)
Can you please ask whether he would be willing to fill out a contrib form (http://www.python.org/psf/contrib/contrib-form/)? Without some kind of explicit contribution, I hesitate to use it. Regards, Martin
[Georg Brandl]
As I posted here previously, I contacted the owner, and he said that he didn't care about specifying a license. I guess that means that we can pick one ;)
[Martin v. Löwis]
Can you please ask whether he would be willing to fill out a contrib form (http://www.python.org/psf/contrib/contrib-form/)? Without some kind of explicit contribution, I hesitate to use it.
Me too, but stronger than hesitation. Georg, if he doesn't sign a contrib form, we have no legal right to distribute his work, or to license Python's users to (re)distribute it either. That's just the way the world works. Or if the fellow just doesn't want to bother picking the "initial license" the contrib form requires, tell him to pick the Academic Free License, Version 2.1. Well, you should actually ask him to ask his lawyer to decide that with him, but since I'm not on hallucinogens at the moment, making the choice for him is the only thing that will work in the real world -- it just has to look like it was his choice ;-)
participants (11)
-
"Martin v. Löwis" -
A.M. Kuchling -
Collin Winter -
Georg Brandl -
Guido van Rossum -
Michael Hudson -
Neal Norwitz -
Nick Coghlan -
Ronald Oussoren -
Thomas Heller -
Tim Peters