Roger Binns wrote:
Obviously the Python 3 documentation and examples need to be updated.
Also why not remove PyObject_HEAD_INIT from Python 3 headers so that if
it is used then the compile fails?
Is there some reason not to define PyObject_HEAD_INIT so
that it expands into the appropriate PyVa
Marcin 'Qrczak' Kowalczyk wrote:
2008/11/11 Greg Ewing <[EMAIL PROTECTED]>:
It would be possible to implement this convention in the
sort method
Until someone wishes to sort a list of some objects by key, where the
keys can be (1, None) compared with (1, 3).
Yes, I thought
M.-A. Lemburg wrote:
The difference is that None is a singleton, so the set of all
None type instances is {None}. You always have an intuitive total order
relation on one element sets: the identity relation.
I don't see this having much practical consequence, though,
since sorting members of a
M.-A. Lemburg wrote:
On 2008-11-11 14:28, Antoine Pitrou wrote:
But why should "n/a" (or "missing", or "undefined") imply "smaller than
everything else"?
It's just a convention based on viewing None as "nothing" or the
empty set.
It would be possible to implement this convention in the
sort
M.-A. Lemburg wrote:
And here's another one:
...
Two values that compare equal to each other (and are in fact identical),
yet cannot be compared less-than or greater-than.
That's not particularly surprising -- complex numbers have
been like that for a long time. The only surprise, if any,
is t
James Y Knight wrote:
Since from what I've tried, things seem to work, I'd really like to
know what precisely does fail from the opponents of utf-8b.
Seems like what will fail is taking one of these utf-8b
decoded names and passing it to some external library
that uses it as a filename withou
Giles Constant wrote:
How about (explanation of syntax to follow):
boolean = match(input, "oneormore(digit).one('hello')")
Take this a step further and use constructor functions
to build the RE.
from spiffy_re import one, oneormore
pattern = oneormore(digit) + one('hello')
match = pat
Stefan Behnel wrote:
We create a new struct for the type that contains the parent-struct
as first field, and then we add the new attributes of the new type behind
that.
I seem to remember there's a field in the type called tp_basicsize
that's meant to indicate how big the base part of the stru
Nick Coghlan wrote:
- we're just going to have to add a second C level method slot that uses
the unaryfunc signature (returning PyObject *) for a "virtual length"
method in addition to the existing mp_length and sq_length (which return
PySsize_t).
As an aside, is there any plan to clean up the
Stefan Behnel wrote:
In the absence of information provided by an external transport protocol (e.g.
HTTP or MIME), it is a fatal error for an entity including an encoding
declaration to be presented to the XML processor in an encoding other than
that named in the declaration [...]
But if the X
Levi wrote:
Recently I've taken some interest in PEP 3106 (revamping dick.keys,
^
Is this a feature related to some kind of chastity belt for men? :-)
--
Greg
___
Python-3000 mailing
Nick Coghlan wrote:
Objects which compare equal must also end up in the same hash bucket in
order for dictionaries to work correctly.
And, if its equality with another object can change during
its lifetime, it will never work properly in a dictionary.
So in that case you should leave __hash__
Nick Coghlan wrote:
With keyword-only parameters allowed now, I think it makes sense to be
able to supply the keywords arguments after the variable length argument
as well.
I'm confused -- I thought that keyword-only arguments were
supposed to let you do exactly that. Or is that only in the
d
Terry Reedy wrote:
To me, it is more important that list(genexp) == corresponding_listcomp
than that the definition of genexp be minimal.
Then listcomps would also have to catch StopIterations
and transmute them correspondingly.
This seems like a lot of trouble to go to in order to
fix a rath
Adam Olsen wrote:
However, since the genexp considers all improper ones to be in error,
it could wrap them with a RuntimeError and pass it through .next()
instead.
Would you do that only for genexps, or for generators
in general?
The current behaviour seems to be that if you explicitly
raise S
Stefan Behnel wrote:
While I agree with this being bad design, I do think that the above is a bug.
It's a different thing if the iterable in the list comp/genexp raises a
StopIteration, or if the conditional does it. And not silently catching
anything raised by the latter sounds like the right t
Antoine Pitrou wrote:
That is, in your example:
>>> def f(x):
... if x > 5: raise StopIteration
...
>>> list(x for x in range(100) if not f(x))
[0, 1, 2, 3, 4, 5]
f() certainly shouldn't raise a StopIteration. There's no reason for doing
that, other than taking dirty implementation shortcut
Oleg Broytmann wrote:
Instead of seeking in the filesystem you end up seeking in the zip. Why
do you expect it'd be faster?
It might help if everything the interpeter needs during
startup could be grouped together in the zip file, so
that it's spread over less disk blocks.
--
Greg
_
Antoine Pitrou wrote:
what is the reason for
PyException_Set{Traceback,Cause,Context} not to INCREF their argument?
Probably because the vast majority of the time the
caller is not doing anything further with these
references, so this arrangement saves some increfs
and decrefs.
--
Greg
___
Martin v. Löwis wrote:
However, _sre relied on the module already being in
sys.modules, as it runs Python code in the init function that already
imports the module being initialized.
This issue also potentially affects all Pyrex and Cython
generated modules, which must be free to execute
Thomas Heller wrote:
So, when all modules are changed to properly support multiple interpreters,
it may be possible to implement a module combining the benefits of
both threading and multiprocessing - moving computation to a separate
interpreter (with its own GIL) without the need to marshal da
Stefan Behnel wrote:
So that means it's fine to remove all locking related functionality from the
new buffer protocol and leave everything to application space, right?
Not quite all of it -- the buffer needs to be considered
as locked against moving between calls to getbuffer and
releasebuffer,
Stefan Behnel wrote:
So you'd always have to release your own read buffer before acquiring a
write buffer
Yes, you really want to be able to upgrade your own lock
from a read lock to a write lock, which means the provider
has to keep track of who the lock holder is somehow.
The more I think ab
Stefan Behnel wrote:
I don't think there should always be a lock in the sense that the requestor is
the only permitted accessor.
No, but there's always a lock in the sense that the provider
is not allowed to move the memory while the buffer is in
use.
As for the other forms of locking, I'm sti
I don't understand all this stuff about getting unlocked
buffers and unlocking buffers while keeping them alive,
etc.
The way I thought this was supposed to work is that the
buffer is *always* locked while the client is accessing
it, the only choice being whether it's a read-only or
read-write lo
Atsuo Ishimoto wrote:
I'm not comfortable with "printable", too. Is "legible" better? This
is first time for me to see this word in my life :).
The term "printable" has a long history in computing of
meaning that a character code corresponds to some visual
glyph, even if the display process in
Daniel Wong wrote:
Ironic that you should mention it. He already mentioned it.
The time machine thing is pretty much a standard
joke in the Python community, which goes to show
how common it is for people to be pleasantly
surprised by what Python already does.
I think everyone's being a bit ha
Daniel Wong wrote:
Are there plans for introducing syntax like this:
(a, (b[2], c)) = ('big' ('red', 'dog'))
I think you'll find Guido has made another trip
in the time machine for this one:
Python 2.3 (#1, Aug 5 2003, 15:52:30)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyri
Lisandro Dalcin wrote:
You emit a
Comm.Recv_init() call with the pointer to the buffer receiving the
message (then you have to ask the object for the buffer pointer).
... Then when you initiate the communication, we should
lock the object
No, you can't rely on a buffer pointer returned earlier
Jim Jewett wrote:
Again, what is the advantage of having str(x) be redundant to repr(x)
in the case of containers?
I think you're misrepresenting the situation when you
describe it that way.
Guido didn't sit down and think "I know, let's make
str(lst) do the same as repr(lst)." He thought
"It'
Travis Oliphant wrote:
Obviously, if you
haven't provided a Py_buffer structure to fill in, then you are only
asking to lock the object's buffer from other access.
What's the use case for that? Why would you ever want
to lock an object if you don't intend to access it?
BTW, I seem to remember
Jim Jewett wrote:
PEP 3138 says that repr should start printing unicode glyphs.
I say that repr should (insetad) start recognizing when it was called
in place of __str__, and should revert back to __str__ when it
recurses down to the next level.
But we *don't* all agree that the only case whe
Blake Winton wrote:
Seriously, I can write:
>>> print 1, "1", Decimal("1")
and get as my output:
1 1 1
Yes, but you've explicitly told it to print that,
so presumably it's what you want in that case.
Equally, you need to be explicit about how you want
a list printed.
--
Greg
___
M.-A. Lemburg wrote:
AFAIK, eval(repr(obj)) is no longer a requirement... simply because
it has always only worked for a small subset of objects and in
reality, you wouldn't want to call eval() on anything too often
due to the security implications.
Yes, I actually think that sentence in the d
M.-A. Lemburg wrote:
It's being able to write
str.transform('gzip').transform('uu')
which doesn't require knowledge about the modules doing the actual
work behind the scenes.
That doesn't preclude those modules exporting their
functionality in the form of codecs having the standard
codec
paul bedaride wrote:
it's why I wonder, if this can't be good if metaclass and class
decorator have the same
interface, then we can use a class as a metaclass or as a decorator ??
That doesn't make sense -- metaclasses and class decorators
are very different things and have very different cap
Stephen J. Turnbull wrote:
Do you really think that .transform clients will really choose
'base64' when they want 'lzma'?
It depends on who the "client" is. An application popping
up a list of compression methods is just going to confuse
users if it lists "base64" as a possibility.
So it alre
Nick Coghlan wrote:
Having to mess around with __import__ just to support a "choose
compression method" configuration option would be fairly annoying.
Perhaps, but even then, I'm not sure it makes sense to
lump them all into the same namespace.
If you're choosing a compression method, it make
Terry Reedy wrote:
Would you prefer re_transform, which is English?
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".
--
Greg
___
Python-3000
Guido van Rossum wrote:
Really? Don't you think it's pretty obvious that b.transform("gzip")
compresses and b.untransform("gzip") decompresses? Or that
b.transform("base64") generates base64 format?
Well, maybe. I think the problem is that the word
"transform" is inherently direction-neutral,
Paul Moore wrote:
The key point for me is that
print(repr(arbitrary_string)) is *guaranteed* to display correctly,
even on my limited-capability terminal, precisely because it only uses
ASCII and no matter how dumb, all terminals I know of display ASCII.
That still sounds like something that th
Nick Coghlan wrote:
What this approach allows you to do is have
generic 'transformation' layers in your IO stack, so you can just build
up your IO stack as something like:
XMLParserIO('myschema')
BufferedTextIO('utf-8')
BytesTransform('gzip')
RawSocketIO
There's nothing wrong with that, but
M.-A. Lemburg wrote:
str.transform() -> str (uses the encode function of the codec)
str.untransform() -> str (uses the decode function of the codec)
Not sure I like those names. It's rather unclear which
direction is "transform" and which is "untransform".
People seem to have trouble eno
Stephen J. Turnbull wrote:
This discussion isn't about whether it could be done or not, it's
about where people expect to find such functionality. Personally, if
I can find .encode('euc-jp') on a string object, I would expect to
find .encode('gzip') on a bytes object, too.
What I'm not seeing
Wasn't there a big discussion once before about whether
encode/decode should be usable for things other than
unicode<->non-unicode transformations? I thought the
conclusion reached back then was that they shouldn't.
Is there some reason the transformations being talked
about can't just be provide
Brett Cannon wrote:
There is a general dislike in putting code in a package's __init__
module.
Why? What's the point of having an __init__.py file if
you're not allowed to put any code there?
If it's something that applies to the package as a
whole, that seems like the obvious place to put it.
Guido van Rossum wrote:
On Wed, Apr 30, 2008 at 3:49 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
So that code will silently behave as though the rest of
the sequence wasn't there some of the time?
Only if it uses LBYL.
I don't understand that. Iteration isn't the onl
Guido van Rossum wrote:
I would like to see the following:
- sq_length should return maxsize if the actual value doesn't fit
So that code will silently behave as though the rest of
the sequence wasn't there some of the time?
Can you elaborate on the rationale for this? I'm having
trouble seei
Martin v. Löwis wrote:
Still, Guido's question stands: do you have an actual use case where
you would want to stop earlier?
It just seems a bit disappointing to me that the underlying
OS has the ability to read directories an item at a time,
but this is not made available to the Python programm
Tim Heaney wrote:
Speaking of this, is it too late to lobby for an iterator version of
os.listdir? (Perhaps listdir would not be the best name. :)
There was discussion about an opendir() function a while
back that would return an iterable, but I don't think
anything came of it.
--
Greg
___
Alexander Belopolsky wrote:
On Tue, Apr 29, 2008 at 10:36 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
..
R = range(N)
for i in R:
for j in R:
You realize that in the snippet above whatever cycles you save by
creating R once, you give away by creating iter(R) twice.
I'm not so su
Alex Martelli wrote:
Is this a SWIG-specific issue (so
that SWIG can take care of it in the C code it generates or links) or
sufficiently general to warrant an addition to the Python core?
I haven't been following this closely, but if the issue is what
I think it is, Pyrex is going to have the
Travis Oliphant wrote:
My feel right now is to not do the special case at all and
actually return a memory-view object even for element access
That could be very tedious in the case where the elements
are actually bytes, though.
Maybe there should be a separate bytesview() object to
use instea
Charles Merriam wrote:
It would be great to change assert from:
assert_stmt::= "assert" expression ["," expression]
To:
assert_stmt::= "assert" expression ["as" expression]
I don't think "as" is the right word to use here...
maybe
assert else
That is, w
Nicholas T wrote:
It's obvious how to use LC's to replace map and filter, but what
about reduce?
LCs were never intended to be a replacement for reduce.
If you like reduce, why not continue to use it? I don't
think it's going away, just being moved into a different
module.
--
Greg
Alex Martelli wrote:
> LCs were originally designed to leak
Well, they weren't really *designed* to leak, it was
just a side effect of the implementation.
It seems to have been decided that it was better to
keep it that way than risk breaking things that might
depend on it. Personally I would rat
Oleg Broytmann wrote:
>When I use str(container) instead of repr(comtainer) does Python need to
> guess if I want an unambiguous representation or a printable representation
> of items? I don't think there is a room for guessing - I explicitly said
> str().
But there's no single, obvious way
Adam Olsen wrote:
> Sure, *now*, but C inherited their definition from a day when it
> wasn't so clear cut. It may be obsolete today, but good luck getting
> them to change the standard.
I'm not really expecting the standard to be changed. But
I do think it's silly for a modern C implementation
Alex Martelli wrote:
> I disagree: I always recommend using %r to display (in an error
> message, log entry, etc), a string that may be in error,
For debugging messages, yes, but not output produced
in the normal course of operation. And "File Not Found"
I consider to be in the latter category --
David Cournapeau wrote:
> Maybe everyone understands it as 8 bits, but it has always been wrong.
It may not be officially written down anywhere, but
almost everyone in the world understands a byte to mean
8 bits. When you go into a computer store and ask for
256MB of RAM, you don't expect to be a
David Cournapeau wrote:
> They are totally different concepts: byte is not a (C) type, but a unit,
> the one returned by the sizeof operator.
If a word is needed for this concept, then invent a new
one, e.g. "size unit", rather than reusing "byte", which
everyone already understands as meaning 8
Nick Coghlan wrote:
> Unfortunately, it turns out that the trick also breaks display of
> strings containing any other escape codes.
There's also the worry that it could trigger falsely
on something that happened to look like \u but
didn't originate from the repr of a unicode char.
> I'm st
Oleg Broytmann wrote:
> Traceback (most recent call last):
> File "./ttt.py", line 4, in
> open("тест") # filename is in koi8-r encoding
> IOError: [Errno 2] No such file or directory: '\xd4\xc5\xd3\xd4'
In that particular case, I'd say the IOError constructor
is doing the wrong thing -- i
Oleg Broytmann wrote:
> Do I understand it right that str(objects) calls repr() on items to
> properly quote strings? (str([1, '1']) must give "[1, '1']" as the result).
> Is it the only reason?
In the case of strings, yes. More generally, there
can be any kind of object in the list, and repr(x)
i
Martin v. Löwis wrote:
> 3.6 byte
> addressable unit of data storage large enough to hold any
> member of the basic character set of the execution
> environment
Blarg. Well, I think the wording of that part of the
standard is braindamaged. The word "byte" already has
a pre-existing m
Guido van Rossum wrote:
> The more I think about this, the more I believe that repr() should
> *not* be changed, and that instead we should give people who like to
> see '日本語' instead of '\u1234\u5678\u9abc' other tools to help
> themselves.
This seems to be a rather ASCII-centric way of thinking
Paul Moore wrote:
> If you don't
> want to change your code, write
>
> from my_repr import my_repr as repr
But repr() itself doesn't do anything -- it just
invokes the __repr__ method of its argument. So
you can't actually accomplish anything by replacing
it, unless your replacement does a lo
Terry Reedy wrote:
> import unirep
> print(*map(unirep.russian, objects))
That's okay if the objects are strings, but what about
non-string objects that contain strings?
We'd need another protocol, such as __unirep__.
--
Greg
___
Python-3000 mailing l
Nick Coghlan wrote:
> and the C standard says that sizeof(char) == 1 byte.
Does it actually use the word byte, or does it just say the
"smallest addressable unit of memory" or something?
Seems to me it can't have it both ways, without also trying
to define the meaning of "byte", which I don't th
Guido van Rossum wrote:
> A complaint about this would carry more weight when it came from
> someone who actually has to deal with the issue
It's not a complaint, just something I thought of. If
Japanese programmers aren't actually bothered by this,
then I'm not either.
> Another issue is that r
Guido van Rossum wrote:
> We'd
> need a third form (eek!) that would preserve the string quotes but be
> more lenient about non-ASCII. Personally, I think some custom loop to
> print the values is good enough.
It might not be a serious problem when most of the chars in
the string are ascii, but wh
Thomas Wouters wrote:
> I don't see the value in str(['1', 1, '1, [1]', '1]',
> '\n[1']) giving hard to understand output.
Random data point: Being forced to do some Ruby programming
recently, I found that Ruby does in fact produce just this
sort of ambiguous output when you print a list, and it'
Guido van Rossum wrote:
> Seems to be mass confusion all around. My proposal is:
>
> repr(int) ==
> str(int) == 'int'
>
> repr(C) ==
> str(c) == '__main__.C'
Can I take a step back and ask why exactly we're considering
doing this? In what use cases is the current result
of str() considered too
Terry Reedy wrote:
> Unfortunately, *any* text printed for any object *could* have been the
> value of a string object.
That's true, but it's sufficiently unlikely that a string
such as "" could have accidentally arisen some
other way that I don't lose any sleep over it. If weird
things seem to b
Adam Olsen wrote:
> Killing threads at arbitrary points really is that dangerous.
I'm not talking about killing an arbitrary thread, but
a particular thread that I've designed with the idea of
killing it in mind.
And I'm not really talking about killing it, either,
just having a way of tapping it
Guido van Rossum wrote:
> Maybe it should be a forked subprocess then, if it doesn't touch
> anything shared?
It might be taking and returning large data structures
that it would be tedious to transfer between processes.
Pickling them might not be straightforward if they
contain references to obj
Terry Reedy wrote:
> As in
>
print(type(3))
>
> int # instead of
I have the same feeling there -- the only time I'm
likely to be deliberately printing a class is for
debugging, and then I want unambiguity.
--
Greg
___
Python-3000 mailing list
Guido van Rossum wrote:
> what do people think of making the str() of a class
> return just the thing between '...' in the repr()?
Are you talking about the class itself, or instances
of the class?
If the latter, I'm not sure I like that idea. Very
often I write thing like 'print "foo =", foo' as
Marcin ‘Qrczak’ Kowalczyk wrote:
> What about lists? I guess (haven't checked) that they are made like
> tuples.
I always thought they were built one item at a time,
but I was wrong (see below). So there doesn't seem to
be much logic or consistency here at all.
>>> def f():
... x = [1,2,3]
...
Charles Merriam wrote:
> How can I write the greatest common denominator of this code:
>
> print "Hello World!" # yes, that needs to be Unicode.
Something like
from __future__ import unicode_literals
from py3k_compat import Print
Print("Hello World!") # yes, that indeed is Unicode.
g
Leif Walsh wrote:
> On Wed, Mar 26, 2008 at 7:34 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
>> x, y => x + y
>
> If something like this is adopted, I plead that := is chosen.
No, that would be massively confusing, since := is
an assignment operator in some lang
Alexander Belopolsky wrote:
> 1. Do nothing: dicts are built incrementally, and sets in batch.
> 2. Implement batch processing for dict literals.
> 3. Implement incremental processing for sets.
My thought is that sets are the odd one out here.
Tuples are created batchwise because, being immutabl
If this were ever to change, my preference would be to
find a syntax that doesn't use a keyword at all.
Lambdas are most useful when the body is extremely
short. But in those cases, the word 'lambda' itself
is nearly as long as the body, which destroys about
half the benefit of using it in the fir
Lennart Regebro wrote:
> I misunderstood you as suggesting
> that the debugger showed the orginal 2.6 code and not the the 3.0
> code.
>
> But this would more or less mean that 2to3 needs to compile the 2.6
> code directly to pyc-files, as I understand it.
Either that or Python would have to gr
Would it help if 2.6 had a __future__ import to treat
all unadorned string literals as unicode?
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/
Adam Olsen wrote:
> I'd tend to assume only *purely* functional languages should have
> asynchronous interrupts. Any imperative language with them is
> suspect.
Yet there are situations where *not* having any such thing
can be extremely inconvenient.
If I'm performing some background calculation
Aahz wrote:
> [*] General note to the list: see how I'm using both the PEP number and
> the title.
Maybe the Python-Dev list server could pass everything
through a filter that looks for "PEP " references
and inserts the PEP title after them? :-)
--
Greg
__
Martin v. Löwis wrote:
> It's currently called lib2to3,
> so I can't see why two2three would be better
I was just thinking that '2to3' wouldn't be a valid
module name. I guess 'lib2to3' works too (or 2),
and is easier 2 type 2.
--
Greg
___
Python-3000
Terry Reedy wrote:
> The fact that the '*' would be redundant in some contexts and therefore
> useless should not necessarily make it syntax error in that context.
It does allow a lone *exp to be given a special
meaning in some contexts, such as yield *exp.
Although I'm still not sure that's a go
Martin v. Löwis wrote:
> When people requested that 2to3 is a library, I think they
> have exactly that use case in mind: programmatically convert
> a source code base at deployment/build time.
For importability as a library, would it be better
to call it two2three?
--
Greg
_
Thomas Wouters wrote:
>
> [Guido] asked for 'f(*a, b, c)' to be valid, but it only makes sense
> to allow, say, 'f(*a, b, *c)' too, and he hasn't said 'no' to that.
And then, of course, people are going to want
to have multiple ** arguments, too...
--
Greg
_
Thomas Wouters wrote:
>
> On Sat, Mar 15, 2008 at 6:07 PM, Greg Ewing <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> >>>>*a, b, c = a, b, *c
>
> +0 on allowing * in other than the last position.
>
> The left-hand side o
Talin wrote:
>
> if a generator is yielding the
> entire output of another generator, it might be possible to 'cut out the
> middleman' and have the ultimate consumer of the values read the
> innermost generator directly.
On the face of things, it certainly seems as though such a thing
*ought*
Charles Merriam wrote:
> -1.
>
> While the syntax has a basic beauty, it requires too much odd explanation.
On further reflection, I think I would only be in
favour of 'yield *it' if it permitted an optimisation
allowing it to run more efficently than an explicit
for-loop.
In the absence of any
Thomas Wouters wrote:
> >>> a, b = *c
> File "", line 1
> SyntaxError: can use starred expression only as assignment target
That error message isn't really accurate, since in
> >>> a, b = (*c,)
the *c is not an assignment target.
Also, the message implies that
*c = a, b
should be valid
Guido van Rossum wrote:
> Thomas Wouters suggests some new syntax:
a, b, *c = range(5)
+1 on this.
*a, b, c = a, b, *c
+0 on allowing * in other than the last position.
> ... for it in iterables:
> ... yield *it
+0.5 (due to consistency problems pointed out in others'
comm
Thomas Wouters wrote:
>
> I do not think
> collecting a (potentially ever-growing) list of results is really the
> right thing to do, do you?
For those cases where it is, perhaps one should be
able to write
[yield *it]
and have it treated as a kind of list comprehension.
--
Greg
Anthony Tolle wrote:
> I'm wrapping an instance of
> I'm wrapping an instance of
> I'm wrapping an instance of
Hmmm, so what you're really worried about is that
people will be able to create static methods without
using staticmethod().
I think the solution to this has already been
mentioned
Nick Coghlan wrote:
> functools.partial style functionality doesn't always play well
> with methods,
I can see it not working well with *unbound* methods. Bound
methods shouldn't be any problem, since from the outside
they're called just like any other function.
But applying partial to an unboun
Anthony Tolle wrote:
> So how does wrapper1 know whether it is wrapping a static method, a
> bound method, or an unbound method? Well, one way it could do this is
> to examine the type of the descriptor it is wrapping.
No, a wrapper can't distinguish between a plain function and
an unbound metho
1 - 100 of 1067 matches
Mail list logo
