Evan Simpson wrote:
I'd like to toss one more variant into the mix. If we really need to
address variables in an intermediate scope, the most explicit way
that I can think of doing so is to write (using Philip's example):
def counter(num):
scope as outer # outer is an arbitrary
Guido van Rossum wrote:
On 7/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Did you also consider and reject:
* Alternate binding operators (e.g. :=, .=, etc.)
Brr.
That's too bad :(
I still find a rebinding operator (:= being my favorite) much, *much*
more appealing than any of the
Guido van Rossum wrote:
Hallo broer! :-)
Yo :)
I wonder what this should mean then:
def outer():
def inner():
x := 1
What is x's scope?
UnboundVariableError: variable 'x' referenced before assignment
Or a SyntaxError if the compiler can detect it.
Also, a := operator allows
Marek Baczek Baczyñski wrote:
I suggest - as an assignment operator instead of := - it's used in
OCaml and it looks *very* different, yet still makes sense.
Except it's currently valid Python syntax:
x = 0
x - 42
False
Just
___
Wolfgang Langner wrote:
what about trac:
http://www.edgewall.com/trac/
It is based on python and has a very good svn integration.
We started using it recently and so far it's working really well. I love
the svn (and wiki!) integration. However, I have no idea how well it
scales to a
Greg Ewing wrote:
Barry Warsaw wrote:
One possible approach is to revert BaseException out of Py2.5,
re-position KeyboardInterrupt, and add Error as an alias for
StandardError. Then we can encourage people to start using Error
as the base classes for their own errors.
Also maybe
Phillip J. Eby wrote:
I think this is a reasonable implementation limit on dynamicity,
Absolutely.
although to be conservative I think we should only do this with -O in
Python 2.5, if we do it at all.
Or with a __future__ directive?
Just
___
Ron Adam wrote:
Josiah Carlson wrote:
Greg Ewing [EMAIL PROTECTED] wrote:
u = unicode(b)
u = unicode(b, 'utf8')
b = bytes['utf8'](u)
u = unicode['base64'](b) # encoding
b = bytes(u, 'base64') # decoding
u2 = unicode['piglatin'](u1) # encoding
u1 =
Guido van Rossum wrote:
If bytes support the buffer interface, we get another interesting
issue -- regular expressions over bytes. Brr.
We already have that:
import re, array
re.search('\2', array.array('B', [1, 2, 3, 4])).group()
array('B', [2])
Not sure whether to blame array
Guido van Rossum wrote:
what will
``open(filename).read()`` return ?
Since you didn't specify an open mode, it'll open it as a text file
using some default encoding (or perhaps it can guess the encoding from
file metadata -- this is all OS specific). So it'll return a string.
If you
Wolfgang Lipp wrote:
Just because you don't read the documentation and guessed wrong
d.get() needs to be removed?!?
no, not removed... never said that.
Fair enough, you proposed to remove the behavior. Not sure how that's
all that much less bad, though...
implied). the reason of being
Phillip J. Eby wrote:
At 03:45 PM 6/27/2005 -0500, Skip Montanaro wrote:
We're getting enough discussion about various aspects of Jason's
path module that perhaps a PEP is warranted. All this discussion on
python-dev is just going to get lost.
AFAICT, the only unresolved issue outstanding
Terry Reedy wrote:
J. David Ibanez [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Given that the behavior of hasattr is clearly defined in Lib Manual
2.1 as equivalent to
def hasattr(obj, name):
try:
getattr(obj, name)
return True
except:
return False
Phillip J. Eby wrote:
Heh. As long as you're going to continue the electrical metaphor,
why not just call them transformers and appliances? [ ... ]
Next we'll see Appliance-Oriented Programming ;-)
Just
___
Python-Dev mailing list
Phillip J. Eby wrote:
At 07:02 PM 1/14/05 -0500, Glyph Lefkowitz wrote:
For the sake of argument, let's say that SegmentPen is a C type,
which does not have a __dict__, and that PointPen is a Python
adapter for it, in a different project.
There are multiple implementation alternatives
Phillip J. Eby wrote:
It's not at all clear to me that sticky behavior is the best
default behavior, even with implicit adoptation. Would anyone in
their right mind expect the following to return [0, 1, 2, 3, 4, 5]
instead of [0, 1, 2, 0, 1, 2]?
from itertools import *
seq =
Phillip J. Eby wrote:
But it _does_ perform an implicit adaptation, via PyObject_GetIter.
First, that's not implicit. Second, it's not adaptation, either.
PyObject_GetIter invokes the '__iter__' method of its target -- a
method that is part of the *iterable* interface. It has to have
Guido van Rossum wrote:
Are there real-life uses of stateful adapters that would be thrown out
by this requirement?
Here are two interfaces we're using in a project:
http://just.letterror.com/ltrwiki/PenProtocol (aka SegmentPen)
http://just.letterror.com/ltrwiki/PointPen
They're both
Phillip J. Eby wrote:
For example, if there were a weak reference dictionary mapping
objects to their (stateful) adapters, then adapt() could always
return the same adapter instance for a given source object, thus
guaranteeing a single state.
Wouldn't that tie the lifetime of the adapter
Skip Montanaro wrote:
Michael This must be one of those cases where I am mislead by my
Michael background... I thought of Liskov substitution principle
Michael as a piece of basic CS background that everyone learned
Michael in school (or from the net, or wherever they
20 matches
Mail list logo
