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=detailaid=1590352group_id=5470atid=305470
I've
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...
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
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
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 about
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 the
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 interface
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 I could
[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 to be this
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
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
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 lazy
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
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.
/F
___
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 point,
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 had made such a
[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 to be this
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 recompile
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
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 stringobject.c,
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 could
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 its
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
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 result
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
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:
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
]
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
where that name is no longer accurate. So I've redubbed it the lazy
strings patch.
[snip
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.
The major new feature is that string *slices* are also represented with
a lazy-evaluation placeholder for the actual string, just as
29 matches
Mail list logo
