Re: [Python-Dev] remaining issues from Klocwork static analysis
Martin v. Löwis wrote:
> Neal Norwitz wrote:
>> # 61 Modules/_sqlite/cursor.c:599 Null pointer may be dereferenced
>>
>> Null pointer 'self->statement' that comes from line 674 may be
>> dereferenced by passing argument 1 to function
>> 'statement_mark_dirty' at line 599.
>
> Looks like a problem. Maybe a break is missing after line 674?
The code is a bit complicated here, and admittedly not the nicest one,
but I verified it and there is no problem here.
_query_execute() is designed to handle both executemany() and execute().
multiple is a local variable that is 1 if there is a set of tuples of
SQL parameters (executemany) instead of a single tuple of SQL parameters
(execute), in which case it's 0.
Before the while loop, the code makes sure that parameters_iter is an
iterator that returns SQL parameter tuples. So if there is only a single
parameter tuple, a temporary list is created an parameters_iter is an
iterator over it.
So, if !multiple (referenced code in line 674), the while-loop will only
be executed once, and in the second loop, the while-loop will exit
because then the following code will break:
parameters = PyIter_Next(parameters_iter);
if (!parameters) {
break;
}
Code in line 599 is thus not executed with self->statement = 0.
-- Gerhard
___
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] Need help with C - problem in sqlite3 module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Looks like I don't know C so well after all ... Apparently at least gcc on Linux exports all symbols by default that are not static. This creates problems with Python extensions that export symbols that are also used in other contexts. For example some people use Python and the sqlite3 module under Apache, and the sqlite3 module exports a symbol cache_init, but cache_init is also used by Apache's mod_cache module. Thus there are crashes when using the sqlite3 module that only occur in the mod_python context. Can somebody with more knowledge about C tell me how to fix the sqlite3 module or compiler settings for distutils so that this does not happen? Of course this only happens because the sqlite3 module is distributed among multiple .c files and thus I couldn't make everything "static". Thanks in advance. - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFFW9UdIO4ozGCH14RApFQAKC+BJd8mGlCXJa89swOcMvASoj6GgCfZxf+ tZ/iVO8xTEV7qNeXBcDT0WU= =lX07 -END PGP SIGNATURE- ___ 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] Python 3000: confused about str8, str, bytes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I maintain the sqlite module in the standard library, which makes heavy use of PyString_* C API. Now I've made it work under Python 3000 insofar as tests pass, but the new Python string semantics mean I have more work to do here and make some API choices. I've read in another thread that the future of str8 is not decided yet. To be honest I was confused when I saw it first, it's documented nowhere as far as I can see. Is that decided yet? Is str8 going away? What will happen with the Python C API? Will PyString_* become what PyUnicode_* is in Python 2.x? - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwMw6dIO4ozGCH14RAoyEAJ0eoqZ8gSqKh5/HIXxhbG5xpMedLgCgquQV Qv+CGyoD8eSXaoAKzn2WBSM= =w4HB -END PGP SIGNATURE- ___ 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] Missing _sqlite checkin on trunk?
[EMAIL PROTECTED] wrote: > On Nov 25 Gerhard Haering checked in a change to the release25-maint branch: > > Author: gerhard.haering > Date: Sun Nov 25 18:40:35 2007 > New Revision: 59184 > > Modified: >python/branches/release25-maint/Modules/_sqlite/statement.c >python/branches/release25-maint/Modules/_sqlite/util.c > Log: > - Backported a workaround for a bug in SQLite 3.2.x/3.3.x versions where a > statement recompilation with no bound parameters lead to a segfault > - Backported a fix necessary because of an SQLite API change in version > 3.5. > This prevents segfaults when executing empty queries, like our test > suite > does. > > This bug is also present on the trunk, yet I saw no indication that he > checked in such a fix there. Gerhard's patch applies cleanly. I sent him > an email after I saw the checkin and verified that the patch worked on the > trunk, but have yet to hear back from him. Yes, I remember. I postponed updating the trunk because I planned sync it with the lastest pysqlite release instead. I've updated my TODO list. > Is there some different method for getting sqlite changes into the trunk? ?! From my point of view it's a module like all the others, except it's also maintained externally as 'pysqlite'. -- Gerhard ___ 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] RELEASED Python 2.6a2 and 3.0a4
Hello Barry, Great job with the releases! Barry Warsaw wrote: > On behalf of the Python development team and the Python community, I'm > happy to announce the second alpha release of Python 2.6, and the > fourth alpha release of Python 3.0. [...] In case you don't know already, the website is not fully updated, yet: http://www.python.org/download/releases/2.6/ Top of the page says "2.6a1" instead of "2.6a2". This file is apparently not yet updated for 2.6alpha2. http://www.python.org/download/releases/2.6/NEWS.txt For the 3.0 version: Top of the page still says "3.0a3". Cheers, -- Gerhard ___ 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] Python 3.0: can we make dbm's .keys() return an iterator?
As far as I can see, the specification of the dbm interface is the module docstring in dbm/__init__.py, which reads: """ [...] It has the following interface (key and data are strings): d[key] = data # store data at key (may override data at # existing key) data = d[key] # retrieve data at key (raise KeyError if no # such key) del d[key] # delete data stored at key (raises KeyError # if no such key) flag = key in d # true if the key exists list = d.keys() # return a list of all existing keys (slow!) """ Now I thought that in Python 3.0, keys(), values() and friends should return iterators. Can we change at least the specification of the dbm module? We could then later in 3.1 change the implementations to return iterators instead of lists, too. I stumbled upon it cos I'm trying to help Skip with the SQLite-based implementation. -- Gerhard ___ 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] Determine minimum required version for a script
techtonik wrote: Can somebody remind how to check script compatibility with old Python versions? I can remember PHP_CompatInfo class for PHP that parses a script or directory to find out the minimum version and extensions required for them to run, and I wonder if there was anything like this for Python? You posted on the *python-dev* mailing list. On this list the key *Python developers* discuss the future of the language and its implementation. Topics include Python design issues, release mechanics, and maintenance of existing releases. Please, do not post general Python questions to this list! For help with Python please use the mailing list [EMAIL PROTECTED] or the newsgroup comp.lang.python. Messages are routed between the two. so they're basically the same thing. -- Gerhard ___ 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] Using Cython for standard library?
Calvin Spealman wrote:
On Mon, Nov 3, 2008 at 6:29 AM, Gerhard Häring <[EMAIL PROTECTED]> wrote:
Stefan Behnel wrote:
Michael Foord wrote:
Moving more C extensions to an implementation based on ctypes would be
enormously useful for PyPy, IronPython and Jython, but ctypes is not yet
as portable as Python itself which could be an issue (although one worth
resolving).
In the same line, moving more extensions to a high-level language like
Cython,
instead of writing them in straight C, would make a later switch to a
different environment a lot easier, as the extensions could be regenerated
with a modified Cython compiler (obviously minus some fixing of premature
optimisations and the like).
Is using Cython for anything in Modules/ really an option? In my limited
experiments with it, I did like it.
But using it for Python standard library stuff doesn't look quite right to
me:
- Option 1: distribute Cython with Python and integrate into build process
-- Ouch!
Can you be a bit more descriptive?
Cython is still being worked on (intensively, it seems). Bundling it
with Python means deciding on a particular version probably for an
entire major release lifecycle (use Cython x.y.{newest} for Python 2.7,
for example).
- Option 2: only distribute generated source files
-- developers still need to have Cython installed
-- you have to trust Cython; who will really review the generated code?
Who reviews the machine code from gcc?
That's comparing apples and eggs :-P But it may be that I'm a little
paranoid here.
I would love to see the option to write the lower levels in something
other than C,
Absolutely. That's why I tried to reimplement pysqlite in something
easier to maintain than handwritten Python C API. There's a ctypes-based
version in its Mercurial repository that's good enough to be used from
PyPy now. And a started Cython-based one.
but obviously any choice would have to be a good one.
[...] So, the question I see isn't if Cython should be
allowed for standard library modules, but if the landscape of such
solutions is at a point that any of them is ready to be committed to.
ACK.
-- Gerhard
___
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] Using Cython for standard library?
Stefan Behnel wrote: Michael Foord wrote: Moving more C extensions to an implementation based on ctypes would be enormously useful for PyPy, IronPython and Jython, but ctypes is not yet as portable as Python itself which could be an issue (although one worth resolving). In the same line, moving more extensions to a high-level language like Cython, instead of writing them in straight C, would make a later switch to a different environment a lot easier, as the extensions could be regenerated with a modified Cython compiler (obviously minus some fixing of premature optimisations and the like). Is using Cython for anything in Modules/ really an option? In my limited experiments with it, I did like it. But using it for Python standard library stuff doesn't look quite right to me: - Option 1: distribute Cython with Python and integrate into build process -- Ouch! - Option 2: only distribute generated source files -- developers still need to have Cython installed -- you have to trust Cython; who will really review the generated code? -- Gerhard ___ 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] http://www.python.org/dev/doc/devel still available
Jeremy Hylton wrote: > I don't think this message is on-topic for python-dev. There are lots > of great places to discuss the design of the python web site, but the > list for developers doesn't seem like a good place for it. Do we need > a different list for people to gripe^H^H^H^H^H discuss the web site? [...] Such as http://mail.python.org/mailman/listinfo/pydotorg-redesign ? -- Gerhard ___ 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] pysqlite for 2.5?
Georg Brandl wrote: > Anthony Baxter wrote: > >>This came up before (back in October 2004!) but didn't go anywhere >>since, AFAICR. Do we want to consider including pysqlite in Python >>2.5? It's the only DB adaptor that I'd really consider suitable for >>shipping with the distribution, because it's self-contained. >> >>What's people's thoughts? > > OTOH, +1 for a simple DB wrapper that makes it easy to start with DB-enabled > applications. The trouble with it can't be worse than the BSDDB issues ;) > > OTOH, pysqlite2 seems to have had a fairly rapid sequence of releases in the > past. That's because I decided for a more rapid release cycle than I used in the past. If bugs are fixed and no features planned to implement in the near future, I made a release. > I don't know whether it is now bug-free (the website claims that the > 2.1 branch should be stable, and the 2.0 branch has proven stable). There have been no more bug reports since 2.1, so I'm confident that all the glitches the switch to transparent compiled statements in 2.1 introduced are fixed now. > There also have been some API changes in the 2.0.x line, like the introduction > of executemany() which broke e.g. SQLObject. I missed that, can you provide a link please? pysqlite 2 was announced to be incompatible with pysqlite 1. I don't think there were any backwards incompatible API changes in the 2.x line. > Anyway, almost all popular web frameworks rely on PySQLite and seem to work > well with it. > > Of course, speaking with Gerhard will be the way to find out more. I'll try to throw in a bit more information that will be necessary for this discussion: pysqlite 2.x is (almost) feature complete now. I've a few more changes sitting in SVN trunk that are waiting for the pysqlite 2.2 release. These are all about wrapping more of the SQLite API, like custom collations. I *am* willing to be a maintainer of an SQLite module for Python. I will gladly help writing a PEP for it. But I won't be the champion for the idea, because I'm only +0 on adding external libraries to Python, like elementtree, or ctypes, or pysqlite instead of relying on setuptools/Cheese Shop. I could probably be convinced that a fat Python is still a good idea nowadays, though :-) -- Gerhard ___ 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] pysqlite for 2.5?
Georg Brandl wrote: > Gerhard Häring wrote: >>I'll try to throw in a bit more information that will be necessary for >>this discussion: >> >>pysqlite 2.x is (almost) feature complete now. I've a few more changes >>sitting in SVN trunk that are waiting for the pysqlite 2.2 release. >>These are all about wrapping more of the SQLite API, like custom collations. > > In what timeframe will those be completed? I would have waited for a pysqlite 2.2 release until I found a good API for logging for pysqlite (mainly for reporting exceptions in Python callbacks). I will probably defer the logging stuff to pysqlite 2.3 and release pysqlite 2.2 soon with the features currently in SVN. I know that pushing new things into Python 2.5 should happen soon, if at all. So *if* pysqlite should go into Python, I propose that I release pysqlite 2.2.0 and we integrate that into the Python alpha release. If this is going to happen, I want it to happen under a different package name than "pysqlite2" and it's probably a good idea to skip "sqlite" too, because there are still users of the SQLite 1.x API (*) and this is the package name of that API. OTOH, "sqlite" would be the natural name if it ends up in Python. Perhaps "sqlitedb" ... Extensive unit tests are available, as is a reference manual in ReST format. -- Gerhard (*) Although if they're really using pysqlite 0.x/1.x then it's unlikely they'll switch to Python 2.5 with their applications. ___ 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] pysqlite for 2.5?
Martin v. Löwis wrote: > Anthony Baxter wrote: > >>This came up before (back in October 2004!) but didn't go anywhere >>since, AFAICR. Do we want to consider including pysqlite in Python >>2.5? It's the only DB adaptor that I'd really consider suitable for >>shipping with the distribution, because it's self-contained. >> >>What's people's thoughts? > > We shouldn't include anything without the explicit permission of the > author(s); I'm the only author of the pysqlite 2 codebase, so no problem here. > if possible, the authors should grant the PSF permission > to change the license (i.e. fill out the contributor agreement). That would be no problem either. > Even better, the authors should be willing to keep the version in > Python synchronized with the separate release. In particular, I would then synchronize changes that have proven stable in the standalone release to the Python core sqlite module. I think this is how Barry does it with the email module, too. -- Gerhard ___ 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] pysqlite for 2.5?
Neal Norwitz wrote: > On 3/28/06, Gerhard Häring <[EMAIL PROTECTED]> wrote: > >>>Even better, the authors should be willing to keep the version in >>>Python synchronized with the separate release. >> >>In particular, I would then synchronize changes that have proven stable >>in the standalone release to the Python core sqlite module. I think this >>is how Barry does it with the email module, too. > > Everything Gerhard has said sounds good. From what I read it seems > that it might be good to add pysqlite to the stdlib eventually. > Overall, I'm +0 on the idea. It seems everyone is pretty positive on > the concept. > > However, I'm -0 on adding this to 2.5. We've already got a lot of > changes. I don't want us to keep piling more on. Also I thought I > saw Gerhard say that there were some other things he wanted to finish > and the timing might work better for him to defer a bit. My current and future plans for pysqlite are really only additional features, like wrapping the rest of the SQLite API. > Some of these things sounded like API changes which may be more problematic > once in the core as we may have stricter rules on backwards > compatibility. All my plans for pysqlite are adding more methods to the API, so I see no backwards compatibility problems. > We also have to convert the doc from ReST to latex. None of these are > show stoppers, but it adds to the amount of work we need to do before > release. And there's already more work than we can handle. I understand your concern for keeping the amount of work for a 2.5 release manageable. So as Anthony Baxter said he'd like to work with me to make this happen, then I think he and I can try to not overload other people with more work. Creating latex docs sounds like I could do it, too. What I'd personally like to offload are these two tasks: - integreting pysqlite into the Python build process - in particular the win32 build process I would have access to Linux and win32 development machines with MS VS2003, but I don't have enough experience with the Python build process to not make stupid mistakes here. -- Gerhard ___ 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] pysqlite for 2.5?
Barry Warsaw wrote: > On Wed, 2006-03-29 at 19:47 +1100, Anthony Baxter wrote: > >>My only concern about this is that it wouldn't be possible for other >>authors to provide 3rd party packages as (for instance) db.mysqldb >>because of the way package importing works. And I'd prefer >>'database.sqlite' rather than 'db.sqlite'. > > +1 on 'database' as the top-level package name. I think short names are more more consistent with the existing naming in the standard library. +1 on db.sqlite from me. db.sql.sqlite is another possibility, if adding something like Durus or ZODB in the same top-level namespace could be considered for 2.6. -- Gerhard ___ 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] pysqlite for 2.5?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip J. Eby wrote: > At 11:36 AM 3/29/2006 -0800, Guido van Rossum wrote: >> [...] Perhaps one person in favor and one >> person against could summarize the argument for me? > > Pro: > > * SQLite is really nice to have for writing simple applications with small > data needs, especially client-side software. It's probably the > best-of-breed open source embedded SQL DB right now. > * So, having a wrapper would be a big "Batteries included" plus for Python That would be my arguments, too. > Con: > > * Competing Python wrappers exist There is really only one other relevant wrapper: APSW. It was purposefully designed to *not* use the DB-API 2.0 (though a similar one), and being a "thinner" wrapper of SQLite. It wraps a few more functions of the SQLite API, though less and less, because pysqlite is catching up here. While there might be arguments for a "thinner" wrapper, I think that pysqlite has the advantage of being DB-API compliant (even with most optional DB-API extensions) and thus offers a good way to prototype database apps with a smooth upgrade path to other, more powerful, databases. > * SQLite itself is updated frequently, let alone the wrappers SQLite being updated regularly is not really a problem, because we can link dynamically against SQLite. And we probably *should* do this on Windows, too, so users can replace a SQLite.DLL with an updated version if they wish to. > * Build integration risks unknown, possible delay of 2.5? > * Another external library to track and maybe have emergency updates of Emergency updates are only for security problems, right? I don't think this would apply to pysqlite. I don't think that would apply to SQLite either, but if it's conceivable, it's another argument for dynamic linking. - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEKvlzdIO4ozGCH14RAuLKAJ9BGnHz4Tym60xOGSwSuqXlqRaAdwCdFeqx +vo5eC0aBu4S2sttb/iZPOc= =bJKK -END PGP SIGNATURE- ___ 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] Discussing the Great Library Reorganization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brett Cannon wrote: > While this is going to require a PEP (which I am willing to write), > the discussion of adding pysqlite has brought forth some discussion on > naming and packaging in the stdlub. Perhaps it's time to start > discussing the Great Library Reorganization that has been discussed > for eons. [...] Wouldn't the newly founded python-3000 mailing list be the perfect place for such major changes? - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEKwBWdIO4ozGCH14RAnIkAJ9L/m8J4aiIisJKVimIv15mvSQApgCgnvP4 H/aV/ZuLs0DLScvnyrfsGPo= =Dm7c -END PGP SIGNATURE- ___ 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] pysqlite for 2.5?
M.-A. Lemburg wrote: > [...] > Also your statement regarding sqlite3 suggests that sqlite > itself is not included - why not ? - SQLite sources are 1.57 MiB uncompressed, we wouldn't want to add that to the Python sources download size, would we? - I personally would not want to have the job to "bless" a certain version of SQLite for being bugfree enough to be used until the next Python minor release. And we wouldn't want to push a Python minor release just somebody found an obscure data corroption bug in a SQLite release - SQLite might not compile on some less common platforms (AIX, HP/UX, Win64, whatever) that Python compiles fine on. - I believe Python is written in more portable C than SQLite. So it might be certain compilers that fail for compiling SQLite. - At some point you might also want a sqlite commandline shell instead of just the shared library, too. All of these are non-issues if we just compile against an installed SQLite on Unix-like system if it can be found. On Windows, I also prefer to have a dynamically linked SQLite Python module. We can distribute the SQLITE3.DLL with Python, and then people could just download an updated SQLITE.DLL from http://sqlite.org/ and overwrite the existing one of the Python installation, *if* an important bug is fixed in SQLite. > Isn't the main argument for having pysqlite included in the > core to be able to play around with SQL without relying > on external libraries ? This, and that you can prototype without having to install and configure a database server. For many applications, the prototype can be the final version. -- Gerhard ___ 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] pysqlite for 2.5?
Fredrik Lundh wrote: > Anthony Baxter wrote: > > >>>Such a module name is less likely to cause problems. >> >>Excellent point. Hm. Maybe we should just go with 'sqlite', instead. > > > except that "sqlite" was the name used by the first pysqlite > generation: > > $ python2.3 > import sqlite sqlite.version > > '1.1.6' > > I'm not sure how much trouble reusing this name would cause, but I'm > quite sure the amount of trouble is larger than "none at all". "sqlitedb" is not taken yet. -- Gerhard ___ 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] pysqlite for 2.5?
M.-A. Lemburg wrote: > Will it also work with e.g. sqlite 2.8.15 (ie. sqlite < v3) - > this is the standard version on SuSE 9.2. No, SQLite 3 has a completely different API than SQLite 2.x. If you need a Python module for it, you can use pysqlite 1.0.1. >>>Also your statement regarding sqlite3 suggests that sqlite >>>itself is not included - why not ? >> >>For the same reasons we don't include the BerkeleyDB library. Many, >>many modern operating systems now ship with libsqlite3 (just as they >>ship with bsddb). While sqlite is nowhere near the size of >>BerkeleyDB, it's still a non-trivial amount of code. > > > If it works with sqlite2 then I agree: these versions are > usually available on Unixes. sqlite3 is not as wide-spread > yet. > > What about the Windows build ? Will that contain the necessary > DLLs ? I proposed to link dynamically on Windows, and ship the Windows SQLite3.DLL. This has two advantages: - Python users can upgrade the SQLite3.DLL by a simple download from in case of emergency - we could make it so that win32 Python core developers (or the Python win32 build process) don't have to build SQLite when building Python -- Gerhard ___ 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] pysqlite for 2.5?
Martin v. Löwis wrote: > Terry Reedy wrote: > >>"Gerhard Häring" <[EMAIL PROTECTED]> wrote in message >>news:[EMAIL PROTECTED] >> >>>I proposed to link dynamically on Windows, and ship the Windows >>>SQLite3.DLL. This has two advantages: >>> >>>- Python users can upgrade the SQLite3.DLL by a simple download from in >>>case of emergency >> >>+1 and thanks from a Windows user > > This binary depends on msvcrt.dll. Does anybody know whether this could > cause a problem? IOW, is any of the forbidden API used across the DLL > boundary (in particular: memory management, stdio, locales)? AFAIK SQLite does not use stdio or locales. Memory management is normally never done explicitly, but by API calls using opaque pointers to the SQLite structure, for example: - sqlite3_compile will return a SQLite statement. - sqlite3_finalize will clean up the SQLite statement, and return any memory used by it. The only explicit memory management function I know is void sqlite3_free(char *z); which looks ok, too. And pysqlite doesn't use it, anyway. -- Gerhard ___ 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] PSF Contributor Agreement for pysqlite
Posting here because I don't know a better place: Federico di Gregorio and me have both faxed PSF contributor agreements to the PSF for integration of pysqlite into Python 2.5. -- Gerhard ___ 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] Raising objections
Neal Norwitz wrote: > What are the doc plans for these modules: > + * ctypes > + * ElementTree/cElementTree > + * msilib > + * pysqlite pysqlite: I've started on new module docs for the "sqlite3" module in the Python standard library, based on the text from the existing pysqlite reference manual. Progress is about 5 % perhaps, I spent the most time figuring out how the Python doc build process works. We should probably check my docs in soon even in a preliminary state, so they can be reviewed/improved. Speaking of which, what about SVN commit privileges for me? It's not a big problem to tunnel my stuff through Anthony or others, but I think this would save resources. -- Gerhard ___ 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 of externally maintained packages PEP
Brett Cannon wrote: > here is the rough draft of the PEP for packages maintained externally > from Python itself. There is some missing, though, that I would like > help filling in. > > I don't know who to list as the contact person (i.e., the Python > developer in charge of the code) for Expat, Optik or pysqlite. [...] > I also thought Gerhard Haering was in charge of pysqlite, but he has > never responded to any emails about this topic. Sorry for not answering any sooner. Please list me as contact person for the SQLite module. > Maybe the responsibility should go to Anthony since I know he worked > to get the package in and probably cares about keeping it updated? > As for Expat (the parser), is that Fred? [...] > > > pysqlite > > - Web site > http://www.sqlite.org/ > - Standard library name > sqlite3 > - Contact person > XXX > - Synchronisation history > * 2.1.3 (2.5) You can add * 2.2.0 * 2.2.2 here. -- Gerhard ___ 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] need info for externally maintained modules PEP
Brett Cannon wrote: > OK, I am going to write the PEP I proposed a week or so ago, listing > all modules and packages within the stdlib that are maintained > externally so we have a central place to go for contact info or where > to report bugs on issues. This should only apply to modules that want > bugs reported outside of the Python tracker and have a separate dev > track. People who just use the Python repository as their mainline > version can just be left out. [...] I prefer to have bugs on the sqlite module reported in the pysqlite tracker at http://pysqlite.org/ aka http://initd.org/tracker/pysqlite For bug fixes I have the same position as Fredrik: security fixes, bugs that block the build and warnings from automatic checkers should be done through the Python repository and I will port them to the external version. For any changes that reach "deeper" I'd like to have them handed over to me. As it's unrealistic that all bugs are reported through the pysqlite tracker, can it please be arranged that if somebody enters a SQLite related bug through the Sourceforge tracker, that I get notified? Perhaps by defining a category SQLite here and adding me as default responsible, if that's possible on SF. Currently I'm not subscribed to python-checkins and didn't see a need to. Is there a need to for Python core developers? I think there's no better way except subscribing and defining a filter for SQLite-related commits to be notified if other people commit changes to the SQLite module in Python? It's not that I'm too lazy, but I'd like to keep the number of things I need to monitor low. -- Gerhard ___ 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] rest2latex - was: Re: Raising objections
Thomas Heller wrote: > [...] I'm now happy with the tool that converts the ctypes tutorial from reST > to LaTeX, > I will later (today or tomorrow) commit that into Python SVN. Did you commit that already? Alternatively, can you send it to me, please? -- Gerhard ___ 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] Status: sqlite3 module docs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I've now moved over all the content from the pysqlite reference manual to the sqlite3 module docs. It would be nice if now somebody with more experience with Python documentation could look over it. A few things I know could be changed: - - Just like with the pysqlite docs, the reference manual tries to have many examples. I've put these under Doc/lib/sqlite/*.py. All other modules have the .py files directly in Doc/lib/ - I don't know if this is necessary for some reason unknown to me. For building HTML docs, having them in a subdirectory works fine. - - Some (or some more) of the examples could probably be moved into a directory in Demo/ instead. - - There's no tutorial for the sqlite3 module right now, all is in reference-manual style. I'll continue to work on this if somebody tells me what to do, but for now it would be nice if somebody could clean it up (and maybe also tell me why certain clean-ups are done - I don't know how indentation is handled for text and examples, e. g.). - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEZS4xdIO4ozGCH14RAo8zAJ9aoqZ2Bjsu0JYh6WyGUXYItKf8oQCeIwL4 jbhixu+TOIYT0PF0/hJGY+g= =/cGc -END PGP SIGNATURE- ___ 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] beta1 coming real soon
Neal Norwitz wrote: > It's June 9 in most parts of the world. The schedule calls for beta 1 > on June 14. That means there's less than 4 days until the expected > code freeze. Please don't rush to get everything in at the last > minute. The buildbots should remain green to keep Anthony happy and > me sane (or is it the other way around). [...] I would have liked to implement the last major missing piece from pysqlite - the authorizer hook - release pysqlite 2.3.0 and merge the changes into the Python core sqlite3 module. This would be an additional feature and not require any changes to the existing code. If you'd rather not have this merged because of new code, then I'll skip it. There are other changes I did in pysqlite for pysqlite 2.3.0 that I'd more strongly like to integrate here: http://initd.org/tracker/pysqlite/changeset/274 This changeset fixes a real bug that can lead to hard crashes and also makes the sqlite module more sane: - converter names are looked up in a case-insensitive manner (the old behaviour is confusing to users) - Errors in callbacks are not silently ignored any longer, but lead to the query being aborted - Additionaly, the error can be echoed to stderr if a debugging flag is set (default is off) -- Gerhard ___ 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] sqlite3 test errors - was : Re: [Python-checkins] r46936 - in python/trunk: Lib/sqlite3/test/regression.py Lib/sqlite3/test/types.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/conn
Co-posting to python-dev in the hope of getting help of people verifying my suspicion ... Gerhard Häring wrote: > [...] > For some reason, they don't seem to have picked up the changed tests of > the sqlite3 module. At least the error messages look exactly like the > ones I had when I ran the current code against old tests. That guess was wrong. The failed sqlite3 tests come from an old SQLite version being linked against. Until recently, SQLite was buggy and it was only fixed in http://www.sqlite.org/cvstrac/chngview?cn=2981 that callbacks can throw errors that are usefully returned to the original caller. The tests for the sqlite3 module currently assume a recent version SQLite (3.3.something). Otherwise some tests will fail. Still, it can be built against any SQLite 3 release. Can somebody please also verify if the malloc/free error message goes away (it really only happened on Mac, didn't it?) if you upgrade SQLite to the latest version on the build host? -- Gerhard ___ 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] [Python-checkins] sqlite3 test errors - was : Re: r46936 - in python/trunk: Lib/sqlite3/test/regression.py Lib/sqlite3/test/types.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/
Gerhard Häring wrote:
Co-posting to python-dev in the hope of getting help of people verifying
my suspicion ...
Gerhard Häring wrote:
[...]
For some reason, they don't seem to have picked up the changed tests of
the sqlite3 module. At least the error messages look exactly like the
ones I had when I ran the current code against old tests.
That guess was wrong. The failed sqlite3 tests come from an old SQLite
version being linked against. Until recently, SQLite was buggy and it
was only fixed in
http://www.sqlite.org/cvstrac/chngview?cn=2981
that callbacks can throw errors that are usefully returned to the
original caller.
The tests for the sqlite3 module currently assume a recent version
SQLite (3.3.something). Otherwise some tests will fail.
Still, it can be built against any SQLite 3 release.
Can somebody please also verify if the malloc/free error message goes
away (it really only happened on Mac, didn't it?) if you upgrade SQLite
to the latest version on the build host?
With SQLite 3.2.8, I also get segfaults on Linux x86 (Ubuntu dapper, gcc).
I've provided a preliminary patch (cannot check in from this place) that
I've attached. Maybe somebody wants to test it, otherwise I'll make a
few other tests in the late evening and probably also selectively
disable certain tests in the test suite if the SQLite version is too old
to pass them.
-- Gerhard
Index: Modules/_sqlite/connection.c
===
--- Modules/_sqlite/connection.c(revision 46958)
+++ Modules/_sqlite/connection.c(working copy)
@@ -34,6 +34,16 @@
static int connection_set_isolation_level(Connection* self, PyObject*
isolation_level);
+
+void _sqlite3_result_error(sqlite3_context* ctx, const char* errmsg, int len)
+{
+#if SQLITE_VERSION_NUMBER >= 3003003
+sqlite3_result_error(ctx, errmsg, len);
+#else
+/* sqlite3_result_null(ctx); */
+#endif
+}
+
int connection_init(Connection* self, PyObject* args, PyObject* kwargs)
{
static char *kwlist[] = {"database", "timeout", "detect_types",
"isolation_level", "check_same_thread", "factory", "cached_statements", NULL,
NULL};
@@ -526,7 +536,7 @@
} else {
PyErr_Clear();
}
-sqlite3_result_error(context, "user-defined function raised
exception", -1);
+_sqlite3_result_error(context, "user-defined function raised
exception", -1);
}
PyGILState_Release(threadstate);
@@ -558,7 +568,7 @@
} else {
PyErr_Clear();
}
-sqlite3_result_error(context, "user-defined aggregate's '__init__'
method raised error", -1);
+_sqlite3_result_error(context, "user-defined aggregate's
'__init__' method raised error", -1);
goto error;
}
}
@@ -582,7 +592,7 @@
} else {
PyErr_Clear();
}
-sqlite3_result_error(context, "user-defined aggregate's 'step' method
raised error", -1);
+_sqlite3_result_error(context, "user-defined aggregate's 'step' method
raised error", -1);
}
error:
@@ -619,7 +629,7 @@
} else {
PyErr_Clear();
}
-sqlite3_result_error(context, "user-defined aggregate's 'finalize'
method raised error", -1);
+_sqlite3_result_error(context, "user-defined aggregate's 'finalize'
method raised error", -1);
} else {
_set_result(context, function_result);
}
___
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] [Python-checkins] sqlite3 test errors - was : Re: r46936 - in python/trunk: Lib/sqlite3/test/regression.py Lib/sqlite3/test/types.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Peters wrote: > [Gerhard Häring] >>> ... >>> Until recently, SQLite was buggy and it was only fixed in >>> >>> http://www.sqlite.org/cvstrac/chngview?cn=2981 >>> >>> that callbacks can throw errors that are usefully returned to the >>> original caller. >>> >>> The tests for the sqlite3 module currently assume a recent version >>> SQLite (3.3.something). Otherwise some tests will fail. > > Sounds like that explains why none of the Windows buildbots failed (on > Windows, Python currently uses the sqlite checked in at > > http://svn.python.org/projects/external/sqlite-source-3.3.4 > > ). I suppose some OSes think they're doing you a favor by forcing you > to be the system SQLite admin ;-) Yes, this issue made development of the SQLite module a bit more "interesting" for me. And I deserved no better for committing changes so late before beta1. Anyway, I verified my theory about the SQLite bugs (that's what they are), and added version checks to the C code and to the test suite, so now Everything Should Work (*crossing fingers*). If anything should still fail, I'll ruthlessly blame Anthony, he brought the idea up of supporting older SQLite versions in the first place :-P - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEkI+hdIO4ozGCH14RAlW/AJ4uQVZrvWC7265+9wshxaBotyLolgCgstKd 5xU5DZm1EC/G9qNctPlMcGc= =gaaO -END PGP SIGNATURE- ___ 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] [Python-checkins] sqlite3 test errors - was : Re: r46936 - in python/trunk: Lib/sqlite3/test/regression.py Lib/sqlite3/test/types.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anthony Baxter wrote: > Well, the just-released Ubuntu 06.06 LTS (Long Term Support) ships > with sqlite 3.2.8. I'd suggest that whatever version ships with > Python should _at_ _least_ work with this version. I have no problems continuing to support any halfway sane version, and that is 3.0.8 or later (AFAIR the first non-beta SQLite 3.x release anyway). It just requires a bit more testing. > [...] > Alternately, we ship the sqlite3 code with Python. I'm deeply > unthrilled with this idea, as it means more emergency security > releases to fix sqlite3 security bugs, as well as bloating out the > size of the release. No, that's not an option. > In the meantime, I'd suggest the appropriate fix is to roll back to > the previous version of the python-sqlite bindings on the trunk. Why? The previous version is really no better, except it ignores errors in callbacks for all SQLite versions, instead of doing something useful and aborting the query with a useful error message for those SQLite versions that support it. - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFEkPfYdIO4ozGCH14RAvQ+AJdxy8Iy0sfkSQVxShmGbq/HGKRzAKCPKMtG ZoEqmcNrgMX6k/7xzy0HKA== =OeDy -END PGP SIGNATURE- ___ 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] Dropping externally maintained packages (Was: Please stop changing wsgiref on the trunk)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Heller wrote: > Martin v. Löwis wrote: >> Guido van Rossum wrote: 4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want to get rid of it, *now* would be the time. >>> I'm all for it. >>> >>> While I am an enthusiastic supporter of several of those additions, I >>> am *not* in favor of the special status granted to software >>> contributed by certain developers, since it is a burden for all other >>> developers. >> Then I guess we should deal with before 2.5b1, and delay 2.5b1 until the >> status of each of these has been clarified. >> >> Each maintainer should indicate whether he is happy with a "this is >> part of Python" approach. If so, the entry should be removed from PEP >> 360 (*); if not, the code should be removed from Python before beta 1. > > I will be happy to say "ctypes is part of Python" (although I *fear* it > is not one of the packages enthusiastically supported by Guido ;-). The same goes for the sqlite3 module. I see it as part of Python and also see it as my job synchronize bugfixes with the external version both ways. I'll also add statements to the source files to ask developers to keep Python 2.3 compatibility. > [...] > I am *very* thankful for the fixes, the code review, the suggestions, > and the encouragement I got by various python-devers. [...] Ditto :-) So, somebody can please adjust the PEPs for the sqlite3 module accordingly. - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElxytdIO4ozGCH14RAs8PAJ9/+zGGFj3nLyKPNN+B+UmG3gaJeQCfV7Uc g0PjyvOfXVkA2cohQjJrzeI= =nM4W -END PGP SIGNATURE- ___ 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] Small sqlite3 test suite fix (Python 2.5b1 candidate)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.python.org/sf/1509584 Please apply if you think it should go in Python 2.5b1, otherwise I'll commit it after the freeze. I'd personally postpone it, because it's only cosmetic (but maybe it's related to the strange sqlite3 regression test failure Neil reported). Also, somebody please add me as Python developer on Sourceforge (I cannot assign items to myself there). - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEmGcjdIO4ozGCH14RAjfuAJ451ElbxqDqi6O+cGV3nVXgp0qLNwCgp6pI usZh93QtNgRz5Es3WmaX2W8= =5owZ -END PGP SIGNATURE- ___ 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] Small sqlite3 test suite fix (Python 2.5b1 candidate)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Peters wrote: > [Gerhard Häring] >> ... >> Also, somebody please add me as Python developer on Sourceforge (I cannot >> assign items to myself there). > > If you still can't, scream at me ;-) Bwah!!! :-P I still cannot see myself in the "Assigned to" dropdown ... - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEmHFZdIO4ozGCH14RArtWAJwPpJ/BmnCR34UgnsJxbEieU/MdeQCdFTu2 nht30gADuguOlWvhnn5Tj7E= =QZlI -END PGP SIGNATURE- ___ 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] doc for new restricted execution design for Python
Brett Cannon wrote: > I have been working on a design doc for restricted execution of Python > [...] All the rest of the API made sense to me, but I couldn't understand why PyXXX_MemoryFree is needed. How could memory usage possibly fall below 0? -- Gerhard ___ 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] doc for new restricted execution design for Python
Brett Cannon wrote: > On 6/22/06, *Gerhard Häring* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > > Brett Cannon wrote: > > I have been working on a design doc for restricted execution of > Python > > [...] > > All the rest of the API made sense to me, but I couldn't understand why > > PyXXX_MemoryFree > > is needed. How could memory usage possibly fall below 0? > > It can't in real life, but people could call MemoryFree() too many > times. Plus you need some way to lower the amount when memory is > freed. No need to penalize a script that does a bunch of malloc/free > calls compared to one that just does a bunch of malloc calls. But if you want to limit the amount of memory a Python interpreter can use, wouldn't you have to integrate that resource checking into the standard Alloc/Dealloc functions instead of only enforcing the resource limit when some new API functions are called? Existing extension modules and existing C code in the Python interpreter have no idea of any PyXXX_ calls, so I don't understand how new API functions help here. -- Gerhard ___ 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] a quit that actually quits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ka-Ping Yee wrote: > [...] > (b) If more handholding seems like a good idea, then: > > class ExitHatch: > def __call__(self): sys.exit() > def __repr__(self): return '' > __builtins__.exit = __builtins__.quit = ExitHatch() That looks like a good compromise to me. - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDsdPWdIO4ozGCH14RAsTyAKCW5mwCJ/cN+UbKICufXwmDIX9/tgCfQLJa LaEL4a4pV7Jhnh3ry/b+CrU= =/FQl -END PGP SIGNATURE- ___ 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
