[Python-Dev] Need Survey Answers from Core Developers
Time is short and I'm still looking for answers to some questions about cPython, so that it makes a good showing in the Forrester survey. 1) How is the project governed? How does the community make decisions on what goes into a release? You know, I've been a member of the Python community for many years -- I know about PEPs, Guido as BDFL, and +1/-1. But I've never figured out exactly how -final- decisions are made on what goes into a release. I've never needed to, until now. Can someone explain in one paragraph? 2) Does the language have a formal defined release plan? I know Zope 3's release plan, every six months, but not that of Python. Is there a requirement to push a release out the door every N months, as some projects do, or is each release separately negotiated with developers around a planned set of features? 3) Some crude idea of how many new major and minor features were added in the last release? Yes, I know this is difficult -- the idea it so get some measure of the evolution/stability of cPython re features. Jython and IronPython are probably changing rapidly -- cPython, not such much. 4) How many committers to the cPython core are there? I don't have the necessary access to the pydotorg infrastructure to answer this -- can someone who does help me out here? Thanks for any one-line answers you can dash off to me today. Jeff Rush Python Advocacy Coordinator ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [Pydotorg] Upgrade of {www,svn}.python.org
Martin v. Löwis wrote: > I'd like to upgrade www.python.org this coming Thursday (June 21), > between 6:00am and 12:00am UTC. During that time, neither www > nor subversion access will be available (although I hope that > I need much less than 6 hours). > > mail.python.org, and all other services running on other machines, > will continue to work. Is this a software version upgrade or a hardware upgrade re the increase in hard disk space recently mentioned by Sean? If you're already physically at the machine, it'd be nice to get an additional drive added at the same time. -Jeff ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [Distutils] PEP 365 (Adding the pkg_resources module)
Guido van Rossum wrote: > On Mon, Mar 17, 2008 at 11:35 AM, Paul Moore <[EMAIL PROTECTED]> wrote: >> >> I'm +lots on someone giving a clear explanation of the meaning and >> interrelationship of the various terms involved in this discussion >> (setuptools, easy_install, pkg_resources, eggs, "package managers" as >> distinct from setuptools, etc etc) so that the discussion gets some >> much-needed clarity :-( > > Right. But finding someone who can explain all this is apparently > hard. All the owners of package managers seem busy... In preparing for my PyCon 2008 tutorial on eggs and buildout, I spent three full-time weeks carefully going over sources for distutils, setuptools and buildout to discover those aspects not documented. I can explain how they work, although I'm not sure this is the correct forum. I'd like to first offer my slides from my tutorial, 150 of them with detailed handout notes on many of them. http://wiki.python.org/moin/buildout/pycon2008_tutorial I'm happy to answer questions after that. I'm in the Hanada B room for OLPC at PyCon and on IRC #pycon. -Jeff ___ 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/archive%40mail-archive.com
[Python-Dev] Capsule Summary of Some Packaging/Deployment Technology Concerns
I was in a Packaging BoF yesterday and, although not very relevant to the packager bootstrap thread, Guido has asked me to post some of the concerns. The BoF drew about 15 people, many of whom were packagers for Red Hat, Ubuntu and such. Everyone had strong expressions of frustration with the status quo and most had tried to resolve their issues but had their patches rejected. I am not taking either side and whether those rejections were justified I cannot say, but the general feeling of their concerns intentionally not being addressed isn't healthy. Several had abandoned setuptools, deeming it a failed solution and others called for a fork. To start, I am not a leader of the group nor do I claim I accurately captured and expressed all their concerns. I apologize to those in the BoF for any misrepresentations. 1. Many felt the existing dependency resolver was not correct. They wanted a full tree traversal resulting in an intersection of all restrictions, instead of a first-acceptable-solution approach taking now, which can result in top-level dependencies not being enforced upon lower levels. The latter is faster however. One solution would be to make the resolver pluggable. 2. People want a solution for the handling of documentation. The distutils module has had commented out sections related to this for several years. 3. A more flexible internal handing of the different types of files is needed. Currently the code, data, lib, etc. files are aggregated at build time and people would like them to be kept separate until install/packaging time. They also want greater flexibility in the kinds of files identified for packaging. There is currently a single plugin entrypoint for file_finding, so people have resorted to abusing the setuptools function find_packages() again and again with different include/exclude args. A solution is to expand the set of entrypoints into finer grained categories. They also want a way to expand the set of categories rather than a fixed set, which can be easily done with entrypoint groups and names. People also want a greater variety of file_finders to be included with setuptools. Instead of just CVS and SVN, they want it to comprehend Mercurial, Bazaar, Git and so forth. 4. They want an uninstall setuptools command. Adding one to remove a specific egg isn't difficult but correctly removing those dependencies that came in with that egg, without breaking later installs can be tricky. This is complicated because there isn't a single global package namespace to manage, when you factor in virtualenv and buildout sandboxes and per-user package areas. This differs from how RPMs and .debs are viewed. 5. There was concern over the .pth mechanism used by setuptools re activation. First, there is a (perceived) performance issue with increasingly adding every ZIP file explicitly onto sys.path. This may or may not be a red herring. The other is the use of a single .pth file to control the list of activated packages. Those who produce distributions would prefer a magic directory into which links to distributions could be dropped, similar to the current best practices for Linux, with /etc/conf.d/, /etc/profile.d/, /etc/xinetd.d/ and so forth. 6. There is a need for more extensibility hooks. People want places to plug in special handling. For example: a) setuptools has a --record option to capture the list of files installed for use by subsequent packaging tools. Some want that list to be available to a setuptools plugin. b) some want hooks for post-build/post-install actions, instead of the current approach of writing a custom build class that handles it all. 7. Many wanted to ability to install files anywhere in the install tree and not just under the Python package. Under distutils this was possible but it was removed in setuptools for security reasons. Custom code can still be written to do this explicitly but this is not popular. Neither setuptools nor distutils has the ability to rename files at install time. A fair question is whether it is the job of setuptools (or any Python packaging solution) to cover all these bases. The risk of not doing the job is that some of those in attendance were rolling their own solutions which do not play well with packages installed using other means, not seeing them. Distutils has intentionally tried to -not- be a general replacement packaging solution, with its support of the "bdist" command for various platform-specific distribution formats. We should continue not trying to replace platform-specific packaging technologies but perhaps improve our control of their creation. As mentioned, some of these concerns can be resolved by adding customization-pressure-release entrypoints to setuptools, and some can be handled with much be
Re: [Python-Dev] [Distutils] Capsule Summary of Some Packaging/Deployment Technology Concerns
Marius Gedminas wrote: > On Mon, Mar 17, 2008 at 08:37:30PM -0400, Phillip J. Eby wrote: >> At 05:10 PM 3/17/2008 -0500, Jeff Rush wrote: >>> People also want a greater variety of file_finders to be included with >>> setuptools. Instead of just CVS and SVN, they want it to comprehend >>> Mercurial, Bazaar, Git and so forth. >> Did you point them to the Cheeseshop? There are plugins already >> available for all the systems you mentioned, plus Darcs and >> Monotone. If you mean "included" as in "bundled", this doesn't make >> a whole lot of sense to me. They knew there were plugins out there, of various quality and availability but wanted them bundled. ;-) It's a pain to track them down. Perhaps if the RPM format were broken out from setuptools, as the inclusion of some formats leads them to believe the set is just incomplete, not intentionally sparse. >> I'd think that if you're using >> setuptools as a developer (the only reason you need the file finders, >> since source distributions include a prebuilt manifest), you'd not >> have a problem saying "easy_install setuptools-git" or adding a >> "setup_requires='setuptools-git'" line to your setup.py. (Although >> the latter would only be needed for *development*, not deployment.) > > setup_requires looks like a solution, but it requires extra attention > from the developers who write the setup.py. Writing a setup.py is > already quite complicated -- I usually end up copying an existing one > and modifying it. As a compromise, of making new formats easily available but not bundled, and not requiring special action within setup.py, setuptools could treat --formats=dpkg as an implicit setup_requires= and pull it from PyPI. And the --list-formats option could query PyPI for the possibilities, just as --list-classifiers does today. If would require a few standards in keywording/classifying those format eggs but we already need those standards for other projects, such as locating recipes for buildout and plugins for trac. -Jeff ___ 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/archive%40mail-archive.com
[Python-Dev] The Breaking of distutils and PyPI for Python 3000?
As I'm digging into packaging issues here at PyCon, a couple of Python 3000 related matters occur to me. As I'm new to the Python 3000 development, if these have already been addressed in prior discussions, I apologize for your time. 1. What is the plan for PyPI when Python 3.0 comes out and dependencies start getting satisfied from distribution across the great divide, e.g. a 3.0-specific package pulls from PyPI a 2.x-specific package to meet some need? Are there plans to fork PyPI, apply special tags to uploads or what? While binary distributions are tagged with the Python version, source distributions are not. And of course a dependency expression as it stands today for "SomePackage > 2.4" may pull 3.0 to satisfy it. 2. There have been attempts over the years to fix distutils, with the last one being in 2006 by Anthony Baxter. He stated that a major hurdle was the strong demand to respect backward compatibility and he finally gave up. One of the purposes of Python 3.0 was the freedom to break backward compatibility for the sake of "doing the right thing". So is it now permissible to give distutils a good reworking and stop letting compatibility issues hold us back? -Jeff ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Capsule Summary of Some Packaging/Deployment Technology Concerns
Phillip J. Eby wrote: > > I'm actually happy to hear that there's this much energy available -- > hopefully some of it can be harnessed towards positive solutions. > > When I began developing setuptools, I often asked for the input of > packagers, developers, etc., through the distutils-sig... and was met > with overwhelming silence. So the fact that there is now a group of > people who are ready to work for some solutions seems like a positive > change, to me. I can appreciate how frustrating silence is when you call for input. Let's see if we can keep the volunteer energy going this time around. > It's hard to make design decisions regarding itches you don't personally > have, and which other people won't help scratch. Unfortunately, a lot > of the proposals from packaging system people have been of the form of, > "fix this for us by breaking things for other people". Not all of them, > though. Many have been very helpful, contributing troubleshooting help > and good patches. > > That some of those good patches took nearly a year to get into > setuptools (some from Fedora just got into 0.6c8 that were sent to me > almost a year ago) is because I'm the only person reviewing setuptools > patches, and I've spent only a few days in the last year doing focused > development work on setuptools (as opposed to answering questions about > it on the SIG). > > It's never a good thing when people's patches sit around, regardless of > where they come from. But that's not the same thing as *rejecting* the > patches. I and others appreciate your call for more patches on various topics. However a long delay in applying them will discourage contribution. Are you open to giving certain others patch view/commit privileges to setuptools? I'd be willing to help out, and keep a carefully balanced hand in what is accepted. -Jeff ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Capsule Summary of Some Packaging/Deployment Technology Concerns
Phillip J. Eby wrote: > At 03:57 AM 3/19/2008 -0500, Jeff Rush wrote: >> Are you open to giving certain others patch view/commit privileges to >> setuptools? > > Jim Fulton has such already. I'm open to extending that to others who > have a good grasp of the subtleties involved. > > Truthfully, if we can just get 0.6 put to bed, I could probably open up > the trunk a lot wider. What is needed to put 0.6 to bed? How can we help accelerate this? > Probably the most frustrating thing (or "chief amongst the most > frustrating things") about setuptools development is that it's a black > hole. By which I mean that backward compatibility and cruft accretion > make it difficult to get out of. > > In the beginning, there was the distutils. Distutils begat setuptools, > and setuptools begat virtualenv and zc.buildout and source control > plugins. Etc., etc. I've found in the past a revisiting of basic principles and objectives, communicated in enhanced documentation, can help to clear out such black holes. ;-) I'm pulling something together, from the recent emails and some archived threads -- it definitely is tangled though, I'll agree. > What I think is really needed in the long run is to keep eggs, but get > rid of setuptools and the distutils in their current form. There's a > lot of brokenness there, and also a lot of accumulated cruft. We really > need a distutils 3000, and it needs to be built on a better approach. That will require a lot of concensus building as well as collection of use cases so that the architecture team can encompass aspects they are not personally aware of. As you've said, it's hard to address itches that are not your own. It certainly is possible for someone to create a parallel packaging moduleset that uses the existing eggs format and PyPI but without the currently codebase, and then, once proven to work, lobby for it as distutils 3000. Frankly I'd like to see setuptools exploded, with those parts of general use folded back into the standard library, the creation of a set of non-implementation-specific documents of the distribution formats and behavior, leaving a small core of one implementation of how to do it and the door open for others to compete with their own implementation. > In truth, my *real* motivation for PEP 365's bootstrap tool isn't so > much to support the package management tools we have today, as it is to > support a new one tomorrow. I have a few ideas for ways to shift the > paradigm of how individual projects get built, to incorporate many > scenarios that don't work well now. But to implement those things in > such a next-generation tool, I will not want to be restricted to just > what's in the stdlib or what can be bundled in the tool. You should document those ideas someplace and start getting community input. There are a lot of diverse opinions on the right way to do this and the way ahead is quite unclear. > And I think it's probably getting close to time I stepped down from > day-to-day management of the codebase (which is more like month-to-month > or quarter-to-quarter for me lately). It will probably be a lot easier > for me to step back and critique stuff that goes in, after the fact, > than to go over the stuff beforehand. :) > > I'm not sure exactly how to go about such a handoff though. My guess is > that we need a bug/patch tracker, and a few people to review, test, and > apply. Maybe a transitional period during which I just say yea or nay > and let others do the test and apply, before opening it up entirely. > That way, we can perhaps solidify a few principles that I'd like to have > stay in place. (Like no arbitrary post-install code hooks.) I'll see about a tracker and identify some people to help out. > btw, offtopic question: are you by any chance the same Jeff Rush who > invented EchoMail? Yep, that's me. Not many remember the Fidonet days. I designed EchoMail on a napkin during a DFW Sysop pizza party during a conversation on what to do with the unused capability of inter-BBS private file transfers. It too escaped its ecosystem and spread like wildfire, almost getting banned from Fidonet. ;-) -Jeff ___ 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/archive%40mail-archive.com
Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?
Martin v. Löwis wrote: > > I don't see the need to for PyPI. For packages (or "distributions", > to avoid confusion with Python packages), I see two options: > > a) provide a single release that supports both 2.x and 3.x. > b) switch to Python 3 at some point (i.e. burn your bridges). > > You seem to be implying that some projects may release separate > source distributions. I cannot imagine why somebody would want > to do that. Yes, I am assuming that existing projects would at some point introduce a 3.x version and maybe continue a 2.x version as separate distros, similar to Python itself. Then the large number of existing unqualified dependencies on, say SQLObject, would pull in the higher 3.x version and crash. It's the older projects that don't get updated often that are at risk of being destabilized by the arrival of 3.x specific code in PyPI. Are developers for Python 3.x encouraged in 3.x guidelines to release 'fat' distributions that combine 2.x and 3.x usable versions? There is also some hassle with 2.x programmers browsing PyPI for useful modules to incorporate in their programs, downloading them (w/easy_install so they don't see the project website) and getting streams of errors because they unknowningly hit a 3.x-specific version. Perhaps a convention of a keyword or more likely a new trove classifier that spells outs 3.x stuff, with indicators on package info pages and query filters on PyPI against that? >> 2. There have been attempts over the years to fix distutils, >> with the last one being in 2006 by Anthony Baxter. He >> stated that a major hurdle was the strong demand to >> respect backward compatibility and he finally gave up. > > Can you kindly refer to some archived discussion for that? http://mail.python.org/pipermail/python-dev/2006-April/063943.html "I started looking at this. The number of complaints I got when I started on this that it would break the existing distutils based installers totally discouraged me. In addition, the existing distutils codebase is ... not good. It is flatly not possible to "fix" distutils and preserve backwards compatibility." -Anthony Baxter >> One of the purposes of Python 3.0 was the freedom to >> break backward compatibility for the sake of "doing >> the right thing". So is it now permissible to give >> distutils a good reworking and stop letting >> compatibility issues hold us back? > > I don't know what the proposed changes are, but for some > changes; in general, I feel that the need for backwards > compatibility is exaggerated. A controversial point, I'm afraid. Perhaps it is time for a parallel rewrite, so that those setup.py who import distutils get the old behavior, and those who import distutils2 get the new, and we let attrition and the community decide which is standard. -Jeff ___ 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/archive%40mail-archive.com
Re: [Python-Dev] The Breaking of distutils and PyPI for Python 3000?
Martin v. Löwis wrote: >> specific code in PyPI. Are developers for Python 3.x encouraged in >> 3.x guidelines to release 'fat' distributions that combine 2.x and 3.x >> usable versions? > > Passive voice is misleading here: encouraged by whom? "... encouraged in __3.x guidelines__ to ...": I presume although I've not found them yet that there is some kind of document for developers titled something like, "how to migrate your Python code from 2.x to 3.x". That document would be a logical place for advice and consideration of the tradeoffs of jumping to 3.x, maintaining two synced versions using 2to3 or 3to2, and the risks of keeping two independent releases. Identifying best practices would help them make good choices for the community. > *I* encourage people to consider that option, rather than assuming it > couldn't possibly work. Whether it actually works, I don't know. > I hope it would work, and I hope it would not be fat at all. So we don't have an actual success story of a dual-version distribution, even as a prototype, using 2to3 within a distutils package? I would not encourage a practice without at least one such example. >>> Can you kindly refer to some archived discussion for that? >> >> http://mail.python.org/pipermail/python-dev/2006-April/063943.html >> > Thanks. I still have the same position as I had then - if > distutils is broken, it should be fixed, not ignored. Since the precise API was not documented well and many people began to make use of ambiguous internal interfaces, such fixes would indeed break them. So your vote would be to do the right thing, even if it results in some breakage. I can respect that philosophy. >> A controversial point, I'm afraid. Perhaps it is time for a parallel >> rewrite, so that those setup.py who import distutils get the old >> behavior, and those who import distutils2 get the new, and we let >> attrition and the community decide which is standard. > > Is there a list of the problems with distutils somewhere? Unfortunately no. Much of it is anecdotal, much of it occurs on lists outside the Python community by those attempting to package things. And some of it are comments by developers who peeked into the distutils source and blanched. And some of the problems are not bugs, per se, but disagreement on scope of functionality and a lack of well-known alternatives. So just "fix it if broken" doesn't work when there is no agreement on how to expand that scope. I am working on pulling together such a list however, and getting it into the tracker, so that debate with a record of decisions can occur. I agree that it is hard to fix problems if no one is _clearly_ reporting them to us. Too much smoke, not enough light. > It always worked fine for me, so I see no reason to fix it in the > first place. Pardon my lack of knowledge of your background; when you say it always worked fine for you, are you referring to personal experiences using it to _install_ software or to experiences as a packager in actually distributing complex collections of modules on different platforms? -Jeff ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [Distutils] PEP 365 (Adding the pkg_resources module)
Paul Moore wrote: > On 20/03/2008, zooko <[EMAIL PROTECTED]> wrote: > I'll chime in here, too. I really want to like > setuptools/easy_install, but I don't. I'll try to be specific in my > reasons, in the hope that they can be addressed. I know some of these > are "known about", but one of my meta-dislikes of setuptools is that > known issues never seem to get addressed (I know, patches accepted, > but I haven't got the time either...) Clearly explained problems with the existing arrangement is valuable as well as patches. Thanks for taking the time to help us see your viewpoint. > 1. No integration with the system packager (Windows, in my case). If I > do easy_install nose, then nose does not show up in add/remove > programs. That significantly affects the way I manage my PC. Part of this stems from stretching of the original mission of setuptools, to install modules for Python, into a general-purpose application installation tool. The buildout tool is more suited for application installation, although not ideal yet. In your scenario, what happens when one egg pulls in another and another, until you have a hundred entries in your add/remove menu? And you don't understand the inter-relationship of those so you cannot do a clean uninstall? Similarly, or what do you want to appear in that add/remove menu when you are using independent sandboxes with various applications in them, some of which are accessible only to specific users who are not admins on that box? > 3. The pkg_resources documentation (in particular, that's the one I've > tried to follow) is extremely hard to read. Partly this is just style, > but it's partly because it is couched in very unfamiliar terms > (distributions, working sets, interfaces, providers, etc). It's also > *huge*. A tutorial style overview, supported by API detail, would be > far better. We'll get better docs. Of course, that module contains roughly five different sets of functionality, some of which can be used unrelated to the others so it's not just one API. > 4. Hard to use with limited connectivity. At work, I *only* have > access to the internet via Internet Explorer (MS based proxy). There > are workarounds, but ultimately "download an installer, then run it" > is a far simpler approach for me. This is hard to address using independent eggs re setuptools but fits buildout which provides for deployment of a set of related eggs as a single entity. I'll add it as a use case and see what we can do though. > 5. Auto-discovery doesn't always work. I'm sorry, I really can't > recall the example at the moment, but sometimes easy_install says it > can't find a package I *know* is available. I've hit a few of these myself, although it wasn't an issue with the auto-discovery mechanism but rather quality problems with PyPI itself. Some of the eggs only had binary distributions provided, and they were not for my platform so couldn't be used. Better error messages in this area would help, with encouragement to nag the original author to provide better data on PyPI. > 6. Splitting the community. Windows users rely heavily on binary > installers (at least, I do). We're starting to get a situation where > some projects provide .egg files, and some provide traditional > (bdist_wininst/bdist_msi) installers. This is bad. One way to do it, > and all that :-) Reporting and author nagging facilities built into PyPI could help encourage more consistent behavior. -Jeff ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Patch review: [ 1009811 ] Add missing types to__builtin__
On Thu, 2005-01-27 at 17:24, "Martin v. Löwis" wrote: > Raymond Hettinger wrote: > > Other than a vague feeling of completeness is there any reason this > > needs to be done? Is there anything useful that currently cannot be > > expressed without this new module? > > That I wonder myself, too. One reason is correct documentation. If the code is rejected, there should be a patch proposed to remove the erroneous documentation references that indicates things are in __builtins_ when they are in fact not. If they are put into __builtins__, the documentation won't need updating. ;-) -Jeff Rush ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Removing Non-Unicode Support?
Neal Norwitz wrote: > On 2/17/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > >>Neal Norwitz wrote: > > >>Another candidate for removal is the --disable-unicode >>switch. >> >>We should probably add a deprecation warning for that in >>Py 2.5 and then remove the hundreds of >>#idef Py_USING_UNICODE >>from the source code in time for Py 2.6. > > I've heard of a bunch of people using --disable-unicode. I'm not sure > if it's curiosity or if there are really production builds without > unicode. Ask this on c.l.p too. Such a switch quite likely is useful to those creating Python interpreters for small hand-held devices, where space is at a premium. I would hesitate to remove switches to drop features in general, for that reason. Although I have played with reducing the footprint of Python, I am not currently doing so. I could never get the footprint down sufficiently to make it usable, unfortunately. But I would like to see the Python developers maintain an awareness of memory consumption and not assume that Python is always run on modern fully-loaded desktops. We are seeing increasing use of Python in embedded systems these days. -Jeff ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Removing Non-Unicode Support?
Guido van Rossum wrote: > On 2/19/06, Jeff Rush <[EMAIL PROTECTED]> wrote: > [Quoting Neal Norwitz] > >>>I've heard of a bunch of people using --disable-unicode. I'm not sure >>>if it's curiosity or if there are really production builds without >>>unicode. Ask this on c.l.p too. >> > Do you know of any embedded platform that doesn't have unicode support > as a requirement? Python runs fine on Nokia phones running Symbian, > where *everything* is a Unicode string. 1. PalmOS, at least the last time I was involved with it. Python on a Palm is a very tight fit. 2. "GM862 Cellular Module with Python Interpreter" http://tinyurl.com/jgxz These may be dimishing markets as memory capacity increases and I wouldn't argue adding compile flags for such at this late date, but if the flags are already there, perhaps the slight inconvenience to Python-internal developers is worth it. Hey, perhaps dropping out Unicode support is not a big win - I just know it is useful at times to have a collection of flags to drop out floating point, complex arithmetic, language parsing and such for memory-constrained cases. -Jeff ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Removing Non-Unicode Support?
M.-A. Lemburg wrote: > I'd say that the parties interested in non-Unicode versions of > Python should maintain these branches of Python. Dito for other > stripped down versions. I understand where you're coming from but the embedded market I encounter tends to focus on the hardware side. If they can get a marketing star by grabbing Python off-the shelf, tweak the build and produce something to include with their product, they will. But if they have to maintain a branch, they'll just go with the defacto C API most such devices use. > Note that this does not mean that we should forget about memory > consumption issues. It's just that if there's only marginal > interest in certain special builds of Python, I don't see the > requirement for the Python core developers to maintain them. These requirements of customization may not be a strong case for today but could be impacting future growth of the language in certain sectors. I'm a rabid Python evangelist and alway try to push Python into more nooks and crannies of the marketplace, similar to how the Linux kernel is available from the tiniest machines to the largest iron. If the focus of Python is to be strictly a desktop, conventional (mostly ;-) language, restricting its adaptability to other less interesting environments may be a reasonable tradeoff to improve its maintainability. But adaptability, especially when you don't fully grok where or how it will be used, can also be a competitive advantage. -Jeff ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
On Friday 01 July 2005 10:45 am, Fred L. Drake, Jr. wrote: > On Friday 01 July 2005 11:44, Phillip J. Eby wrote: > > Resource managers. > > Yeah, I was thinking that, but was somewhat ambivalent. But I definately > like it better than anything else proposed so far. I like that as well. My hat in the ring would be "brackets" or "bracketed statements", implying there is something before, after and in the middle. Also not an acronym, and short. And while we're on naming issues... Regarding __enter__/__exit__ versus __enter__/__leave__, I like the latter not only because of ASM history but that the two are the same length, making documentation cleaner in some cases. ENTER: blah blah LEAVE: blah blah A minor item, but then I'm big on visual symmetry. ;-) -Jeff ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
On Thursday 28 July 2005 07:21 pm, Tim Peters wrote: > [Martin v. Löwis] > > > The conversion should be done using cvs2svn utility, available e.g. > > in the cvs2svn Debian package. The command for converting the Python > > repository is > > Sample results of this conversion are available at > > > > http://www.dcl.hpi.uni-potsdam.de/python/ > > http://www.dcl.hpi.uni-potsdam.de/distutils/ > > I'm sending this to Jim Fulton because he did the conversion of Zope > Corp's code base to SVN. Unfortunately, Jim will soon be out of touch > for several weeks. Jim, do you have time to summarize the high bits > of the problems you hit? IIRC, you didn't find any conversion script > at the time capable of doing the whole job as-is. If that's wrong, it > would be good to know that too. The conversion script isn't perfect and does fail on complex CVS arrangements or where there is extensive history to migate. However it appears above that Martin has already tried the script out, with success. BTW, re SSH access on python.org, using Apache's SSL support re https would provide as good of security without the risk of giving out shell accounts. SSL would encrypt the link and require a password or permit cert auth instead, same as SSH. Cert admin needn't be hard if only a single server cert is used, with client passwords, instead of client certs. -Jeff ___ 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/archive%40mail-archive.com
Re: [Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
Anthony Baxter wrote: > Rather than the back-n-forth about what the FSF might or might not do, > can we just ask them for an official opinion and settle the matter? > > Who would we need to talk to for a definitive answer? I'm sure there's > various FSF mailing lists where we could get 157 different potential > answers, but I'm talking about an actual, official FSF statement <0.5 > wink> From http://www.fsf.org/licensing/licenses/index_html: "If you want help choosing a license, evaluating a license, or have any other questions about licenses, you can email us at <[EMAIL PROTECTED]>." -Jeff ___ 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/archive%40mail-archive.com
