Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
Hi Martin, On Mon, Mar 12, 2007 at 11:50:17PM +0100, "Martin v. L?wis" wrote: > Does distutils support this kind of setup? Modules/Setup? distutils does, and I can find many projects which require a combination of C and Python modules being organized as a single package with the extension modules somewhere inside: psyco, pygame, pysqlite2, PIL, Numeric, OpenSSL... in fact, this is the case of the majority of the packages I see in my 'site-packages'. If someone wanted to distribute a Python executable with any of these packages built-in, he would run into exactly the same problem as Miguel did. A bientot, Armin ___ 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] Patch 1644818: Allow importing built-in submodules
Martin v. Löwis wrote: > I couldn't tell off-hand whether having > extension modules in a package would even work It's quite common for a third-party package to consist of some Python code and some extension modules, with the extension modules living inside the package namespace. It works fine. -- Greg ___ 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] [ 1673007 ] urllib2 requests history + HEAD
> From: Facundo Batista <[EMAIL PROTECTED]> > This patch was posted by "koder_ua". > I think that Request must have a "request type" parameters, so people > can send "HEAD" requests easily. > But it seems to me that keeping a request history in the module is bad, > because it can easily grow up to thousands and explode (a.k.a. consume > too much memory). > Fo example, I have a web service, running 7x24, and opening another web > service, with around 10 requests per second. This means, keeping the > history (around 50bytes each request), 1.2 GB of RAM in only a month! > So, I'll close this patch as "Rejected", for this reason, if anyone > raises objections. > Regards, > -- > . Facundo This is probably a misunderstanding. Request's history don't store in the "module".They store in two places: 1) In Request object (for current request, so they would be destroyеd with it); 2) In HTTPConnection object (while request redirects). In HTTPConnection history stores only for current served Request. Even if You use the same HTTPConnection for many Requests, they (HTTPConnection) clear history every time when new Request starts. # from httplib HTTPConnection.putrequest patched str = '%s %s %s' % (method, url, self._http_vsn_str) self._output(str) self.sended_hdrs = [str] <<< previous history die here ___Full history for all processed request didn't not stored in any place. --- KDanilov aka koder(aka koder_ua) ___ 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] Patch 1644818: Allow importing built-in submodules
On Monday 12 March 2007 4:50:17 pm Martin v. Löwis wrote: > Does distutils support this kind of setup? Yes, and it has since its introduction. Just use the dotted name for the extension name. > IOW, I would expect that there are sooo many places where extension > modules in packages are not supported that it is just a tiny detail > that they don't work in builtin modules (which, as I said, only have > top-level modules, anyway). 4Suite has many extension modules that are part of packages and never once has there been a problem reported due to extension modules. The thought that extension modules cannot be in a package has never even cross my mind. I would have thought it a bug if they didn't, FWIW. -- Jeremy Kloth http://4suite.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] Patch 1644818: Allow importing built-in submodules
At 11:50 PM 3/12/2007 +0100, Martin v. Löwis wrote: >Does distutils support this kind of setup? Modules/Setup? distutils does, and has from its inception, as far as I know. >IOW, I would expect that there are sooo many places where extension >modules in packages are not supported The only thing I know of that doesn't support it very well is py2exe, actually. PEAK has had extensions modules in subpackages for many years now, and never run into any problems. In fact, py2exe's only problem with it is that it still requires such modules to have globally unique names -- you can't have both a foo.speedups extension and a bar.speedups extension. (This actually happened with RuleDispatch and PyProtocols; I ended up renaming them to _p_speedups and _d_speedups to better support py2exe users.) ___ 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] Patch 1644818: Allow importing built-in submodules
Phillip J. Eby schrieb: > At 11:50 PM 3/12/2007 +0100, Martin v. Löwis wrote: >>Does distutils support this kind of setup? Modules/Setup? > > distutils does, and has from its inception, as far as I know. > > >>IOW, I would expect that there are sooo many places where extension >>modules in packages are not supported > > The only thing I know of that doesn't support it very well is py2exe, > actually. PEAK has had extensions modules in subpackages for many years > now, and never run into any problems. In fact, py2exe's only problem with > it is that it still requires such modules to have globally unique names -- > you can't have both a foo.speedups extension and a bar.speedups > extension. (This actually happened with RuleDispatch and PyProtocols; I > ended up renaming them to _p_speedups and _d_speedups to better support > py2exe users.) > It is kind of funny that I contributed a patch to the McMillan installer to support extension modules in packages years ago, but never bothered to implement that in py2exe. If anyone contributes a patch for py2exe, I can integrate it... Thomas ___ 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] assert(obj) in Py_DECREF and Py_INCREF?
Patch #1517947 suggests adding an assert for these. Is that acceptable or just considered a drop in ocean? Georg ___ 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] deprecate commands.getstatus()
I'd like to deprecate commands.getstatus() in 2.6. Reason: there is getoutput() and getstatusoutput(). In the latter, "status" means the exit code. getstatus(), however, returns the output of "ls -ld " which is completely nonobvious and confusing. Perhaps the whole commands module can be deprecated in favor of subprocess. Georg ___ 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] deprecate commands.getstatus()
On 3/13/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > I'd like to deprecate commands.getstatus() in 2.6. > > Reason: there is getoutput() and getstatusoutput(). In the latter, "status" > means the exit code. getstatus(), however, returns the output of "ls -ld > " which is completely nonobvious and confusing. +1. > Perhaps the whole commands module can be deprecated in favor of subprocess. -1. Reason (for both voteS): I have learned that the getoutput() and getstatusoutput() functions in the commands module are exceedingly popular amongst Googlers who write simple Python scripts that occasionally invoke an external command. It's much simpler than using os.popen() or the subprocess module (which is also very popular BTW). But I have found no uses of commands.getstatus() in our entire codebase so I'm okay with seeing that mistake finally eradicated (and it was *my* mistake :-). -- --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] assert(obj) in Py_DECREF and Py_INCREF?
Georg Brandl schrieb: > Patch #1517947 suggests adding an assert for these. > > Is that acceptable or just considered a drop in ocean? I think it's pointless. If they ever be NULL, the INCRE/DECREF will crash right away, anyway, so you'll certainly notice. As you will have a debug build when the assertion triggers, you can just as well fine the location of the crash quickly in the debugger (e.g. using the core file on systems that support that, or the JIT-debugger on other systems). 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] deprecate commands.getstatus()
Guido van Rossum schrieb: > On 3/13/07, Georg Brandl <[EMAIL PROTECTED]> wrote: >> I'd like to deprecate commands.getstatus() in 2.6. >> >> Reason: there is getoutput() and getstatusoutput(). In the latter, "status" >> means the exit code. getstatus(), however, returns the output of "ls -ld >> " which is completely nonobvious and confusing. > > +1. Done in rev. 54361. Georg ___ 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] deprecate commands.getstatus()
On 3/13/07, Titus Brown <[EMAIL PROTECTED]> wrote: > What about reimplementing commands.* using subprocess? Or providing a > commands.*-compatible interface in the subprocess module? What does that buy us? -- --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
