I think Python needs a dedicated "pragma" syntax; we already have two
pragma syntaxes ("from __future__ import" and "# coding"), and I think a
syntax designed for expressing pragmas would be much clearer than using
existing language features in weird ways to express pragmas. But that's
a deb
Greg Ewing wrote:
Yes, but then I don't see the advantage over just giving the object a copy()
method and calling it directly.
In other words, I see little benefit in having copy() be a generic function.
So true! Other candidates for not being generic functions: len(),
repr(), str(), int
Christian Heimes wrote:
Larry Hastings wrote:
+1 for exactly the reasons cited. I think copy() and deepcopy() should
both be "essential" built-in functions.
I'm -0 on copy and -1 on deepcopy.
If you need a copy or a deepcopy of an object (except dicts, lists and
set
Steven Bethard wrote:
Maybe copy.copy() could become __builtin__.copy()?
+1 for exactly the reasons cited. I think copy() and deepcopy() should
both be "essential" built-in functions.
/larry/
___
Python-3000 mailing list
Python-3000@python.org
http
Nicko van Someren wrote:
Do we really want set literals at all, given that set(...) exists?
If we are going to have one then, it seems to make sense to have
both. If we are going to have both, I would rather that they generate
the same type of set.
Maybe the postings crossed in the ether
Oleg Broytmann wrote:
The article says "decimal" is a synonym. What is the point to use an
unknown synonym instead of a well-known word?
His point is that Python has a fixed-point number type called "Decimal",
and that this will lead to confusion. I can see his point, but we all
know from ye
Guido van Rossum wrote:
I think I've been convinced that b[0] should return an int in range(256).
This made me feel funny. I stared at this for a while:
b'a' != b'abcde'[0] ?!?
b'a'[0] != b'a' ?!?
Then I realized that making b[0] return an int simply makes bytes
objects behave less li
Guido van Rossum wrote:
On 9/15/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
Changing the existing behaviour of argv would probably
be too disruptive, so how about relegating argv to a
low-level detail and providing something else for
everyday use that omits argv[0]?
sys.arguments would sound
Mark Summerfield wrote:
(Personally I've never needed an insertion-ordered dict.)
Then you've never programmed in PHP I take it. PHP's one-size-fits-all
data structure is an insertion-ordered dict; PHP programmers use it
everywhere a Python programmer might use a dict /or/ a list. I've had
Nicholas Bastin wrote:
As for the user-replaceable shared library part, that's up for
considerable debate. It's unlikely that static linkage legally
creates a derivative work (that would be pretty unreasonable in
computer science terms), but it's never been tested in court, so
static linking wou
Greg Ewing wrote:
If there's a link on the same web page that works
when the user clicks on it, I don't think they're
even going to notice the difference.
They'll notice the difference when they want to redistribute Python,
when they note the new licensing-based restrictions ("GMP must be in a
Thomas Wouters wrote:
Because (relatively) small dicts with (broadly speaking) similar keys
are quite common in Python. Module and class and instance __dict__s,
for instance ;) As Tim mentioned, the dict implementation only looks
at part of the actual hash value (depending on the size of the di
If the Python community is just noticing the Hsieh hash, that implies
that the Bob Jenkins hashes are probably unknown as well. Behold:
http://burtleburtle.net/bob/hash/doobs.html
To save you a little head-scratching, the functions you want to play
with are hashlittle()/hashlittle2() in "l
Patch submitted to Roundup; it's issue #1007:
http://bugs.python.org/issue1007
(It's listed under Python 2.6 as there's currently no appropriate choice
in the "Versions" list.)
/larry/
___
Python-3000 mailing list
Python-3000@python.org
http://ma
Attached is a patch for review.
As of revision 57341 (only a couple hours old as of this writing),
test_shelve was failing on my machine. This was because I didn't have
any swell databases available, so anydbm was falling back to dumbdbm,
and dumbdbm had a bug. In Py3k, dumbdbm's dict-like
Delaney, Timothy (Tim) wrote:
> A view is a lightweight object that implements an interface by
> delegating to an underlying object. The underlying object cannot be
> changed through the view, but could be changed directly, in which case
> the view will reflect the new contents of the object.
It ce
Aahz wrote:
> While I don't have an opinion about the patch itself, I do have an
> opinion about other people's opinions. ;-) That is, my opinion is that
> unless you get a +1 from at least one of Fredrik, MvL, or MAL (and no -1
> from any of them), this patch should be abandoned. (The exact set
Josiah Carlson wrote:
> Perhaps I missed something about the concatenation implementation, but in
> order to prevent the rendering of lazy concatenation objects, shouldn't you
> need to keep a reference and pointer to the left and right
> strings/concatenation objects? This isn't the same as a
I'd like to start a (hopefully final) round of discussion on
the "lazy strings" series of patches. What follows is a summary
on the current state of the patches, followed by five poll
questions.
I apologize in advance for the length of this posting.
A NOTE BEFORE WE BEGIN
The "lazy strings"
Guido van Rossum wrote:
Experiment, see what results in the cleanest code in typical usage.
I experimented, and surprise! it's the API we already have. Returning
both "p" and "len" was only helpful for the ill-fated "options #3 and
#4"; once that requirement dropped away, the best approach bec
Guido van Rossum wrote:
Finally (unrelated to the memory problem) I'd like to see some
benchmarks to prove that this is really worth it.
Here's a first cut at some benchmarks. I gently hacked the pybench in
Tools so it'd run, and compared the full "lazy strings" patch to an
unpatched tree. In
Jim Jewett wrote:
> On 1/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> But IIUC the string may already have been seen by other code, right?
>> This violates immutability, and that's not acceptable.
> No.
>
> IIRC, the string was rendered as soon as any code viewed it. Since it
> isn't ren
Guido van Rossum wrote:
I like having a function (not macro) that returns pointer and length
through output variables.
I proposed a macro because I planned some cheap inlining. Casts and
parentheses omitted for *cough* clarity:
#define PyUnicode_VALUE(self, p, len) ((self->str != NULL) ? (p
Guido van Rossum wrote:
Changing the API is the only reasonable solution amongst all the
options I've seen.
I defer to you. Perhaps another approach will surface; in the meantime
I'll start on the API change.
You suggested changing the name as a reminder of the semantics change.
Are you in
I don't understand what you mean by #3 and #4; change *which* length?
The phrasing of #3 using "hopefully-big-enough" and "odds" immediately
makes me think "buffer overflow attack" which is a non-starter.
Change the length of the string.
Example: our lazy string should be 4032 bytes long, but
Guido van Rossum wrote:
As discussed on that page, the current version of the patch could cause
crashes in low-memory conditions. I welcome suggestions on how best to
resolve this problem. Apart from that fly in the ointment I'm pretty
happy with how it all turned out.
What kind of crashes? Th
I've just posted my first pass of the full "lazy strings" patch, with
both "lazy concatenation" and "lazy slices". It's available on
Sourceforge here:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1629305&group_id=5470
It applies cleanly (with "patch -p1") against the curren
On Tue, Dec 19, 2006, Guido van Rossum wrote:
On 12/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
(I haven't abandoned this, but it hasn't been a top priority;
partially because Larry Hastings work on smarter concatenation has
showed that "lazy evaluation" can w
Aahz wrote:
On Tue, Dec 19, 2006, Guido van Rossum wrote:
On 12/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
(I haven't abandoned this, but it hasn't been a top priority; partially
because Larry Hastings work on smarter concatenation has showed that
"lazy ev
29 matches
Mail list logo
