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():
> >..val += 1
> >return val
> >
Facundo Batista wrote:
> 2006/2/25, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
>> Translating the library reference as such is more difficult, because
>> it can't be translated in small chunks very well.
>
> The SVN directory "python/dist/src/Doc/lib/" has 276 .tex's, with an
> average of 250 lines
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.
>
> There would be potential for breaking code, but I
> suspect the actual amount of breakage would be
> small,
On 2/22/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> That's what rankles people about this, I think -- there
> doesn't seem to be a good reason for treating the global
> scope so specially, given that all scopes could be
> treated uniformly if only there were an 'outer' statement.
> All the argument
Almann T. Goo wrote:
> One of the biggest points of contention to this is of course the
> backwards incompatibility with a new keyword ...
Alternatively, 'global' could be redefined to mean
what we're thinking of for 'outer'. Then there would
be no change in keywordage.
There would be potential
2006/2/25, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Translating the library reference as such is more difficult, because
> it can't be translated in small chunks very well.
The SVN directory "python/dist/src/Doc/lib/" has 276 .tex's, with an
average of 250 lines each.
Maybe manage each file inde
2006/2/25, Alex Martelli <[EMAIL PROTECTED]>:
> A similar situation applies to Italy -- a lot of stuff is translated
> at http://www.python.it/doc/Python-Docs/html/ (the C-API and
> Extending and Embedding aren't translated, though), but it's 2.3.4-
> vintage docs. There's no real mechanism or pr
Greg Ewing wrote:
> Stephen J. Turnbull wrote:
>> It's "what is the Python compiler/interpreter going
> > to think?" AFAICS, it's going to think that base64 is
> > a unicode codec.
>
> Only if it's designed that way, and I specifically
> think it shouldn't -- i.e. it should be an error
> to att
On Feb 25, 2006, at 4:43 PM, [EMAIL PROTECTED] wrote:
> Zitat von Facundo Batista <[EMAIL PROTECTED]>:
>
>> The question is, it's ok to use a third party system for this
>> initiative? Or you (we) prefer to host it in-house? Someone alredy
>> thought of this?
>
> I thought about it at one time, a
Zitat von Facundo Batista <[EMAIL PROTECTED]>:
> The question is, it's ok to use a third party system for this
> initiative? Or you (we) prefer to host it in-house? Someone alredy
> thought of this?
I thought about it at one time, and I think the doc strings can be
translated very well using gett
>> 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, and the
Guido> pstats module invoked separately prints the out
Stephen J. Turnbull wrote:
> The reason that Python source code is text is that the primary
> producers/consumers of Python source code are human beings, not
> compilers
I disagree with "primary" -- I think human and computer
use of source code have equal importance. Because of the
fact that Pyth
FWIW this has now been checked in. Enjoy!
--Guido
On 2/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/22/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> > A minor related point about on_missing():
> >
> > Haven't we learned from regrets over the .next() method of iterators
> > that
On 2/25/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> >> I just noticed that cProfile (like profile) prints to stdout. Yuck.
>
> Guido> Can you clarify? Why is it wrong to send the output of the
> Guido> profiler to stdout?
>
> If the program emits a bunch of output of its own I
>> I just noticed that cProfile (like profile) prints to stdout. Yuck.
Guido> Can you clarify? Why is it wrong to send the output of the
Guido> profiler to stdout?
If the program emits a bunch of output of its own I want to keep it separate
from what is arguably the debug output of
"Thomas Wouters" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The one open point that Aahz forwarded me, and is expressed somewhat in
> http://mail.python.org/pipermail/python-dev/2004-September/048695.html ,
> is
> the case where you have a package that you want to transparentl
After a small talk with Raymond, yesterday in the breakfast, I
proposed in PyAr the idea of start to translate the Library Reference.
You'll agree with me that this is a BIG effort. But not only big, it's dynamic!
So, we decided that we need a system that provide us the management of
the translat
On 2/25/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I just noticed that cProfile (like profile) prints to stdout. Yuck.
Can you clarify? Why is it wrong to send the output of the profiler to
stdout? It seems to make sense to me that you should be able to
redirect the profiler's output to a
On 2/25/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
> Since I implemented[*] PEP 328, Aahz suggested I take over editing the PEP,
> too, as there were some minor discussion points to add still. I haven't been
> around for the discussioons, though, and it's been a while for everone else,
> I thi
[EMAIL PROTECTED] wrote:
> Georg> Probably related:
>
> Georg> http://python.org/sf/1235266
>
> Don't think so. That was just a documentation nit (and is now fixed and
> closed at any rate).
Well, it is another module that prints to stdout instead of stderr.
Okay, not so closely relate
Georg> Probably related:
Georg> http://python.org/sf/1235266
Don't think so. That was just a documentation nit (and is now fixed and
closed at any rate).
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
[EMAIL PROTECTED] wrote:
> I just noticed that cProfile (like profile) prints to stdout. Yuck. I
> guess that's to be expected because the pstats module does the actual
> printing and it's used by both modules. I'm willing to give up backward
> compatibility to achieve a little more sanity and f
[Skip]
>I just noticed that cProfile (like profile) prints to stdout. Yuck. I
> guess that's to be expected because the pstats module does the actual
> printing and it's used by both modules. I'm willing to give up backward
> compatibility to achieve a little more sanity and flexibility here. I
On 2/25/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I just noticed that cProfile (like profile) prints to stdout. Yuck. I
> guess that's to be expected because the pstats module does the actual
> printing and it's used by both modules. I'm willing to give up backward
> compatibility to ac
I just noticed that cProfile (like profile) prints to stdout. Yuck. I
guess that's to be expected because the pstats module does the actual
printing and it's used by both modules. I'm willing to give up backward
compatibility to achieve a little more sanity and flexibility here. I
propose rewri
> "Ron" == Ron Adam <[EMAIL PROTECTED]> writes:
Ron> So, lets consider a "codec" and a "coding" as being two
Ron> different things where a codec is a character sub set of
Ron> unicode characters expressed in a native format. And a
Ron> coding is *not* a subset of the unicode c
Since I implemented[*] PEP 328, Aahz suggested I take over editing the PEP,
too, as there were some minor discussion points to add still. I haven't been
around for the discussioons, though, and it's been a while for everone else,
I think, so I'd like to rehash and ask for any other open points.
T
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> Stephen J. Turnbull wrote:
>> the kind of "text" for which Unicode was designed is normally
>> produced and consumed by people, who wll pt up w/ ll knds f
>> nnsns. Base64 decoders will not put up with the same kinds of
Zitat von Trent Mick <[EMAIL PROTECTED]>:
> Are there specific code areas in mind that would be ripped out for this
> or is this mainly to avoid having to test on and ensure new code is
> compatible with?
Primarily the non-W versions of the file system API. I think the
W9x popen support could als
29 matches
Mail list logo
