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
Simon Percivall wrote:
> On 5 jul 2006, at 11.40, Scott Dial wrote:
> > Guido van Rossum wrote:
> >> Would this also use ..num to refer to num in an outer scope two
> >> levels removed?
> >
> > I realize this was a wink, but it is a valid problem with the
> > "dot"-proposal.
> >
> > def foo(n):
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
__
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
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 th
Baptiste Carvello wrote:
> Terry Reedy a écrit :
> > So I propose that the context maker be called just that: 'context
> > maker'. That should pretty clearly not be the context that manages
> > the block execution.
> >
> +1 for context maker. In fact, after reading the begining of the
> thread, I
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 p
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.
>
> Al
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
___
Py
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) #
Mark Russell wrote:
> PEP 227 mentions using := as a rebinding operator, but rejects the
> idea as it would encourage the use of closures. But to me it seems
> more elegant than some special keyword, especially is it could also
> replace the "global" keyword. It doesn't handle things like
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 bla
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.
>
>
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 b
Wolfgang Lipp wrote:
> On Sat, 27 Aug 2005 12:35:30 +0200, Martin v. Löwis
<[EMAIL PROTECTED]>
> wrote:
> > P.S. Emphasis mine :-)
>
> no, emphasis all **mine** :-) just to reflect i never expected .get()
> to work that way (return an unsolicited None) -- i do consider this
> behavior harmful a
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 out
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:
>
[EMAIL PROTECTED] wrote:
> \begin{datadesc}{PY_RESOURCE}
> -The module was found as a Macintosh resource. This value can only be
> -returned on a Macintosh.
> +The module was found as a Mac OS 9 resource. This value can only be
> +returned on a Mac OS 9 or earlier Macintosh.
> \end{datadesc}
Skip Montanaro wrote:
> Just re.sub("[\r\n]+", "\n", s) and I think you're good to go.
I don't think that in general you want to fold multiple empty lines into
one. This would be my prefered regex:
s = re.sub(r"\r\n?", "\n", s)
Catches both DOS and old-style Mac line endings. Alternatively,
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
Python-Dev@pytho
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 hav
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 *
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 alternati
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
Phillip J. Eby wrote:
> At 10:09 AM 1/14/05 +0100, Just van Rossum wrote:
> >Guido van Rossum wrote:
> >
> > > Are there real-life uses of stateful adapters that would be
> > > thrown out by this requirement?
> >
> >Here are two interf
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
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
27 matches
Mail list logo
