[EMAIL PROTECTED] wrote:
> Talin writes:
> > (one additional postscript - One thing I would be interested in is an
> > approach that unifies file paths and URLs so that there is a consistent
> > locator scheme for any resource, whether they be in a filesystem, on a
> > web server, or stored
[EMAIL PROTECTED] wrote:
> Talin writes:
> > (one additional postscript - One thing I would be interested in is an
> > approach that unifies file paths and URLs so that there is a consistent
> > locator scheme for any resource, whether they be in a filesystem, on a
> > web server, or stored
Talin writes:
> (one additional postscript - One thing I would be interested in is an
> approach that unifies file paths and URLs so that there is a consistent
> locator scheme for any resource, whether they be in a filesystem, on a
> web server, or stored in a zip file.)
+1
But doesn't fi
(one additional postscript - One thing I would be interested in is an
approach that unifies file paths and URLs so that there is a consistent
locator scheme for any resource, whether they be in a filesystem, on a
web server, or stored in a zip file.)
-- Talin
___
BJörn Lindqvist wrote:
> On 10/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 9/30/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>>> It would be terrific if you gave us some clue about what is wrong in
>>> PEP355, so
>>> that the next guy does not waste his time. For instance, I find PEP35
On Tuesday 24 October 2006 21:02, A.M. Kuchling wrote:
> Does someone need to unpack the 2.4.4 docs in the right place so that
> http://www.python.org/doc/2.4.4/ works?
That would be me, and yes, and done. Sorry for the delay; life's just been
busy lately. Time for me to go look at the releas
Does someone need to unpack the 2.4.4 docs in the right place so that
http://www.python.org/doc/2.4.4/ works?
--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
On 10/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/30/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> > It would be terrific if you gave us some clue about what is wrong in
> > PEP355, so
> > that the next guy does not waste his time. For instance, I find PEP355
> > incredibly good for
> class S(str):
> def __str__(self): return "S.__str__"
>
> class U(unicode):
> def __str__(self): return "U.__str__"
>
> print str(S())
> print str(U())
>
> This script prints:
>
> S.__str__
> U.__str__
Yes, but "print U()" prints nothing, and the explicit str() should not
be necessary.
I believe you've overriden unicode.__str__ as you expect.
class S(str):
def __str__(self): return "S.__str__"
class U(unicode):
def __str__(self): return "U.__str__"
print str(S())
print str(U())
This script prints:
S.__str__
U.__str__
Regards,
--
KAJIYAMA, Tamito <[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> >> Your posts are making it. It's just that everyone's ignoring you :)
>
> Christopher> I feel loved .
>
> Christopher> Seriously, why would somoene ignore this? this is
> Christopher> obviously not a pebkac problem.
>
> I'm not sure what a "pe
[EMAIL PROTECTED] wrote:
> I'm not sure what a "pebkac" problem is.
http://en.wikipedia.org/wiki/PEBKAC
You'll learn some new nonsense every day ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
>> Your posts are making it. It's just that everyone's ignoring you :)
Christopher> I feel loved .
Christopher> Seriously, why would somoene ignore this? this is
Christopher> obviously not a pebkac problem.
I'm not sure what a "pebkac" problem is. I will attempt to cha
> Your posts are making it. It's just that everyone's ignoring you :)
I feel loved .
Seriously, why would somoene ignore this? this is obviously not a
pebkac problem.
Respectfully,
Christopher Taylor
___
Python-Dev mailing list
Python-Dev@pyt
Christopher Taylor wrote:
> Ok, here's what I found: In addition to the configure script not
> taking changing LIBDIR, Modules/getpath.c uses a hardcoded value for
> static chat lib_python[] = "lib/python" VERSION;
> which appears on line 134. So even if the configure script changes
> LIBDIR it w
Christopher> I'm wondering if my posts are going through??
Yup. Sorry, but I've no useful comments to make on your problems though.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
Ok, here's what I found: In addition to the configure script not
taking changing LIBDIR, Modules/getpath.c uses a hardcoded value for
static chat lib_python[] = "lib/python" VERSION;
which appears on line 134. So even if the configure script changes
LIBDIR it won't do much good because the value
> Based on the behaviour of str and the fact that overriding unicode.__repr__
> works just fine, I'd say file a bug on SF.
Done. This is item 1583863.
Mike
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
Mike Krell wrote:
> Is this a bug? If not, how do I override __str__ on a unicode derived class?
Based on the behaviour of str and the fact that overriding unicode.__repr__
works just fine, I'd say file a bug on SF.
I think this bit in PyUnicode_Format needs to use PyUnicode_CheckExact instead
Per my conversation with Martin v. Löwis on the python-list, I think I
have found a problem with the configure script and Makefile.in.
For Python 2.4.4 it seems that the arguement --libdir does not change
the Makefile. Specifically I need this to change the libdir to
/usr/lib64 for RH on a x86_64
Jean-Paul Calderone wrote:
> On Mon, 23 Oct 2006 07:58:25 -0700, Larry Hastings <[EMAIL PROTECTED]> wrote:
>> [snip]
>> If external Python extension modules are as well-behaved as the shipping
>> Python source tree, there simply wouldn't be a problem. Python source is
>> delightfully consistent
On Oct 24, 2006, at 11:09 AM, Jack Jansen wrote:
Look at packages such as win32, PyObjC, ctypes, bridges between
Python and other languages, etc. That's where implementors are
tempted to bend the rules of Official APIs for the benefit of
serious optimizations.
PyObjC should be safe in
On 23-Oct-2006, at 16:58 , Larry Hastings wrote:I genuinely don't know how many external Python extension modules are well-behaved in this regard. But in case it helps: I just checked PIL, NumPy, PyWin32, and SWIG, and all of them were well-behaved. Apart from stringobject.c, there was exactly o
23 matches
Mail list logo
