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/)
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
>> " wh
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
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
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 deprecat
Patch #1517947 suggests adding an assert for these.
Is that acceptable or just considered a drop in ocean?
Georg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
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 packa
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
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 sup
> 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 t
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.
-
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
12 matches
Mail list logo
