Re: [Python-Dev] [Python-3000] Questions on optional type annotations
On 5/11/06, Edward Loper <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > Another benefit of this is the ability to get more info through
> > introspection. Right now, you can't even find the number of arguments
> > of a function implemented in C. You only know if it takes 0, 1, or
> > variable # of arguments and if it accepts keywords.
>
> By this, do you mean that it's currently possible to distinguish these
> cases (builtins that take 0 args, builtins that take 1 arg, builtins
> that take varargs, builtins that take keywords) via introspection in
> python? If so, could you let me know how this is done? For epydoc,
> this would at least let me give a little more info when no signature is
> present on the first line of the docstring.
Hmm, well I only said the info was available. I didn't say it was
available from Python code. :-)
Actually, with the patch below the flags are available:
>>> len.__flags__
8
The flags are METH_XXX flags defined in Include/methodobject.h:
#define METH_OLDARGS 0x
#define METH_VARARGS 0x0001
#define METH_KEYWORDS 0x0002
#define METH_NOARGS 0x0004
#define METH_O0x0008
If you want this patch included in 2.5, feel free to ask on
python-dev. I guess I'm +0 on it. This could be a trivial extension
module for older versions of python. Aaaa, screw it, I copied
python-dev, we'll see if anyone cares.
n
--
Index: Objects/methodobject.c
===
--- Objects/methodobject.c (revision 45961)
+++ Objects/methodobject.c (working copy)
@@ -146,6 +146,12 @@
return PyString_FromString(m->m_ml->ml_name);
}
+static PyObject *
+meth_get__flags__(PyCFunctionObject *m, void *closure)
+{
+ return PyInt_FromLong(m->m_ml->ml_flags);
+}
+
static int
meth_traverse(PyCFunctionObject *m, visitproc visit, void *arg)
{
@@ -174,6 +180,7 @@
{"__doc__", (getter)meth_get__doc__, NULL, NULL},
{"__name__", (getter)meth_get__name__, NULL, NULL},
{"__self__", (getter)meth_get__self__, NULL, NULL},
+ {"__flags__", (getter)meth_get__flags__, NULL, NULL},
{0}
};
___
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] Efficient set complement and operation on large/infinite sets.
> "Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes: Raymond> There's room in the world for alternate implementations of sets, Raymond> each with its own strengths and weaknesses. ... Raymond> Alternatve implementations will most likely start-off as Raymond> third-party extension modules Raymond> As for the built-in set types, I recommend leaving those alone and Raymond> keeping a API as simple as possible. Agreed. I implemented most of what I need last night - not surprisingly in less time than it took to write the original mail. Raymond> The __rand__ idea is interesting but I don't see how to implement Raymond> an equiprobable hash table selection in O(1) time -- keep in mind Raymond> that a set may be very sparse at the time of the selection. I think the rand issue is enough to make the proposal questionable. Another thing I realized which I think adds to the argument that this should be separate, is that it's not so straightforward to deal with operations on sets that have different universes. You can do it, but it's messy, not elegant, and not fun (and no-one is asking for it, not even me). This leads to a much nicer approach in which you have a separate module that provides a UniversalSet class. When you call the constructor, you tell it whatever you can about what the universe looks like: how big it is, how to generate random elements, how to exclude things, etc. This class provides a simple (a la Python set.__init__) method that hands back a set within this universe. You're then free to operate on that set, and other instances provided by UniversalSet, as usual, and you get to do complement. It's easy to imagine subclasses such as InfiniteSet, FiniteSet, etc. Python's sets are the case where nothing is known about the universe (aside from implementation details, like elements being hashable). The various different kinds of UniversalSet subclasses would provide methods according to what was known about their universes. That would clearly be a 3rd party extension. Terry ___ 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] pthreads, fork, import, and execvp
Rotem Yaari wrote: > This has occurred on Python 2.4.1 on a 2.4.27 Linux kernel. > > Preliminary analysis of the hang shows that the child process blocks > upon entering the execvp function, in which the import_lock is acquired > due to the following line: > > def _ execvpe(file, args, env=None): > from errno import ENOENT, ENOTDIR > ... While I agree there's no good reason to embed this import inside the function, I also don't see how you could be getting a deadlock unless you have modules that either spawn new threads or fork the process as a side effect of being imported. Neither of those is guaranteed to work properly due to the fact that the original thread holds the import lock, leading to the possibility of deadlock if the spawned thread tries to import anything (as seems to be happening here) and the original thread then waits for a result from the spawned thread. Spawning new threads or processes can really only be safely done when invoked directly or indirectly from the __main__ module (as that is run without holding the import lock). When done as a side effect of module import, the module needs to ensure that the result of the spawned thread or process is only waited for after the original module import is complete (and the import lock released as a result). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] [Python-checkins] r45925 - in python/trunk: Lib/tempfile.py Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c
M.-A. Lemburg wrote: > Martin v. Löwis wrote: >> M.-A. Lemburg wrote: >>> BTW, and intended as offer for compromise, should we instead >>> add the Win32 codes to the errno module (or a new winerrno >>> module) ?! I can write a parser that takes winerror.h and >>> generates the module code. >> Instead won't help: the breakage will still occur. It would >> be possible to put symbolic constants into the except clauses, >> instead of using the numeric values, but you still have to >> add all these "except WindowsError,e" clauses, even if >> the constants were available. > > Right, I meant "instead of using ErrorCode approach". > >> However, in addition would be useful: people will want to >> check for specific Win32 error codes, just because they are >> more descriptive. I propose to call the module "winerror" >> (in parallel to winerror.h, just as the errno module >> parallels errno.h) > > Ok. > >> Adding them all to the errno would work for most cases, >> except that you get conflicts for errno.errcode. > > I think it's better to separate the two - you wouldn't > want to load all the winerror codes on Unix. I've written a parser which only includes the ERROR_* definitions from the winerror.h file. The generated file is quite large (160kB) and it's currently a Python module defining the symbols and an errorcode dictionary (just like the errno module does). Generating a C extension wouldn't really decrease the size of the mapping tables, since they would also end being dictionaries on the heap. An alternative would be to use a lookup object which then searches in a static C array of data (e.g. a large switch statement which the compiler then optimizes). This would have the advantage of not using up too much process memory and could be shared between Python processes. The downside is that the approach would not be compatible to the errno module interface, since all lookups would have to go through the lookup object, e.g. winerror.ERROR.ACCESS_DENIED instead of: winerror.ERROR_ACCESS_DENIED What do you think ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 12 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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
[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 [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] [Python-checkins] r45925 - in python/trunk: Lib/tempfile.py Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c
M.-A. Lemburg wrote: > What do you think ? I think the size could be further reduced by restricting the set of error codes. For example, if the COM error codes are left out, I only get a Python file with 60k source size (although the bytecode size is then 130k). I'm not sure whether GetLastError can ever return a COM error code, but in my experience, it never did. I wouldn't want to introduce a clumsy interface just to achieve space savings. If people consider the space consumption of 200k disk size unacceptable (or would never use the module because of the runtime size effects), the entire idea should be dropped (IMO). OTOH, I don't find such a size increase unacceptable myself. 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
