Is this a bug? If not, how do I override __str__ on a unicode derived class?
class S(str):
def __str__(self): return '__str__ overridden'
class U(unicode):
def __str__(self): return '__str__ overridden'
def __unicode__(self): return u'__unicode__ overridden'
s = S()
u = U()
print '
On behalf of the Python development team and the Python
community, I'm announcing the release of Python 2.3.6
(release candidate 1).
Python 2.3.6 is a security bug-fix release. While Python 2.5
is the latest version of Python, we're making this release for
people who are still running Python 2.3.
Larry Hastings schrieb:
> Am I correct in understanding that changing the Python minor revision
> number (2.5 -> 2.6) requires external modules to recompile? (It
> certainly does on Windows.)
There is an ongoing debate on that. The original intent was that you
normally *shouldn't* have to recompi
[EMAIL PROTECTED] schrieb:
> >> Anyway, it was my intent to post the patch and see what happened.
> >> Being a first-timer at this, and not having even read the core
> >> development mailing lists for very long, I had no idea what to
> >> expect. Though I genuinely didn't expect it
On Mon, 23 Oct 2006 09:07:51 -0700, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
>"Paul Moore" <[EMAIL PROTECTED]> wrote:
>> I had picked up on this comment, and I have to say that I had been a
>> little surprised by the resistance to the change based on the "code
>> would break" argument, when you
"Paul Moore" <[EMAIL PROTECTED]> wrote:
> I had picked up on this comment, and I have to say that I had been a
> little surprised by the resistance to the change based on the "code
> would break" argument, when you had made such a thorough attempt to
> address this. Perhaps others had missed this
Larry Hastings wrote:
> Am I correct in understanding that changing the Python minor revision
> number (2.5 -> 2.6) requires external modules to recompile?
not, in general, on Unix. it's recommended, but things usually work
quite well anyway.
___
Larry> The only function that *might* return a non-terminated char * is
Larry> PyString_AsUnterminatedString(). This function is static to
Larry> stringobject.c--and I would be shocked if it were ever otherwise.
If it's static to stringobject.c it doesn't need a PyString_ prefix. In
On 10/23/06, Larry Hastings <[EMAIL PROTECTED]> wrote:
>
> Steve Holden wrote:
>
> But it seems to me that the only major issue is the inability to provide
> zero-byte terminators with this new representation.
>
> I guess I wasn't clear in my description of the patch; sorry about that.
>
> Like
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 about using the macro PyString_AS_ST
Steve Holden wrote:
But it seems to me that the only major issue is the inability to provide
zero-byte terminators with this new representation.
I guess I wasn't clear in my description of the patch; sorry about that.
Like "lazy concatenation objects", "lazy slices" render when you ca
[EMAIL PROTECTED] wrote:
> >> Anyway, it was my intent to post the patch and see what happened.
> >> Being a first-timer at this, and not having even read the core
> >> development mailing lists for very long, I had no idea what to
> >> expect. Though I genuinely didn't expect it t
>> Anyway, it was my intent to post the patch and see what happened.
>> Being a first-timer at this, and not having even read the core
>> development mailing lists for very long, I had no idea what to
>> expect. Though I genuinely didn't expect it to be this brusque.
Martin>
Josiah Carlson wrote:
> Want my advice? Aim for Py3k text as your primary target, but as a
> wrapper, not as the core type (I put the odds at somewhere around 0 for
> such a core type change). If you are good, and want to make guys like
> me happy, you could even make it support the buffer interf
14 matches
Mail list logo
