Larry Hastings <[EMAIL PROTECTED]> wrote:
> But I'm open
> to suggestions, on this or any other aspect of the patch.
As Martin, I, and others have suggested, direct the patch towards Python
3.x unicode text. Also, don't be surprised if Guido says no...
http://mail.python.org/pipermail/python-30
On 2006/10/20, Larry Hastings wrote:
> I'm ready to post the patch.
Sheesh! Where does the time go.
I've finally found the time to re-validate and post the patch. It's
SF.net patch #1590352:
http://sourceforge.net/tracker/index.php?func=detail&aid=1590352&group_id=5470&atid=305470
I've at
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
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
Josiah Carlson wrote:
> It would be a radical change for Python 2.6, and really the 2.x series,
> likely requiring nontrivial changes to extension modules that deal with
> strings, and the assumptions about strings that have held for over a
> decade.
the assumptions hidden in everyone's use of th
Larry Hastings <[EMAIL PROTECTED]> wrote:
> It was/is my understanding that the early days of a new major revision
> was the most judicious time to introduce big changes. If I had offered
> these patches six months ago for 2.5, they would have had zero chance of
> acceptance. But 2.6 is in it
Larry Hastings 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 to be this brusque.
I cou
Larry Hastings wrote:
> Martin v. Löwis wrote:
> Let's be specific: when there is at least one long-lived small lazy
> slice of a large string, and the large string itself would otherwise
> have been dereferenced and freed, and this small slice is never examined
> by code outside of stringobjec
Martin v. Löwis wrote:
> It's not clear to me what you want to achieve with these patches,
> in particular, whether you want to see them integrated into Python or
> not.
>
I would be thrilled if they were, but it seems less likely with every
passing day. If you have some advice on how I might
On Sat, 21 Oct 2006, Mark Roberts wrote:
[...]
> If there's a widely recognized argument against this, a link will likely
> sate my curiosity.
Quoting from Martin v. Loewis earlier on the same day you posted:
"""
I think this specific approach will find strong resistance. It has been
implemented
son <[EMAIL PROTECTED]>
> Subject: Re: [Python-Dev] The "lazy strings" patch
> Sent: 21 Oct '06 22:02
>
>
> Larry Hastings <[EMAIL PROTECTED]> wrote:
> >
> > I've significantly enhanced my string-concatenation patch, to the point
> &
Larry Hastings <[EMAIL PROTECTED]> wrote:
>
> I've significantly enhanced my string-concatenation patch, to the point
> where that name is no longer accurate. So I've redubbed it the "lazy
> strings" patch.
[snip]
Honestly, I don't believe that pure strings should be this complicated.
The im
See also the Cedar Ropes work:
http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/vol25/issue12/spe986.pdf
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
Larry Hastings schrieb:
> I've significantly enhanced my string-concatenation patch, to the point
> where that name is no longer accurate. So I've redubbed it the "lazy
> strings" patch.
It's not clear to me what you want to achieve with these patches,
in particular, whether you want to see them
Talin wrote:
> Interesting - is it possible that the same technique could be used to
> hide differences in character width? Specifically, if I concatenate an
> ascii string with a UTF-32 string, can the up-conversion to UTF-32 also
> be done lazily?
of course.
and if all you do with the resul
Interesting - is it possible that the same technique could be used to
hide differences in character width? Specifically, if I concatenate an
ascii string with a UTF-32 string, can the up-conversion to UTF-32 also
be done lazily? If that could be done efficiently, it would resolve some
outstandi
29 matches
Mail list logo
