> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> Stephen J. Turnbull wrote:
>> I gave you one, MIME processing in email
Greg> If implementing a mime packer is really the only use case
Greg> for base64, then it might as well be removed from the
Greg> standard libra
The buildbot shows that the debug-build test_grammar is dying with a C
assert failure on all boxes.
In case it helps, in a Windows release build test_transformer is also failing:
test_transformer
test test_transformer failed -- Traceback (most recent call last):
File "C:\Code\python\lib\test\te
On Feb 26, 2006, at 5:43 PM, Ron Adam wrote:
...
> So far everywhere I've seen closures used, a class would work. But
> maybe not as conveniently or as fast?
Yep. In this, closures are like generators: much more convenient
than purpose-built classes, but not as general.
> Haskel sounds in
Alex Martelli wrote:
>> I'm -1 on adding the intermediate (outer) scopes to functions. I'd even
>> like to see closures gone completely, but there's probably a reason they
>> are there. What I like about functions is they are fast, clean up
>> behind themselves, and act *exactly* the same on cons
On 2/26/06, Ron Adam <[EMAIL PROTECTED]> wrote:
> I'm -1 on adding the intermediate (outer) scopes to functions. I'd even
> like to see closures gone completely, but there's probably a reason they
> are there.
We already have enclosing scopes since Python 2.1--this is PEP 227
(http://www.python.or
On Feb 26, 2006, at 4:20 PM, Ron Adam wrote:
...
> (sigh of relief) Ok, so the following example will still be true.
Yep, no danger of dynamic scoping, be certain of that.
> Maybe something explicit like:
>
import __main__ as glob
Sure, or the more general ''glob=__import__(__name__)''
Stephen J. Turnbull wrote:
> I gave you one, MIME processing in email
If implementing a mime packer is really the only use case
for base64, then it might as well be removed from the
standard library, since 99.9% of all programmers will
never touch it. Those that do will need to have boned up
Since I was on a streak of implementing not-quite-the-right-thing, I checked
in my PEP 308 implementation *with* backward compatibility -- just to spite
Guido's latest change to the PEP. It jumps through a minor hoop (two new
grammar rules) in order to be backwardly compatible, but that hoop can g
Alex Martelli wrote:
> On Feb 26, 2006, at 11:47 AM, Ron Adam wrote:
>...
>> How would you know you aren't in inadvertently masking a name in a
>> function you call?
>
> What does calling have to do with it? Nobody's proposing a move to
> (shudder) dynamic scopes, we're talking of saner conc
On 2/26/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> For the record: I detest the existing 'global' (could I change but
> ONE thing in Python, that would be the one -- move from hated
> 'global' to a decent namespace use, e.g. glob.x=23 rather than global
> x;x=23), and I'd detest a similar 'oute
> Would this apply to reading intermediate scopes without the global keyword?
Using a name from an enclosing scope without re-binding to it would
not require the "global" keyword. This actually is the case today
with "global" and accessing a name from the global scope versus
re-binding to it--thi
On Feb 26, 2006, at 11:47 AM, Ron Adam wrote:
...
> How would you know you aren't in inadvertently masking a name in a
> function you call?
What does calling have to do with it? Nobody's proposing a move to
(shudder) dynamic scopes, we're talking of saner concepts such as
lexical scopes a
At PyCon, there was general reluctance for incorporating
the ast-objects branch, primarily because people where
concerned what the reference counting would do to
maintainability, and what (potentially troublesome)
options direct exposure of AST objects would do.
OTOH, the approach of creating a sh
Terry Reedy wrote:
> "Almann T. Goo" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> On 2/26/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>>> Alternatively, 'global' could be redefined to mean
>>> what we're thinking of for 'outer'. Then there would
>>> be no change in keywordage.
>>
On 2/26/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Then do you also dislike the original proposal: that only a single dot
> be allowed, and that the '.' would mean "this name, but in the nearest
> outer scope that defines it"? Then:
>
> def incrementer_getter(val):
>def incremente
"Almann T. Goo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 2/26/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Alternatively, 'global' could be redefined to mean
>> what we're thinking of for 'outer'. Then there would
>> be no change in keywordage.
>> Given the rarity of globa
On 2/25/06, Almann T. Goo <[EMAIL PROTECTED]> wrote:
> On 2/23/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 2/22/06, Almann T. Goo <[EMAIL PROTECTED]> wrote:
> > > def incrementer_getter(val):
> > >def incrementer():
> > >val = 5
> > >def inc():
> > >
On Sun, Feb 26, 2006 at 03:27:34PM +0100, Massimiliano Leoni wrote:
> Why would you change the Python scoping rules, instead of using the
> function attributes, available from release 2.1 (PEP 232) ?
Because closures allow for data that isn't trivially reachable by the caller
(or anyone but the
On 2/25/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> >> It is currently impossible to separate profile output from the
> >> program's output.
>
> Guido> It is if you use the "advanced" use of the profiler -- the
> Guido> profiling run just saves the profiling data to a file,
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> I think we need some concrete use cases to talk about if
Greg> we're to get any further with this. Do you have any such use
Greg> cases in mind?
I gave you one, MIME processing in email, and a concrete bug that is
possible w
Why would you change the Python scoping rules, instead of using the
function attributes, available from release 2.1 (PEP 232) ?
For example, you may write:
def incgen(start, inc):
def incrementer():
incrementer.a += incrementer.b
return incrementer.a
incrementer.a = start - inc
Zitat von Georg Brandl <[EMAIL PROTECTED]>:
> Martin: There aren't any German docs, are there?
I started translating the doc strings once, but never got to complete
it. I still believe that the doc string translation is the only approach
that could work in a reasonable way - you would have to use
On Sun, 26 Feb 2006 08:50:57 +0100, Georg Brandl wrote:
> Martin: There aren't any German docs, are there?
There is e.g. http://starship.python.net/~gherman/publications/tut-de/
Kind regards,
Alexander
___
Python-Dev mailing list
Python-Dev@python.org
23 matches
Mail list logo
