[Reinhold Birkenfeld]
> This last patch includes a new exception, are you sure that this can
be
> safely backported?
Not too worried about it. Better to have the exception reported than
the silent failure that confused the heck out of everyone who tried to
figure-out what caused the OP's problem.
[EMAIL PROTECTED] wrote:
> Update of /cvsroot/python/python/dist/src/Lib
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31892
>
> Modified Files:
> Tag: release24-maint
> urllib.py
> Log Message:
> Sync-up with patches to the head.
> Includes SF 1016880: urllib.urlretrieve si
Okay. I consider it rejected.
Reinhold
Guido van Rossum wrote:
>>From the sound of it, it's probably not worth endowing every string
> object with this method and hardcoding its implementation forever in C
> code. There are so many corner cases and variations on the
> functionality of "dedenting"
Patch / Bug Summary
___
Patches : 343 open ( +1) / 2927 closed ( +4) / 3270 total ( +5)
Bugs: 908 open ( +0) / 5245 closed (+13) / 6153 total (+13)
RFE : 189 open ( +1) / 185 closed ( +0) / 374 total ( +1)
New / Reopened Patches
__
Allow to
> some time ago, I proposed a string method "dedent" (which currently is
in
> the
> textwrap module). The RFE is at http://python.org/sf/1237680.
>
> Any opinions? If I don't get positive comments, I'll reject it.
-1
Let it continue to live in textwrap where the existing pure python code
adequat
Nathan Bullock wrote:
> I find that I quite often want a
> function that will give me a relative path from path A
> to path B. I have created such a function, but it
> would be nice if it was in the standard library.
+1 from me. It's a fairly common thing to want to do.
Greg
_
On 9/14/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > Index: test_ioctl.py
> > ===
> > RCS file: /cvsroot/python/python/dist/src/Lib/test/test_ioctl.py,v
> > retrieving revision 1.2
> > retrieving revision 1.3
> > diff -u -d -r1.2 -r
>From the sound of it, it's probably not worth endowing every string
object with this method and hardcoding its implementation forever in C
code. There are so many corner cases and variations on the
functionality of "dedenting" a block that it's better to keep it as
Python source code.
On 9/14/05,
Hi,
some time ago, I proposed a string method "dedent" (which currently is in the
textwrap module). The RFE is at http://python.org/sf/1237680.
Any opinions? If I don't get positive comments, I'll reject it.
Reinhold
--
Mail address is perfectly valid!
Ah, ok. Then I guess everything's fine. It was just the
/* make sure there are no duplicate values for an argument;
its not clear when to use the term "keyword argument vs.
keyword parameter in messages */
that disturbed me.
Reinhold
Guido van Rossum wrote:
> Correct usage is argument for
Correct usage is argument for the call site but parameter for the
function/method definition. So you can't just count occurrences.
On 9/14/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> Hi,
>
> looking at bug #1283289, I saw that the term "keyword parameter" is used in
> Python/getargs.c, m
Hi,
looking at bug #1283289, I saw that the term "keyword parameter" is used in
Python/getargs.c, mixed with "keyword argument".
Grepping through the source, "keyword parameter" had 43 matches, while
"keyword argument" had 430. Should the "parameter" form be extinguished?
Reinhold
(And BTW, sho
[re-adding Python-Dev]
On Wed, 2005-09-14 at 02:00 +0200, Henrik Levkowetz wrote:
> Hi Peter,
>
> on 2005-09-10 21:29 Peter Jones said the following:
> > Hi,
> >
> > In Python 2.4.1, Python/sysmodule.c includes a function PySys_SetArgv().
> > One of the things it does is attempt to resolve symbo
Phillip J. Eby wrote:
> I think this is called a "polymorphic inline cache", although it doesn't
> seem very polymorphic if you're only caching one type. :)
if it's not polymorphic, it's an ordinary inline cache (aka "call-site cache").
(see various Self papers for more on polymorphic caches)
> Index: test_ioctl.py
> ===
> RCS file: /cvsroot/python/python/dist/src/Lib/test/test_ioctl.py,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -d -r1.2 -r1.3
> --- test_ioctl.py 20 Mar 2003 04:33:16 - 1.
I have no way to test this code on Windows (or on other UNIX platforms
besides Linux and AIX). Hopefully someone can verify whether it breaks
anything.
-- Forwarded message --
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Sep 14, 2005 11:15 AM
Subject: [Python-checkins] python/
At 09:12 PM 9/14/2005 +0400, Sokolov Yura wrote:
>We could cash looks by this way:
>Store with a class its version. Every time after creation when we change
>a class
>(add,remove or chage class member, including __base__, __bases__ and mro) ,
>we increase the version number. Lets call it VERSION
Excuse my english.
I have a complex Idea. It can be not worth, but just look at.
It touches the classes and inheritance.
Base point:
We change classes not too often. But every look at a member leads to
search throw
a __dict__ of all bases in ierarhy till member found. We could cache
this search
At 06:55 PM 9/14/2005 +0200, Martin v. Löwis wrote:
>Neal Norwitz wrote:
> > This code doesn't really work in general. It assumes that any append
> > function call is a list method, which is obviously invalid. But if a
> > variable is known to be a list (ie, local and assigned as list
> > (BUILD_
Martin v. Löwis wrote:
> Alternatively, couldn't LIST_APPEND check that this really is a list,
> and, if it isn't, fall back to PyObject_CallMethod?
that's the obvious solution, of course. cf. existing shortcuts:
$ grep -n INLINE Python-2.4.1/Python/ceval.c
1103: /* IN
Martin v. Löwis wrote:
> Neal Norwitz wrote:
>> This code doesn't really work in general. It assumes that any append
>> function call is a list method, which is obviously invalid. But if a
>> variable is known to be a list (ie, local and assigned as list
>> (BUILD_LIST) or a list comprehension),
Neal Norwitz wrote:
> This code doesn't really work in general. It assumes that any append
> function call is a list method, which is obviously invalid. But if a
> variable is known to be a list (ie, local and assigned as list
> (BUILD_LIST) or a list comprehension), could we do something like th
On 9/12/05, Nathan Bullock <[EMAIL PROTECTED]> wrote:
> Just wondering if a function such as this has ever
> been considered? I find that I quite often want a
> function that will give me a relative path from path A
> to path B. I have created such a function, but it
> would be nice if it was in th
Victor STINNER wrote:
> RexFi explains me that Python can't guess eval('len(u"é")') charset.
I personally like to see a charset argument for eval() and compile().
exec would not directly support other charsets; you would have to
compile() first to specify a charset.
I have a patch somewhere that
24 matches
Mail list logo
