Guido van Rossum wrote:
>> Many times I find myself asking for a slice of a specific length,
>> rather than a slice with a specific end. I suggest to add the syntax
>> object[start:>length] (or object[start:>length:jump]), beside the
>> existing syntax.
> Feel free to continue to argue for this, but I'm -1, and that usually
> kills a proposal dead. I doubt that you'll be able to get enough
> influential people on python-dev to rally for your proposal; but I'm
> sure they will explain to you why your syntax is unpythonic and the
> feature is so minor as to be unneeded.
It already was explained when this came up on c.l.py ...
"Martin v. Löwis" wrote:
> Raymond Hettinger wrote:
> > Instances of classes inheriting from str, tuple, etc cannot
> be weakly
> > referenced. Does anyone know the reason for this?
> In addition to the reason Christian gave, one (conceptually more
> important) reason is that strings can't participate in cycles. Weak
> references were introduced as a mechanism to avoid creating cyclic
> structures, so that "backward" links could be made weak references.
> It appears that people have then been eager to add weakref support
> to other datatypes. IMO, they have been too eager. For example, I
> can't see a reason why Unicode objects should be weakly referencable
> (just as I can't see a reason for plain strings).
Never rule out "foolish" consistencies. I can imagine a system where multiple, heterogeneous values all get run through a weakref processor; to have string objects pass through without Yet Another try/except would be a design and maintenance boon.
Quite similar to my current "pet peeve":
>>> None > 3
>>> None > 'hoopy'
>>> None > True
>>> None > datetime.date(2004, 5, 31)
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
TypeError: can't compare datetime.date to NoneType
...writing an O-R mapper, this particular hobgoblin bites me rather often ;)
> Fix grammar hopefully. :)
> ! - Unicode type got two new methods; iswide() and width(). They
> ! manipulate east asian width information as of Unicode TR11.
> ! - Unicode type got two new methods now; iswide() and width(). They
> ! manipulate east asian width information from Unicode TR11.
Not that I think that having grammatically perfect NEWS is at all important,
but this isn't grammatically correct.
Something like "The Unicode type received two new methods: iswide() and
width(). These manipulate East Asian width information, as outlined in
Unicode TR11" is probably what you're after.
> We can always point people at the daily tarballs of the CVS HEAD.
Are these generated by SourceForge? If so, note that the same problem
affecting viewcvs and anonymous cvs is also affecting the tarballs as well.
I doubt this is much of an issue, though - most of the bugs would be
independent enough to be able be worked on from slightly old cvs, wouldn't
they? Maybe SourceForge's "timely resolution" will come through before
I remember from a year or so ago that the various PSF licensing agreements
were not finalised, but Guido said contributors should still sign them in
their draft form. Have things moved on at all since then? I recall that
Guido said legal ditherings had been going on for a year or so even back
then. cookielib is a derived work of libwww-perl, so I guess I need to
get Gisle Aas (libwww-perl's author) to sign something if it is to be part
of 2.4, right?
(BTW, I've written LaTeX docs for cookielib now, comments welcome. Patch
Chermside, Michael wrote:
> The only bit that seems tricky to me is determining the crossover
> value in pure C. How do we do that?
I think that's as simple as pow(FLT_RADIX, DBL_MAX_DIG).
So the comparison would go something like:
def cmp_floatvlong_positive(afloat, along):
assert afloat >=0 and along >= 0
if along < FLT_RADIX**DBL_MANT_DIG:
# the long is representable as float
return cmp(afloat, float(along))
elif afloat >= FLT_RADIX**DBL_MANT_DIG:
# the float is representable as integer
return cmp(long(afloat), along)
# At this point we know: afloat < FLT_RADIX**DBL_MANT_DIG <= along
def cmp_floatvlong(afloat, along):
ures = cmp_floatvlong_positive(abs(afloat), abs(along))
if (afloat >= 0) != (along >= 0):
Assuming FLT_RADIX is a power of 2, comparing the long to the
crossover value can be implemented by counting bits of magnitude,
if along < FLT_RADIX**DBL_MANT_DIG:
if trunc(lg(along)) < lg(FLT_RADIX)*DBL_MANT_DIG:
The crossover value as a float can be (pre-)computed the
straightforward way: pow(FLT_RADIX, DBL_MAX_DIG) will always be exact
> One more attempt to fix the grammar.
> ! - Unicode objects received two new methods now; iswide()
> and width(). They
> ! query east asian width information according to Unicode TR11.
One more attempt to fix the fix <wink>.
1. "east asian" should be "East Asian".
2. The semi-colon after "now" should be a colon.
3. The "now" after "methods" should be removed.
Given the content changes, I'd now suggest:
"Unicode objects received two new methods: iswide() and width(). These
query East Asian width information, as specified in Unicode TR11."
(To me (and this might be a NZ thing or something) "according to" doesn't
convey the quite same meaning as "as specified in", or "as described by", or
words to that effect; hence the other change. It's not as important).
I just noticed SF bug #850964, which Fred kindly fixed (back in
April)... except he did it by modifying optparse.py, which is a no-no.
As it says in the comment at the top:
# Python developers: please do not make changes to this file, since
# it is automatically generated from the Optik source code.
Luckily, I've already fixed this bug in the Optik CVS, very similarly to
Fred's fix. So the fact that optparse.py will be clobbered sooner or
later doesn't really matter in this case. But it might have!
Greg Ward <gward(a)python.net> http://www.gerg.ca/
Sure, I'm paranoid... but am I paranoid ENOUGH?
On Wed, Jun 02, 2004 at 08:36:47PM -0400, Tim Peters wrote:
> [Jeff Epler]
> > Oh -- there are some floats f for which
> > float(long(f))
> > raises an OverflowError in float()?
> No, at least not unless the machine has very strange arithmetic. For an
> IEEE box,
Thanks. I re-read the message I was replying to, and now I see the
problem with the code I proposed. I just didn't get it the first time.