le is loaded, its source code
has long since been compiled into code objects.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of US
le, when you write
while expr:
...
it gets turned into
expr.__while__(thunk)
etc.
No, I'm not really serious about this -- it was just
a wild thought!
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZeal
statement, for example.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
[EMAIL
l the necessary information about both scopes
available.
Although it might be better to have some sort of
"outer" declaration for rebinding in the enclosing
scope, instead of doing it on a whole-function basis.
--
Greg Ewing, Computer Science Dept, +--+
uido was saying that it's important for them to
know that mutable objects are never in danger of being
shared, so you should at least tell them that much.
Otherwise they may end up worrying unnecessarily that
two of their lists might get shared somehow behind
their back.
--
Greg Ewi
on Windows
running under Virtual PC mounting the source directory
from the host system as a file share, and it turns out
that reading a unix symlink from the Windows end just
returns the contents of the link. Aaarrghh! Braindamage!
--
Greg Ewing, Computer Science Dept, +--
Neil Schemenauer wrote:
The translation of a block-statement could become:
itr = EXPR1
arg = None
while True:
try:
VAR1 = next(itr, arg)
except StopIteration:
break
try:
arg = None
Guido van Rossum wrote:
And surely you exaggerate. How about this then:
The with-statement is similar to the for-loop. Until you've
learned about the differences in detail, the only time you should
write a with-statement is when the documentation for the function
you are calling s
Elegant as the idea behind PEP 340 is, I can't shake
the feeling that it's an abuse of generators. It seems
to go to a lot of trouble and complication so you
can write a generator and pretend it's a function
taking a block argument.
I'd like to reconsider a thunk implementation. It
would be a lot s
. Cells
slow down access somewhat compared to regular local variables.
True, but is the difference all that great? It's
just one more C-level indirection, isn't it?
we'll want variables
*assigned to* by the thunk also to be shared with the containing
function,
Agreed. We'd
Nick Coghlan wrote:
With an appropriate utility block manager
I've just thought of another potential name for them:
Block Utilization and Management Function (BUMF) :-)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citiz
Neil Schemenauer wrote:
A variation on this with somewhat different semantics swaps the keywords:
in EXPR for VAR:
BLOCK
Looks weird to my eyes.
Probably makes perfect sense if you're Dutch, though. :-)
--
Greg Ewing, Computer Science
xplain the meanings
of those particular uses, and leave the full general
explanation as an advanced topic.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wh
e of a for-loop. This is
going to give people the wrong idea altogether.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA
tement.
struct opening(foo) as f:
...
Then we could confuse both C *and* Ruby programmers at
the same time! :-)
[No, I don't really mean this. I actually prefer "block"
to this.]
--
Greg Ewing, Computer Science Dept, +--+
Universit
7; (i.e. it is not
> terminated early due to an exception, a break statement or a return
> statement)
I've always thought that was a particularly unintuitive use
of the word 'else', and I'm not sure I'd like it to be
extende
to get lots of finger exercise typing redundant
keywords, I'd program in COBOL. :-)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned s
y!
class Frobbing:
def __neg__(self):
begin_frobbing()
try:
yield
finally:
end_frobbing()
frobbing = Frobbing()
...
-frobbing:
do_something()
--
Greg Ewing, Computer Science Dept, +--+
University o
y out there which
take function arguments could *already* be used with
a thunk-based block statement, without needing to be
re-written at all.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
C
g these
user-defined statements look even more like the native
ones.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand |
rator propagates the Break exception back out,
the block statement should break any enclosing loop.
If the iterator wants to behave like a loop, it can
catch the Break exception and raise StopIteration
instead.
--
Greg Ewing, Computer Science Dept, +--+
Universi
y extends as far as it *doesn't*
require anything beyond existing syntax and semantics.
If new syntax and tricky new interactions with iterators
are needed to support it, it doesn't seem so elegant
any more.
--
Greg Ewing, Computer Science Dept, +--+
U
Nick Coghlan wrote:
> Something relatively nonsensical, but usefully mnemonic
> (like 'stmt') may be a good way to go.
How about 'do'?
do opening(filename) as f:
...
do locking(obj):
...
do carefully(): # :-)
...
--
Greg Ew
gt; trying to understand the source code, having break depend
> on something defined somewhere completely else seems like
> an obstacle to easy understanding. IMHO, of course.
>
> //Simon
>
--
Greg Ewing, Computer Science Dept, +--+
o *not* retain existing PEP 340 semantics if uncaught,
i.e. break an enclosing loop rather than just terminate
the block statement.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurc
some people might find it useful for indenting a block
of code for cosmetic reasons, although that could easily
be seen as an abuse...
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christ
give you block iterators implemented by generators.
This makes a lot more sense to me than trying to
warp the iterator protocol to make it into a block
protocol as well. Let's keep the two things orthogonal.
--
Greg Ewing, Computer Science Dept, +--+
Univ
Ron Adam wrote:
> There seems to be some confusion as to weather or
> not 'for's will do finalizing. So I was trying to stress I think
> regular 'for' loops should not finalize. They should probably give an
> error if an object with an try-finally in them or an __exit__ method.
But if the for
Nick Coghlan wrote:
> "Loop on this iterator and finalise when done" would be written:
>
>for item in itr:
>process(item)
>finally:
>pass
This is approaching things from the wrong end. The user of
an iterator shouldn't need to know or care whether it
requires finalization
particular screw, and this isn't a problem.
But I don't have a big crowd of people looking
over my shoulder while I work, all trying to figure
out why I chose one particular screwdriver over
another, and decide which would be the best
screwdriver to use on
If implemented properly,
it could be as simple as testing whether a slot of a
type object is populated during processing of the
bytecode which causes exit from the loop.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of New
the right
statement.
For backwards compatibility, the existing for-loop
would work for partial iteration of old iterators,
but this usage would be deprecated.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen
d" idiom.
I'm inclined to agree. Anything more elaborate than
breaking from a single place in the immediately
enclosing loop tends to be getting into the realm
of spaghetti, in my experience. Giving people named
loops would be tantamount almost to giving them
a go
he's not wrong, and due to the way things are
coded, the reference happens to hang around a little
longer than strictly needed.
If garbage collection were sufficient, we'd be relying
on it to close our files in the first place, and this
whole thread would never have gotten sta
Guido van Rossum wrote:
> Now it would make more sense to change the syntax to
>
> with EXPR as VAR:
> BLOCK
>
> and we have Phillip Eby's proposal.
Change the 'with' to 'do' and I'd be +1
ecorator
What about giving them an __exit__ method if and only
if they have a yield inside a try/finally? Old generators
won't be doing that, because it's currently illegal.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
n this case?
Or do you think return (and break and continue) should
be disallowed in a finally?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | whol
are in some very old library modules.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc
; attribute set to
> None if not a chained exception).
Instead of an 'args' attribute, I'd suggest that
the constructor take keyword arguments and store
them in corresponding attributes. Then interested
parties could retrieve them by name instead of
having to remember their positio
Guido van Rossum wrote:
> - Greg Ewing (I believe) wants 'do' instead of 'with' for the
> keyword. I think I like 'with' better, especially combining it with
> Benji's proposal. IMO this reads better with 'with' than with 'do':
line)
To anyone with a Lisp or funcional background, that
looks like nothing more than a local variable
binding.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand
Guido van Rossum wrote:
> So then the all-important question I want to pose is: do we like the
> idea of using a (degenerate, decorated) generator as a "template" for
> the do-statement enough to accept the slightly increased complexity?
I can't see how this has anything to do with whether
a gener
Here's my vote on things at the moment:
+1 on
do EXPR as VAR:
...
+1 on keeping the EXPR and VAR distinct.
+1 on keeping the do and generator protocols distinct.
+1 on not going out of our way to let the controller
catch exceptions or alter control flow. Let's keep it
as simple as we c
u want
to do 'with' it, e.g. you have a pathname and you want
to open a file. I've already argued against giving file
objects __enter__ and __exit__ methods. And I'm -42 on
giving them to strings. :-)
--
Greg Ewing, Computer Science Dept, +--+
Guido van Rossum wrote:
>>Also, one question: will the "do protocol" be added to built-in "resource"
>>types? That is, locks, files, sockets, and so on?
>
> One person proposed that and it was shot down by Greg Ewing. I think
> it's better to requ
ety of possible errors.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA In
method *does*
return a canvas, with __enter__ and __exit__
methods, and the rule that you have to use the
appropriate protocol before you can use it. This
would avoid most of the aforementioned problems.
So I think I may have just talked myself out of
e
> existing "open" builtin would suffice:
>
>with open(filename, "rb") as f:
>for line in f:
>print line
I think I'm starting to agree. Currently about +0.6 in
favour of 'with' now, especially if this is to be
almost
lity constraints.
E.g. it seems we can't make for-loops work the way
they should in the face of generator finalisation
or we break old code.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a
blem, the difference would be even
smaller.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned
Ron Adam wrote:
> He should also be able to put try excepts before the yield, and after
> the yield, or in the block. (But not surrounding the yield, I think.)
I was given to understand that yield is currently
allowed in try-except, just not try-finally. So
this would require a non-backwards-com
Aahz wrote:
> On Fri, May 13, 2005, Greg Ewing wrote:
>
>>Instead of an 'args' attribute, I'd suggest that the constructor take
>>keyword arguments and store them in corresponding attributes.
>
> Sounds reasonable, but it should be equally easy to ha
t an exception if you try to re-use one.
I still think it's conceptually cleaner if the object
you use to access the resource is created by the
__enter__ method rather than being something pre-
existing, but I'm willing to concede that PBP here.
--
Greg Ewing, Computer Science Dept, +--
Nick Coghlan wrote:
>the_stmt = EXPR1
>stmt_enter = getattr(the_stmt, "__enter__", None)
>stmt_exit = getattr(the_stmt, "__exit__", None)
>
>if stmt_enter is None:
>VAR1 = the_stmt
>else:
>VAR1 = stmt_enter()
If we're doing this, it might be better if VAR were
Guido van Rossum wrote:
> Unfortunately I can't quite decide whether either rule applies in the
> case of exceptions.
I think you'd at least be justified in using the "magic" rule,
since they're set by the exception machinery.
Greg
___
Python-Dev mail
Nick Coghlan wrote:
> Paul Moore wrote:
>
>>On 5/17/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>
>>>Previously Belaboured Point? (Just guessing from context here, but if I'm
>>>right,
>>>that's one acronym I'm going to have to remember. . .)
>>
>>Practicality Beats Purity, surely...?
>
>
> D'
k to the
throw, something would try to put the same frame in the
traceback twice, which can't work since it's a linked
list.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christch
ion of new-style generators,
there could be a new statement
for var from expr:
...
or maybe just a wrapper function
for var in partial(expr):
...
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of Ne
figure user code except for
> the explicit purpose of introspection). So I think the PEP should
> continue to use __traceback__ etc.
I was just thinking the same thing myself!
(Does Guido have a telepathy machine now, as well
as a time machine?)
--
Greg Ewing
Other than that, all this looks good.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
[EMAI
. Even if D(whatever)
didn't ignore the context settings, you'd get the same
oddity if the numbers came from somewhere else with a
different precision.
I'm very uncomfortable about the whole idea of a
context-dependent precision. It just seems to be
asking for trouble.
--
G
Raymond Hettinger wrote:
>>From the mists of Argentina, a Palidan set things right. The literal
> 1.1 became representable and throughout the land the monster was
> believed to have been slain.
I don't understand. Isn't the monster going to pop
right back up again as soon as anyone does any
arit
levant, because digits in
a character string are not "digits of a decimal value"
according to what we are meaning by "decimal value"
(i.e. an instance of Decimal). In other words, this
principle only applies *after* we have constructed a
Decimal instance.
--
Greg Ewing, Computer
Raymond Hettinger wrote:
> Did you see Mike Cowlishaw's posting where he described why he took our
> current position (wysiwig input) in the spec, in Java's BigDecimal, and
> in Rexx's numeric model?
Yes, it appears that you have channeled him correctly
on that point, and Tim hasn't. :-)
But I al
Guido van Rossum wrote:
> So (a) would have my preference.
Mine, too.
> the PEP would have to be amended to state that
> VAR must be a single variable or a list of variables IN PARENTHESES.
+1
--
Greg Ewing, Computer Science Dept, +--+
Univ
es data:
out.write(data)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of
Smith wrote:
> computing the bin boundaries for a histogram
> where bins are a width of 0.1:
>
for i in range(20):
> ... if (i*.1==i/10.)<>(nice(i*.1)==nice(i/10.)):
> ... print i,repr(i*.1),repr(i/10.),i*.1,i/10.
I don't see how that has any relevance to the way bin boundaries
would be
Guido van Rossum wrote:
> I also wonder if having a b"..." literal would just add more confusion
> -- bytes are not characters, but b"..." makes it appear as if they
> are.
I'm inclined to agree. Bytes objects are more likely to be used
for things which are *not* characters -- if they're characte
Guido van Rossum wrote:
> There's also the consideration for APIs that, informally, accept
> either a string or a sequence of objects.
My preference these days is not to design APIs that
way. It's never necessary and it avoids a lot of
problems.
Greg
_
Barry Warsaw wrote:
> This makes me think I want an unsigned byte type, which b[0] would
> return.
Come to think of it, this is something I don't
remember seeing discussed. I've been thinking
that bytes[i] would return an integer, but is
the intention that it would return another bytes
object?
t just do 'setup.py install' directly?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a mo
o it cross-
platform, that's a very good reason to prefer using eggs
over a platform-specific package format.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand
I think the association of "open" with "file" is
established strongly enough in programmers' brains that
dropping it now would just lead to unnecessary confusion.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
str-used-as-bytes.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
y how to *encode*
characters into the bytes object. If you want to be able
to specify how to *decode* a str argument as well, you'd
need a third argument.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post merid
at a
bug in the application.
Likewise, the user should be able to put it anywhere on
the HD, not just the Applications folder.
Also I consider the need for a dmg in the first place
to be a bug in the Web. :-) (You should be able to just
directly download the .app file.)
This sort of thing i
o be more robust
than one which scatters files far and wide and then
relies on some elaborate bookkeeping system to try
to make sure things don't step on each other's toes.
When everything goes right, I don't care either. But
things go wrong often enough to make me care about
unnece
cs.streamdecoder(encoding, openbinary(filename))
Having codecs be stream filters might be a good idea
anyway, since then you could use them to wrap anything
that can be treated as a stream of bytes (sockets,
some custom object in your program, etc.), you
could create pipelines of encoders and decod
Ron Adam wrote:
> My first impression and thoughts were: (and seems incorrect now)
>
> bytes(object) -> byte sequence of objects value
>
> Basically a "memory dump" of objects value.
As I understand the current intentions, this is correct.
The bytes constructor would have two different s
Fred L. Drake, Jr. wrote:
> The proper response in this case is often to re-start decoding
> with the correct encoding, since some of the data extracted so far may have
> been decoded incorrectly.
If the protocol has been sensibly designed, that shouldn't
happen, since everything up to the codi
Brett Cannon wrote:
> One protects us from ending up with an unusable AST since
> the seralization can keep the original AST around and if the version
> passed back in from Python code is junk it can be tossed and the
> original version used.
I don't understand why this is an issue. If Python code
Ron Adam wrote:
> I was presuming it would be done in C code and it will just need a
> pointer to the first byte, memchr(), and then read n bytes directly into
> a new memory range via memcpy().
If the object supports the buffer interface, it can be
done that way. But if not, it would seem to
Smith wrote:
> The problem with areclose(), however, is that it
> only solves one part of the problem that needs to be solved
> if two fp's *are* going to be compared: if you are going to
> check if a < b you would need to do something like
>
> not areclose(a,b) and a < b
No, no, no.
If
openbytes?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
[E
ainers for data.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
[EMAI
/write) and all other stuff (readlines, text codecs,
etc.) implemented as wrappers around it.
To be compatible with that model, opentext() etc.
need to be factory functions returning the appropriate
stack of objects. As such they shouldn't be class
methods of any type.
--
G
Jason Orendorff wrote:
> Also the pseudo-encodings ('hex',
> 'rot13', 'zip', 'uu', etc.) generally scare me.
I think these will have to cease being implemented as
encodings in 3.0. They should really never have been
in the first
y, if you were insane enough
to turn that option on.)
> ...anyway this is getting seriously OT for python-dev. :)
Agreed. I will say no more about it here.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Ca
Josiah Carlson wrote:
> They may not be encodings of _unicode_ data,
But if they're not encodings of unicode data, what
business do they have being available through
someunicodestring.encode(...)?
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Brett Cannon wrote:
> If the compiler was hacked on by more people I would agree with this.
> But few people do
This has the potential to be a self-perpetuating situation.
There may be few people hacking on it now, but more people
may want to in the future. Those people may look at the
funky cod
Guido van Rossum wrote:
> The first, required, argument to the
> constructor should be the default value.
I'd like to suggest that this argument be a function
for creating default values, rather than an actual
default value. This would avoid any confusion over
exactly how the default value is copi
Martin v. Löwis wrote:
>>Another thought -- what is going to happen to os.open?
>>Will it change to return bytes, or will there be a new
>>os.openbytes?
>
> Nit-pickingly: os.open will continue to return integers.
Sorry, what I meant was will os.read return bytes.
Greg
_
Stephen J. Turnbull wrote:
>>"Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
> Guido> - b = bytes(t, enc); t = text(b, enc)
>
> +1 The coding conversion operation has always felt like a constructor
> to me, and in this particular usage that's exactly what it is. I
> prefer the n
Would people perhaps feel better if defaultdict
*wasn't* a subclass of dict, but a distinct mapping
type of its own? That would make it clearer that it's
not meant to be a drop-in replacement for a dict
in arbitrary contexts.
Greg
___
Python-Dev mailing
Bengt Richter wrote:
> My guess is that realistically default_factory will be used
> to make clean code for filling a dict, and then turning the factory
> off if it's to be passed into unknown contexts.
This suggests that maybe the autodict behaviour shouldn't
be part of the dict itself, but prov
Guido van Rossum wrote:
> I see two alternatives.
Have you considered the third alternative that's been
mentioned -- a wrapper?
The issue of __contains__ etc. could be sidestepped by
not giving the wrapper a __contains__ method at all.
If you want to do an 'in' test you do it on the
underlying d
Brett Cannon wrote:
> While #3 is my preferred solution as well, it does pose a Liskov
> violation if this is a direct dict subclass
I'm not sure we should be too worried about that.
Inheritance in Python has always been more about
implementation than interface, so Liskov doesn't
really apply in
Delaney, Timothy (Tim) wrote:
> However, *because* Python uses duck typing, I tend to feel that
> subclasses in Python *should* be drop-in replacements.
Duck-typing means that the only reliable way to
assess whether two types are sufficiently compatible
for some purpose is to consult the document
Ron Adam wrote:
> Storing byte information as 16 or 32 bits ints could take up a rather
> lot of memory in some cases.
I don't quite see the point here. Inside a bytes object,
they would be stored 1 byte per byte. Nobody is suggesting
that they would take up more than that just because
a_bytes_o
Ron Adam wrote:
> Storing byte information as 16 or 32 bits ints could take up a rather
> lot of memory in some cases.
I don't quite see the point here. Inside a bytes object,
they would be stored 1 byte per byte. Nobody is suggesting
that they would take up more than that just because
a_bytes_o
1901 - 2000 of 2443 matches
Mail list logo
