Martin v. Löwis wrote:
And that's the main difference why having encode/decode is a good idea,
and having transform/untransform is a bad idea.
I agree that 'untransform' is a bad name for the inverse of transform,
but I don't think 'transform' is bad. For me the distinction is
existence of
Stephen J. Turnbull wrote:
But why be verbose *and* ignore the vernacular?
gzipped = plaintext.transform('gzip')
plaintext = gzipped.transform('gunzip')
I'm generally resistant to a registry, none of my applications are so
general that they would take advantage of a
string-key-to-di
I wrote:
...and it doesn't have to be reflexive if that...
Umm, that should have said 'have an inverse', which is different than
reflexive or symmetric. I get a little lost on 'surjective' and
'injective', having been taught the terms 'onto' and 'one-to-one'. But
I digress.
For wrapping
Fiddling with the name of the antonym doesn't help.
The direction of "untransform" or whatever it's
called is only as clear as the direction of
"transform".
How about making the transformation parameter more descriptive?
gzipped = plaintext.transform(plaintext_to_gzip)
plaintext = gzipped
Mike Meyer wrote:
> Yup, it's probably futile - most people don't care about portability
> or precision, and will use "byte" to mean "8-bit byte".
Nor will this be an issue in Python. Maybe an inset paragraph on some
footnote of a bit of documentation on a wiki page.
> Standards can't get away
How about reversing the order?
class C(object):
with x as property:
...
Joel
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman
Dj Gilcrease wrote:
> If I understand right, positional only arguments would not be optional
> in any way shape or form, thats what default arguments are for.
I have been expecting that by providing a default value to an argument
in the definition that you are making it optional, be it keyword o
Dj Gilcrease wrote:
> On Thu, Feb 14, 2008 at 6:04 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > Now can you come up with a syntax for positional-only
>> > arguments? So far everybody has failed at that, and there are some use
>> > cases where it's useful too.
>
>
>
Speaking from the protocol encoding/decoding view, and one where a
buffer is very similar to a list of small integers...
>> Also what about .replace() and .translate()?
>
>> If they are not done in place should they return a new buffer (PyBytes_)
>> object or a bytes (PyString_) object? [i'd sa
Should this PEP include changes to the struct module, or should it be a
separate PEP?
I would like struct.pack() to return bytes and struct.unpack() to accept
bytes or buffers but not strings. The 's' and 'p' format specifier
should refer to bytes and not strings.
In protocol encoding and dec
> Making an iterator over an integer sequence acceptable in the
> constructor strongly suggests that a byte sequence contains integers
> between 0 and 255 inclusive, not length 1 byte sequences.
>
> And I think that's the cleanest conceptual model for them as well. A
> byte sequence doesn't con
> **Open Issue:** I'm undecided on whether indexing bytes and buffer
> objects should return small ints (like the bytes type in 3.0a1, and
> like lists or array.array('B')), or bytes/buffer objects of length 1
> (like the str type). The latter (str-like) approach will ease porting
> code from Pyth
> Sounds much like the modes offered by an old operating system that had a
> very nice lock manager.
Awe, VMS isn't THAT old, is it? :-)
I have a wrapper around threading.Lock and threading.RLock that I've
been using that does deadlock detection and have wished for these lock
modes many times
> http://www.python.org/dev/peps/pep-0362/
>
> This would be helpful for boost::python.
Speaking of helpful...
class X:
def f(self): pass
class Y(X): pass
...I would like a mechanism to indicate that Y.f is inherited, and I was
hoping that perhaps that information could be
Greg Ewing wrote:
> I'm wondering whether we want a "byte character literal"
> to go along with "byte string literals":
>
>h[0] == c"P"
>
> After all, if it makes sense to write an array of bytes
> as though they were ASCII characters, it must make sense
> to write a single byte that way as
Jason Orendorff wrote:
> Hooks would help with that, or even eliminate the need altogether.
IMHO, having a __bytes__ method would go a long way.
Joel
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-30
Guido van Rossum wrote:
> Personally I think support for the various accounting-style output is
> not worth it. I betcha any accounting system worth the name would not
> use this and instead have its own custom code for formatting anyway.
>
> My personal suggestion is to stay close to the .NET fo
> My preference would be to limit sum() to value addition only, and never do
> concatenation.
I would be happy with that, provided there was join function and operator:
>>> join = lambda x: reduce(lambda y, z: y.__join__(z), x)
I think this is clearer than sum():
>>> join(['a', 'b',
> It should be
>
> sum(*operands)
>
> not
>
> sum(operands, initialvalue=?)
>
> It should amount to "map(+, operands)".
Or, to be pedantic, this:
reduce(lambda x, y: x.__add__(y), operands)
Joel
___
Python-3000 mailing list
Python-3000@p
> @abstract
> def range(*args:3):
> ...
>
> then that would be best. I propose, therefore, that we require an
> integer annotation on the *args to enable positional dispatching.
I thought there was already a proposal to do something like this:
@abstract
def r
> @before(do_stuff)
> def debug_it(ob: ClassC):
> import pdb
> pdb.set_trace()
This is probably far fetched, but I would much rather see:
before do_stuff(ob: ClassC):
import pbd
pdb.set_trace()
So the keyword 'before' and 'after' are just
Phillip J. Eby wrote:
>> Personally, I still think that the most uniform way of spelling this
>> is overloading isinstance and issubclass; that has the highest
>> likelihood of standardizing the spelling for such inquiries.
>
> A big +1 here. This is no different than e.g. operator.mul() being a
I've come late to this thread, and misunderstood what was wrong with
super(), so a thousand pardons please. But since that's never stopped
me before...
Guido van Rossum wrote:
> But:
>
> class E(D): pass
>
> print E().f()
>
> This prints DDBCA which surely isn't right.
>
> Sounds like the
> But I haven't figured out how to do that yet...
It turns out to be easier than I thought, and it avoids changing the
object __class__, which is ugly.
class _super(property):
def __init__(self):
property.__init__(self, self.get_super, None, None)
def get_sup
I mucked around with this, and here is my version:
class _super(property):
def __init__(self):
property.__init__(self, self.get_super, None, None)
def get_super(self, klass):
def dong(obj):
class wrapper:
def _
25 matches
Mail list logo
