Re: [Python-Dev] Not releasing rc1 tonight
Barry Warsaw wrote: I'm not going to release rc1 tonight. There are too many open release blockers that I don't want to defer, and I'd like the buildbots to churn through the bsddb removal on all platforms. I'd like to try again on Friday and stick to rc2 on the 17th. any news on this front? (I have a few minor ET fixes, and possibly a Unicode 5.1 patch, but have had absolutely no time to spend on that. is the window still open?) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] HTTPS read-only SVN access is denied?
> SVN checkout over HTTPS protocol requires password. Is it intentional > or just temporary server issue? I am behind a proxy that doesn't > support PROPFIND requests and I can't test SVN+SSH, because 22 port is > closed. > > Site docs keep silence about that HTTPS is used at all. Shouldn't > authentication be asked only on write access in normal SVN setup? Not necessarily - as you say, it's undocumented (and will remain so); in any case, I have now granted anonymous read access to that repository, through https. That there was access at all was for the sake of a completely unrelated repository for which even anonymous read access is denied (and remains so). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Not releasing rc1 tonight
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 7, 2008, at 10:51 AM, Fredrik Lundh wrote: Barry Warsaw wrote: I'm not going to release rc1 tonight. There are too many open release blockers that I don't want to defer, and I'd like the buildbots to churn through the bsddb removal on all platforms. I'd like to try again on Friday and stick to rc2 on the 17th. any news on this front? (I have a few minor ET fixes, and possibly a Unicode 5.1 patch, but have had absolutely no time to spend on that. is the window still open?) There are 8 open release blockers, a few of which have patches that need review. So I think we are still not ready to release rc1. But it worries me because I think this is going to push the final release beyond our October 1st goal. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSMP6/3EjvBPtnXfVAQIprQQAsWgxQPKyxM/rrG5TWL4UqI7xne6dLTjL Nx3OBpi8hcNXEqyxzoosFXXZy4PpSWU+SwxuI1YQT9rUjv/ks6yxu3cBcEVhtEHV KE34YS4D825tVGvbvpsOXF06fsfv5j5zZGB6hlSipZoiv1rhR3uEsO2zkWaI4eQ6 Ty2Cfuxu10A= =8eP5 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.6 doc searching issue?
[EMAIL PROTECTED] schrieb: >>From this page: > > http://docs.python.org/dev/index.html > > I searched for "csv" and got just one hit: > > http://docs.python.org/dev/contents.html?highlight=csv > > Shouldn't it have at least matched the docs for the csv module itself, not > just the table of contents? It definitely should. We're currently working on improving the JS-based search to search object (module, function, class) names before trying full-text search. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] 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
On Thu, Sep 4, 2008 at 7:33 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote: > On Thu, Sep 04, 2008 at 03:23:22PM +0200, Jesus Cea wrote: >> Compared to sqlite, you don't need to know SQL, you can finetuning (for >> example, using ACI instead of ACID, deciding store by store), and you >> can do replication and distributed transactions (useful, for example, if >> your storage is bigger than a single machine capacity, like my case). > > Let me raise the glove. Compared to bsddb: > > -- SQLite is public domain; the licensing terms of Berkeley DB[1] are not > friendly to commercial applications: "Our open source license ... > permits use of Berkeley DB in open source projects or in applications > that are not distributed to third parties." I am not sure if using of > PyBSDDB in commercial applications is considered "using of Berkeley DB > in open source projects"; FWIW, many years ago in the past when I asked sleepycat about this (long before oracle bought them) they said that python was considered to be the application. Using berkeleydb via python for a commercial application did not require a berkeleydb license. But my legal advice is worth as much as the paper its printed on. Always ask your own lawyer and oracle about such things. -gps ___ Python-Dev mailing list [email protected] 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
On Thu, Sep 4, 2008 at 11:03 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote: > On Thu, Sep 04, 2008 at 07:40:28PM +0200, Jesus Cea wrote: >> A stable fileformat is useful for long term support, but an evolving >> format allows improvements. > > Once I upgraded Python on a Windows computer... I think it was 2.2 to > 2.3 upgrade - and all my bsddb databases stopped working. I cannot call > this "improvement". I didn't have db_upgarde on that computer (or I didn't > know about it). Does PyBSDDB have db_upgrade in the distribution? Does > Python distribution have db_upgrade? Unfortunately that is a bad example and should be blamed on python and not berkeleydb: Going from python 2.2 -> 2.3 was when the bsddb module was renamed to bsddb185 and the bsddb3 module was included as bsddb. It was an incompatible change because the underlying library was entirely replaced with something much much different despite happening to share the name and being made to support the same API. You could probably have built the bsddb185 module and loaded your data from that and rewritten it using the new bsddb module. The db upgrade API is available in the bsddb.db module. I never got around to writing the automatic on disk format upgrade code for the bsddb/__init__.py API. It wouldn't have solved the 2.2->2.3 problem but it would remove the need to know about db_upgrade in all future versions. fwiw, a precompiled berkeleydb with db_upgrade.exe and friends has always been available from sleepycat/oracle so a solution exists even if it wasn't nicely documented in a "reading your data when upgrading python HOWTO." >> Following your reasoning, Python should be >> keep in 1.0 era, for compatibility sake. > > Python? No. But persistent data structures? Yes! How many different > pickle data formats there were since Python 1.0? What is the oldest > pickle format modern Python can read? (Just using pickle as an example.) Python by itself won't solve your long term data warehousing needs. The SQLite project's on disk format has already changed at least once (sqlite2 -> sqlite3) and no doubt it could change again in the future. The lesson for python: when that happens lets write the code to make the transition between formats trivial. -gps ___ Python-Dev mailing list [email protected] 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 and sqlite
On Sun, Sep 07, 2008 at 11:34:37AM -0700, Gregory P. Smith wrote: > You could probably have built the bsddb185 module and loaded your data > from that and rewritten it using the new bsddb module. I built bsddb185, loaded old data, exported it to... I don't remember now, but I clearly remember I stopped using bsddb. > The lesson for python: when that happens lets write the code to make > the transition between formats trivial. For me the lesson is different - do not include modules in the stdlib that relies on unstable 3rd party libraries. I consider bsddb unstable. sqlite is more stable, but PySQLite... there are many minor releases between Python releases; my humble opinion is it'd be better to have one external PySQLite module than two (PySQLite and sqlite3). Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Not releasing rc1 tonight
Barry Warsaw wrote: (I have a few minor ET fixes, and possibly a Unicode 5.1 patch, but have had absolutely no time to spend on that. is the window still open?) There are 8 open release blockers, a few of which have patches that need review. So I think we are still not ready to release rc1. So what's the new ETA? Should I set aside some time to work on the patches, say, tomorrow, or is it too late? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [issue3769] Deprecate bsddb for removal in 3.0
On Thu, Sep 4, 2008 at 11:30 AM, Brett Cannon <[EMAIL PROTECTED]> wrote: > Another thing to keep in mind with the whole shelve/dbm.any argument > is that for 3.1 there is nothing saying we can't change shelve and the > dbm package to allow 3rd-party code to register with the dbm package > such that bsddb can be used as needed behind the scenes. > > -Brett Exactly. That is what I think should really happen here. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3rd party dbm (was: [issue3769] Deprecate bsddb for removal in 3.0)
On Sun, Sep 07, 2008 at 02:35:58PM -0700, Gregory P. Smith wrote:
> On Thu, Sep 4, 2008 at 11:30 AM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Another thing to keep in mind with the whole shelve/dbm.any argument
> > is that for 3.1 there is nothing saying we can't change shelve and the
> > dbm package to allow 3rd-party code to register with the dbm package
> > such that bsddb can be used as needed behind the scenes.
>
> Exactly. That is what I think should really happen here.
I will try to find a spare time to some job in the area. I am planning
API like this (in terms of Python 2.x with anydbm):
# dbm.something module
import anydbm
anydbm.register('something', whichdb_test_function)
whichdb_test_function is not required - whichdb module can provide
a generic test function:
def generic_test(filename, module_name):
module = __import__(module_name)
try:
module.open(filename)
except:
return False
else:
return True
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
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 and sqlite
Oleg Broytmann wrote: > On Sun, Sep 07, 2008 at 11:34:37AM -0700, Gregory P. Smith wrote: >> You could probably have built the bsddb185 module and loaded your data >> from that and rewritten it using the new bsddb module. > >I built bsddb185, loaded old data, exported it to... I don't remember > now, but I clearly remember I stopped using bsddb. > >> The lesson for python: when that happens lets write the code to make >> the transition between formats trivial. > >For me the lesson is different - do not include modules in the stdlib > that relies on unstable 3rd party libraries. I consider bsddb unstable. > sqlite is more stable, but PySQLite... there are many minor releases between > Python releases; my humble opinion is it'd be better to have one external > PySQLite module than two (PySQLite and sqlite3). > Unfortunately this advice should have been taken several years ago. The fact is that there are almost certainly Python users who rely on the presence of the bsddb module for production work, and simply removing it without deprecation is bound to upset those users. I'm particularly concerned that it appears that normal procedures have been circumvented to enable its removal from 3.0. Since we have at least one developer committed to ongoing support that seems both harsh and unnecessary. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] 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 and sqlite
On Sun, Sep 7, 2008 at 3:43 PM, Steve Holden <[EMAIL PROTECTED]> wrote: > Oleg Broytmann wrote: >> On Sun, Sep 07, 2008 at 11:34:37AM -0700, Gregory P. Smith wrote: >>> You could probably have built the bsddb185 module and loaded your data >>> from that and rewritten it using the new bsddb module. >> >>I built bsddb185, loaded old data, exported it to... I don't remember >> now, but I clearly remember I stopped using bsddb. >> >>> The lesson for python: when that happens lets write the code to make >>> the transition between formats trivial. >> >>For me the lesson is different - do not include modules in the stdlib >> that relies on unstable 3rd party libraries. I consider bsddb unstable. >> sqlite is more stable, but PySQLite... there are many minor releases between >> Python releases; my humble opinion is it'd be better to have one external >> PySQLite module than two (PySQLite and sqlite3). >> > Unfortunately this advice should have been taken several years ago. The > fact is that there are almost certainly Python users who rely on the > presence of the bsddb module for production work, and simply removing it > without deprecation is bound to upset those users. Those users would first have to port their code to Python 3.0. That task is a lot larger than dealing with a separate download of bsddb. It is not being removed from 2.6. > I'm particularly concerned that it appears that normal procedures have > been circumvented to enable its removal from 3.0. Since we have at least > one developer committed to ongoing support that seems both harsh and > unnecessary. 3.0 breaks a lot of things. Most of the library reorg may have been discussed more than this particular removal, but that doesn't mean that changes won't come as a surprise for most users. In this case, a completely compatible module is available as a 3rd party download. That's a lot less sever than the complete abandonment than the fat of many other modules. It's just a matter of source code packaging. Vendors can completely remove the difference in their packaging of the binaries. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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 and sqlite
>> Unfortunately this advice should have been taken several years >> ago. The fact is that there are almost certainly Python users who >> rely on the presence of the bsddb module for production work, and >> simply removing it without deprecation is bound to upset those users. Guido> Those users would first have to port their code to Python Guido> 3.0. That task is a lot larger than dealing with a separate Guido> download of bsddb. It is not being removed from 2.6. Perhaps 2.7 and 3.1 should have a conversion function at the dbm package level which will convert a database from one format to another, e.g.: dbm.convert(srcdb, dstdb, dstfmt) The format of srcdb should be discoverable from the file itself. Skip ___ Python-Dev mailing list [email protected] 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)
> I thought that all that was happening was that BSDDB was becoming a > separate project. If one needs BSDDB with Python2.6, one installs it. No, not in the way you mean it. > Aren't there other parts of Python that require external modules, such as > Tk? It's different. BSDDB (the Sleepycat-then-Oracle implementation) never was part of Python; this hasn't changed. What *has* changed is that the bsddb module (i.e. the Python wrapper) is now not part of Python anymore, either, due to it being maintained separately. This is as if Tkinter was removed from Python. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add python.exe to PATH environment variable
> FWIW, my opinion is similar to how I read Martin's - that if a suitable, > safe patch that cleanly uninstalls can be found, it should be included, but > disabled by default. Personally I'd never use it. That's my view also (less strict now; I previously would have rejected it outright, as I didn't consider that it might be optional and off by default). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add python.exe to PATH environment variable
>> I mean that many Windows use the PATH, and as such, may fail if a new >> directory is added to the PATH that contains a DLL they indirectly use. > > Then it's just a matter of not putting any DLLs in those directories, isn't > it? A. It's not just DLLs. Any program invoking CreateProcess might pick up the Python executable. This might be confusing if the program would previously pick up a different Python installation. B. I don't think this can work: we *must* install DLLs into the Python directory - at least pythonxy.dll (at least the way Python is currently build - maybe SxS would allow to place it elsewhere). I *think* we also need to place the CRT manifest in the directory; not sure what consequences this has. > Most Linux distributions solve that by installing binaries named > /usr/bin/python2.4, /usr/bin/python2.5, etc., and making /usr/bin/python a > symlink to one of those. Thus if a program relies on particular Python > version, > it can just use a specific executable rather than a generic one. Unfortunately, symlinks are not available on Windows. OTOH, other things *are* available, such as registered extensions. For example, you don't need python on PATH to start a Python script; just invoking the .py file will find the Python interpreter from the registry. I don't think it is wise to apply Unix solutions to Windows problems. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add python.exe to PATH environment variable
> A cleaner (though still dirty) way to achieve this would be to add a > link to the appropriate "python.exe" in a directory already on the path > such as c:\Windows\system32 That would be fairly easy to implement. I suppose pythonw.exe wouldn't need the same treatment, as people won't invoke it manually. I guess that option wouldn't be available to non-admin users, though. > My own solution, on systems where I haven't bothered to add \python25 > and python25\Scripts to the PATH, is to simply use > > \python25\python > > With tab expansion enabled by default it's easy enough. Same for me. That's why I like Python being installed in the root directory (also a common complaint - why doesn't it install into the Programs Files folder?) Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add python.exe to PATH environment variable
> May be an external program called by the uninstaller can take care > of this, removing what was added to PATH. Or a custom action. There are ways to solve this problem - they just take some effort to implement them. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] constness of interpreter data
> So, er, is this a remotely sane thing to be doing, and does anyone have > suggestions? :) Not for 2.6/3.0 - but after that: sounds good. OTOH, I don't see a clear technical *need* for these data to be const. In general, const-ness helps correctness and sharing across processes, and the cases you provide are correct and provide sharing even without being const. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
