Re: [Python-Dev] Choosing a best practice solution for Python/extension modules
So go ahead and tear this apart so that we can hopefully reach a consensus that makes sense so that at least testing can easily be done. If I was developing an application and wanted to deal with two different versions of the same library, I would simply make sure that the version I wanted to use was first on sys.path. Perhaps something such as: lib/python-3.0/libdynload/ # extension module implementations lib/python-3.0/libpython/ # pure python implementations Then in the test suite simply ensure that either the Python implementation or the C implementation is first on sys.path. Both directories would contain an _pickle.py module, and then pickle.py could be changed from: try: from _pickle import * except ImportError: Pickler, Unpickler = _Pickler, _Unpickler To just: from _pickle import Pickler, Unpickler By default libdynload would be first on sys.path so that extension modules would be imported first if available, otherwise it would fallback to the pure Python versions. The test suite could then add/ remove libdynload from sys.path as needed. Well, OK, so this is a pretty big change as to how standard lib files are structured - so maybe there are quite a few reasons why this isn't feasable ... but it does make things a lot simpler and gets rid of the need for performing any magic with the loaded modules in the test suite. ___ 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] "setuptools has divided the Python community"
On Mar 25, 2009, at 5:25 AM, Antoine Pitrou wrote: Paul Moore gmail.com> writes: 3. Setuptools, unfortunately, has divided the Python distribution community quite badly. Wait a little bit, and it's gonna be even worse, now that buildout and pip seem to become popular. For example, the TurboGears people are considering switching from setuptools to pip... Tarek is now doing a lot of very useful work on distutils (thanks Tarek!), but I'm not sure it'll be enough to stop people from converting to whatever of the many build/packaging systems which have been popping up recently. Combined with the current trend that everything must be exploded into lots of interdependent but separately packaged libraries (the paste/pylons syndrome... try pulling something like TurboGears2 and see how many third-party packages it installs), I fear this is going to generate a very painful user/developer experience :-( From my perspective (the Python web community), setuptools has been a great uniter of community. By making it easier to break-up large projects into smaller distributions, it's now reasonable to share more code between more developers. This is an important philosophy of TurboGears 2, in that they're bringing together different pieces of Python web parts and composing them into a single framework. I think it's great that when I'm working on a Zope-based project I can participate in packages produced by the non-Zope ecosystem. This builds much greater bridges across sub-communites than smaller barriers put up such as one project using pip and another using easy_install. Heck, even when only wanting to share code between a couple personal projects, the barrier is now low enough that it's reasonable to package up that code and share a distribution, when in the past the only way to share that code was nasty copy-n-paste. Yes, there is pain in learning to use these tools, but it's mostly a documentation issue. Once you've learned the tools, it can be very easy to manage a very large amount of packages. Thanks to Buildout (luv the Buildout!) it's so much easier today to deploy a Zope- based application today than it was 5 years ago, even though a Zope- based application 5 years ago used a single monolithic Zope distribution and a Zope-based application today is composed of many, many smaller distributions. I'm very happy that I can so easily incorporate 3rd party libraries into my projects, it makes for a very pleasant developer experience :-) ___ 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] "setuptools has divided the Python community"
On Mar 27, 2009, at 6:22 PM, P.J. Eby wrote: At 10:22 PM 3/27/2009 +0100, M.-A. Lemburg wrote: Perhaps someone should start working on a tool called "FryingPan" to create "Omelettes", ie. all eggs squashed into a single ZIP file... ;-) They're called baskets actually. ;-) There's no tool to do it, but pkg_resources does support multiple eggs being contained in the same zipfile. And omelettes are when you take a collection of unzipped eggs and symlink into them to create a "flat" view of the files those eggs provide. (or at least that's the term used in Plone land after they switched to eggs and wrote the collective.recipe.omelette recipe for Buildout to make creating these symlinks easy) http://pypi.python.org/pypi/collective.recipe.omelette There is also a recipe for use with Buildout for gathering a collection of eggs and putting them all in a basket called z3c.recipe.eggbasket. Although that's a little different than having a basket as a zip file with multiple eggs in an installed location, since the z3c.recipe.eggbasket is for sending a bunch of eggs over the internet all in one go, with the idea that that file is uncompressed once the eggs are installed ... because you need to take the eggs out of the basket before you bake an omelette :P http://pypi.python.org/pypi/z3c.recipe.eggbasket ___ 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] My summit notes (packaging)
On Mar 27, 2009, at 6:25 PM, P.J. Eby wrote:
At 03:06 PM 3/27/2009 -0500, Tarek Ziadé wrote:
They both aim at the
same goal besides a few differences, and they both rely
on a new metadata introduced by setuptools, wich is.
"install_requires". This new metadata extends the metadata.
described in PEP 314 but is slightly different from.
what is descibred in the Draft PEP 345 ("Requires").
..
PEP 345 introduces "Requires" and "Provides" wich are
are implemented in Distutils and PyP, but are not
widely used. 40 out of +4000 if I remember correctly. Martin will
correct me here if I am wrong.
FYI, The reason setuptools uses a different way of specifying
requirements is that the PEP-proposed way could not be used without
some kind of indexed repository of packages -- and PyPI did not
index "provides" at the time. Also, the PEP-proposed versioning
scheme was not compatible with the versioning schemes actually used
in the field at the time.
These conditions could be considered to have changed now, or be
changeable given enough will and volunteer effort. Since setuptools
was only a 1.5-person effort back in the day (i.e., me plus
occasional contribs from Ian Bicking, Bob Ippolito, and Jim Fulton),
and backward compatibility was a critical requirement to get
adoption, using RPM-style provides/requires was not an option at
that time.
Tarek, was there any further discussion on "Requires" vs
"install_requires" or any decisions made on what to do about this?
(I've got a +1 ready for including 'install_requires' in the standard
package metadata and marking 'Requires' as deprecated if that was put
forth :P)
From what I understand of PEP 345's "Requires" and "Provides" fields
is that it's not possible to use them unambigously? For example, if
I'm working on a Python project and want to depend upon a project that
provides a 'utils' module, there could be several packages on PyPI
that declare they provide a 'utils' module. Which project would get
picked then?
It's also a lot more succinct to just spell out the project name in
the "install_requires" field than to have to list all of the modules
and packages you expect to use in the project you are depending upon.
For example, this is pretty reasonable:
install_requires: Django
And this is a disaster:
Requires: django
Requires: django.conf
Requires: django.contrib
Requires: django.contrib.admin
Requires: django.contrib.admindocs
Requires: django.contrib.auth
Requires: django.contrib.comments
Requires: django.contrib.contenttypes
Requires: django.contrib.csrf
Requires: django.contrib.databrowse
Requires: django.contrib.flatpages
Requires: django.contrib.formtools
Requires: django.contrib.gis
Requires: django.contrib.humanize
Requires: django.contrib.localflavor
Requires: django.contrib.markup
Requires: django.contrib.redirects
Requires: django.contrib.sessions
Requires: django.contrib.sitemaps
Requires: django.contrib.sites
Requires: django.contrib.syndication
Requires: django.contrib.webdesign
Requires: django.core
Requires: django.db
Requires: django.dispatch
Requires: django.forms
Requires: django.http
Requires: django.middleware
Requires: django.shortcuts
Requires: django.template
Requires: django.templatetags
Requires: django.test
Requires: django.utils
Requires: django.views
Not to mention that if you were upgrading to a newer version of Django
you'd could no longer just say '1.0' or '1.1' in 'install_requires'
but would instead have to fiddle with the Requires list to match newly
introduced modules and packages. I guess one is supposed to just list
"Requires: django" since that would resolve to the Django project
which, and it's implied that it would then provide everything else? Or
perhaps one is supposed to comb through their code and just list the
particular bits of Django that they're importing and using? There are
other times when a project may provide several top-level packages, and
again it's a lot easier to just ask for the project name rather than
list all of the top-level packages (usually this type of project is
kept on an private package server where it's reasonable to occupy
common top-level names such as 'utils' without worrying too much about
naming conflicts). Additionally, consuming the "Requires" field is
always more work, since you need to do some kind of look-up to go from
module/package name to project name before you can fetch a
distribution for that project.
___
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] #!/usr/bin/env python --> python3 where applicable
On Apr 18, 2009, at 1:08 PM, Mitchell L Model wrote: Some library files, such as pdb.py, begin with #!/usr/bin/env python In various discussions regarding some issues I submitted I was told that the decision had been made to call Python 3.x release executables python3. (One of the conflicts I ran into when I made 'python' a link to python3.1 was that some tools used in making the HTML documentation haven't been upgraded to run with 3.) Shouldn't all library files that begin with the above line be changed so that they read 'python3' instead of python? Perhaps I should have just filed this as an issue, but I'm not confident of the state of the plan to move to python3 as the official executable name. Hrmm ... On installing from source, one either gets: ./bin/python3.0 Or is using 'make fullinstall': ./bin/python So the default and the tutorial (http://docs.python.org/3.0/tutorial/interpreter.html ) refer to 'python3.0'. But I've done all my Python installs with 'make fullinstall' and then just manage my environment such that 'python' points to a 2.x or 3.x release depending upon what the source code I'm working on requires. If using something such as the Mac OS X Installer you'll get both a 'python' and 'python3.0'. Are there some Python installers that provide './bin/python3'? But if there sometimes just 'python', 'python3.0' or 'python3' then it's not possible for the shebang to work with both all known install methods ... One could argue that executable files part of the python standard library should have their interpreter hard-coded to the python interpreter to which they are installed with, e.g.: #!/Users/kteague/shared/python-3.0.1/bin/python Of course, this would remove the ability for a Python installation to be re-located ... if you wanted to move the install, you'd need to re- install it in order to maintain the proper shebangs. But it would mean that these scripts would also use the correct interpreter regardless of a user's current environemnt. Or, if the standard library was packaged such that all of it's scripts were advertised as console_scripts in the entry_points, it'd be easier for different install approaches to decide how to write out the shebang or to instead provide wrapper scripts for accessing those entry points (since it might be nice to have a ./bin/pdb). But that's a bit pie-in-the-sky since entry_points isn't even yet a part of the Distutils Metadata. ___ 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 376
A plural class name looks strange (I think it's the first time I see one in the CPython codebase). How about another name? (DistributionPool, DistributionMap, WorkingSet etc.). Sure, WorkingSet is nice, it's the name used in setuptools, A WorkingSet and a DistributionDirectories (or whatever it gets named to) are different things though, no? A WorkingSet is "a collection of active distributions", where each distribution might come from different distribution directories: http://peak.telecommunity.com/DevCenter/PkgResources#workingset-objects Where as DistributionDirectories is a dictionary of locations where distributions are installed. The WorkingSet may be comprised of distributions from several different locations, and each location may contain the same or different versions of the same distribution. (as far as I understand things ...) I can't really think of a better name for a dict of distribution locations ... but then I'm not averse to a pluralized class name. Overall though, I think PEP 376 is starting to look very good! ___ 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 376
On Jun 30, 2009, at 4:46 PM, Tarek Ziadé wrote: On Tue, Jun 30, 2009 at 10:06 PM, Scott David Daniels wrote: Tarek Ziadé wrote: On Tue, Jun 30, 2009 at 8:37 PM, Paul Moore wrote: [1] I'd actually like it if the PEP defined an uninstall command - something like "python -m distutils.uninstall packagename". It can be as minimalist as you like, but I'd like to see it present. it's already there: http://www.python.org/dev/peps/pep-0376/#adding-an-uninstall- function That (at least as I read it) is a function, not a command. If it is a command, give an example of its use from the command line for us poor "don't want to research" people. If the following works: $ python setup.py uninstall some_package Then explicitly say so for us poor schlubs. Right, I'll add that. Although it will be a reference implementation only. Uninstall as a command feels a little weird. Since "python setup.py [some-command]" implies that the setup.py contains information about the distribution that the command is being applied to. So instead of: $ python setup.py uninstall some_package It could just be: $ python setup.py uninstall Except then you'd need to have a complete distribution kicking around with which to run the "python setup.py uninstall" command just to tell the uninstall command the distribution name you want to uninstall. But then with the other uninstall format you could uninstall any distribution from within any other distribution, which is convenient, but weird ... e.g.: $ cd Spam-1.0/ $ python setup.py uninstall Foo Although even the other version of the command could do weird stuff: $ cd Spam-1.0/ $ python setup.py install $ cd ../Spam-2.0/ $ python setup.py uninstall Which would presumably remove the Spam 1.0 distribution when run from the 2.0 version of it! Or perhaps this command should only allow uninstall to be run from a distribution whose name and version match the one that it was installed from ... I dunno what the right solution is. My two-cents is either to punt and only include an uninstall function as currently proposed, or for only supporting some form of the "python setup.py uninstall" style since I would guess that the most common use-case for uninstall is: user downloads a distribution, runs "python setup.py install", tries out the package, decides they don't like package, then runs "python setup.py uninstall" to restore their python back to it's original state. For doing anything more complex than that, people should be encouraged to use another one of the existing tools for managing their distributions, IMHO. ___ 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 370 and IronPython
On Oct 10, 2009, at 2:17 PM, Brett Cannon wrote: The one unfortunate thing about this proposal is how this is going to mean I have to install a package potentially four times if I want it available to all possible Python interpreters. Then again, the chances of anyone beyond the people on this mailing list using more than a single interpreter regularly is so small that bothering to add support for yet another user directory that works on any Python interpreter will not be worth it. Yeah, I imagine that the use-case of wanting to re-use a shared set of packages between multiple interpreter implementations is relatively small. But if you did want to do so, you could just export the location for your (PYTHONIMPLEMENTATIONNAME)PATH to the location you want to re-use and off you go ... ___ 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] standard libraries don't behave like standard 'libraries'
On Nov 12, 2009, at 11:57 AM, Jesse Noller wrote: On Thu, Nov 12, 2009 at 2:38 PM, "Martin v. Löwis" wrote: I am not an expert, I am just another python learner. These are just my views on the state of the standard libraries and to make them state-of-the-art..! ;) If I understand correctly, you want the (current) standard library to be separated from the Python implementation, and available separately. Interestingly enough, people are very much split over whether that would be a good thing or not. Some like it the way Python does, some dislike it (and some quite strongly so). In any case, many Python users consider it a good thing that it comes "with batteries included", ie. with no need to add extra stuff for many tasks. Some of the Python maintainers have recently started objecting to this setup, asking that the standard library should be split into separate packages that are released and distributed independent of Python. Others of us feel strongly that such a change should not be made. So don't expect any immediate change to happen. Regards, Martin Martin is correct; this came up on distutils-sig a month or so ago; I proposed offering multiple downloads "with batteries" and "without batteries (with the batteries on the side)". We decided as a group to hold off on that until further in the future. jesse It's also worth noting that there are three issues with respect to standard library packaging which are all orthologous: * Packaging for metadata: The standard library could be packaged so that there is consistent metadata about the distributions which compromise the standard library (version, author, maintainer, etc). This could be useful so that it would be easier to see at a glance which packages changed between any two Python releases. For example, I have a script which compares two working sets of packages and generates a web page with a colour-coded list of differences between those two working sets, based on the size of the version number bump, e.g. major.medium.minor (doesn't work with packages which use odd version numbering schemes). I've used this to compare working sets between different Grok releases or Plone releases to help see where the activity or major API changes might be happening inside any given Zope-based release. However, this script only works on 80% of the code, the other 20% is in the standard library, which is currently a black-box. Also, if PEP 376 is accepted, then the standard library will be inviolation of the stanard metadata for installed packages unless this happens. * Packaging for release: The standard library could be packaged so that releases happen on PyPI. This could be useful so that it's easier to consume newer versions of a package before those packages are included in the next Python release. It could also make Python upgrades easier, as you could hold-back packages which might otherwise break an application upon upgrade. I happened to find a bug in a standard library package today, and currently my option is to: Submit bug report to PyPI, wait for Python 2.7 release, then wait for Plone to update to Python 2.7. I'm looking at many years before this fix goes into my production application, so in the meantime I need to maintain a work-around for the bug as well account for the day when this bug is fixed. It makes a mess of the code. If it was possible to release this package on PyPI, this could reasonably happen in a few days or at worst a couple months. The setup.py for that package could be updated to require the newer version of the package, and the workaround could be removed from the code. * Packaging for resizing: The standard library could be packaged so that it could be made smaller or larger, or there could be different sized standard libraries made with different Python releases. So there are benefits to packaging the standard library which would be useful, for reasons which would have no impact on the "batteries included" aspect of Python. Plus, if the standard library was packaged and releases were made on PyPI (in addition to including them normally in the Python releases), we *might* be able to use PyPI's commenting infrastructure on this packages (~evil grin~). ___ 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] standard libraries don't behave like standard 'libraries'
On Nov 13, 2009, at 6:23 PM, Greg Ewing wrote: Martin v. Löwis wrote: > Some of the Python maintainers have recently started objecting to this > setup, asking that the standard library should be split into separate > packages that are released and distributed independent of Python. Others > of us feel strongly that such a change should not be made. I'd be worried, because I would no longer be able to release an app or package and say "requires Python x.y". I'd have to list the version numbers of all the micro packages making up the standard library that I use. Worse, I'd have to be aware of which ones I actually *do* use so I could mantain that list, something I don't have to think about at the moment. "requires Python x.y" would imply a dependency on the working set of micro-packages which were shipped with that version of Python (or more specifically, any working set that was released within a particular Python release series). You would only need to list packages from the standard library as dependencies in special-case circumstances where you required a version higher or lower than what shipped with a particular release series of Python. It would perhaps increase the potential for people to get into situations where they update a Python with newer packages which makes it incompatibe with other Python applications. This problem would be mitgated by the fact that the standard library tends to be very API stable, so usually newer releases only contain minor bug fixes or performance enhancements and are unlikely to cause breakage. Package installation tools would also still continue to install into site- packages, or ideally in a virtualenv or script-generation environement like Buildout does. So installing updates to the standard library could be done only to support those applications which require them, but leave the default working set untouched for any other Python applications. Conversely, it may also help the standard library compatability in some situations, as I've seen people copy newer files into the standard library locations as a method of applying bug fixes, and given a better set of metadata it would then be more natural to use tools which allowed updates to happen in an orderly fashion. That's all given that splitting the standard library into individual packages also continues to release a single standard library. I don't really think releases small/medium/large sized standard libraries as was also discussed is a good idea. Maybe usage of tools such as virtualenv and buildout aren't yet widespread enough to alleviate people mucking up their installations in such a way that causes them pain. And this would also make it easier for people to develop applications which would be harder to pakcage into linux distributions or other package managers which don't allow for non-global updates. However, these are only theoretical concerns. It's concrete issue such as this one: http://stackoverflow.com/questions/1734373/including-package-data-with-distribute/ Where a developer uses something in the standard library, and a python- dev commiter provides a fix very quickly (yay Tarek!). But then that developer has to be told to wait a year until the next Python release, then wait until you've got the time to migrate the rest of your application to the new Python release, then you can finally use that fix, and in the meantime even though the issue has been solved you still need to workaround the problem! It's issues like this where it's hard not to want to avoid using standard library packages (beyond "core" modules which stable and only change very rarely lke os, sys, re, etc.) because there are unneccessary roadblocks between developer and user. ___ 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] Monkeypatching idioms -- elegant or ugly?
+1 on having established Python idioms for these techniques. While I don't know if there has ever been a formal definition of monkey patch, the term monkey patch came from guerilla patch, which came from two or more dynamic modifications to a class interfering with each other. These modifications were usually made by extension code (Zope add-on Products) to upstream code (the Zope framework), so I would define a monkey patch only as dynamic modifications made to a class with the *intent to change or correct behaviour in upstream code*. The term has also caught on with the a second definition of referring to any dynamic modification of class, regardless of intent though. I would perhaps call these methods something like: * add_method_to_class * extend_class This gives you a better idea of what they do, rather than use a term with a somewhat ambigous definition. With monkeypatch_method under the definition of "altering existing upstream behviour", I might expect it to raise an error if the method I was replacing on a class did not exist (e.g. upstream code was refactored so my patch no longer applied). ___ 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] [ANN] Python 2.3.7 and 2.4.5, release candidate 1
"It has to do with the MACOSX_DEPLOYMENT_TARGET. If it's set to 10.4, the legacy version of setpgrp is used (with args), it it's 10.5, setpgrp expects no arguments. It seems configure won't detect the difference." http://bugs.python.org/issue1358 This issue was fixed for Python 2.5. As the issue notes, you can work around it with: ./configure MACOSX_DEPLOYMENT_TARGET=10.5 But it would be really nice if the configure fix for 2.5 was backported to 2.4.5 since Zope is still on 2.4 and Mac OS X skipped system builds for 2.4 going direct from 2.3 -> 2.5. ___ 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] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)
On Sep 4, 2008, at 8:10 AM, C. Titus Brown wrote: I have to say I've never had problems with a stock install of Python on either Mac OS X or Windows (shockingly enough :). I think this is good advice for applications that rely on external libraries, but I just don't see any problems with relying on Python 2.5 to contain all the things that normally come with Python 2.5. There can be subtle differences between a "stock" Python and the system Python on Mac OS X 10.5. For example, Mac OS X compiles against EditLine instead of GNU Readline. From "man python" on Mac OS X: """ The Python inteterpreter supports editing of the current input line and history substitution, similar to facilities found in the Korn shell and the GNU Bash shell. However, rather than being implemented using the GNU Readline library, this Python interpreter uses the BSD EditLine library editline(3) with a GNU Readline emulation layer. ... For example, the rlcompleter module, which defines a completion function for the readline modules, works correctly with the EditLine libraries, but needs to be initialized somewhat differently: ... """ Fairly rare that you'd trip over this minor difference though - EditLine is more a problem on Mac OS X when trying to compile your own Python, since you need to install and link against GNU Readline. However, all does not seem to be right with the bsddb module on the system Python 2.5 on Mac OS X 10.5: $ /usr/bin/python Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb Traceback (most recent call last): File "", line 1, in File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/bsddb/__init__.py", line 51, in import _bsddb ImportError: No module named _bsddb >>> ___ 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] 3.1 focus (was Re: for __future__ import planning)
On Oct 4, 2008, at 9:59 PM, Martin v. Löwis wrote: Setuptools declares dependencies, but does not add a Python version requirement, like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/ ) with a new metadata called 'Requires Python' Even if the problem is fixed in short term with a Trove classifier, Why would that be a short-term fix? It would work for the entire life time of Python 3, and can be easily extended for Python 4, so it sounds like a permanent solution to me. As a permanent solution, you need to keep the problem statement in mind, though: to allow people to determine whether a package works with Python 3. The Setuptools dependencies fields are only for declaring library dependencies, not dependencies such as the Python interpreter. A problem with overloading the Categories field with Python version compatability information is that it makes for a poor user-interface. On the release page for a package, I'd rather see a Python Version field than having to look through a potentially large list of Categories. There is a "Py Version" field for file uploads (which I'd really like to tweak the UI to read "Python Version"), maybe if you could specify for uploads of the "source" type the Python compatability of the source file? Even without Python 3 it would be nice to upload a source file and indicate that you've used a Python 2.5 or 2.6ism in your code (or made use of newer standard library modules). Although this raises the question, what is the recommended practice for version numbering for distributions attempting to support both Python 2 and 3? Say I have a distribution that I've made work with Python 2.6 and can run on Python 3 after running it through 2to3. The source code is different so that to me suggests different version numbers - but the API will be the same, so maybe the same version number should be used? That is should there be? foobar-1.0-py2.6.tar.gz foobar-1.0-py3.0.tar.gz Or should it be something like? foobar-1.0.tar.gz # Python 2 foobar-1.1.tar.gz # Python 3 Well, writing out that last example looks wrong to me, since 1.0 -> 1.1 suggests bug fixes and API changes to the package. But someone could be thinking, "1.0 supports the Python 2 API and 1.1 supports the Python 3 language API". So at any rate it'd be good to make the way to handle this explicit in the (yet to be created) "2to3 central" documentation resource. ___ 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
