| [ Raymond Hettinger ]:
| > If someone really cared about the double lookup, they could
| > flatten a level by starting their modules with:
| >
| >from __builtin__ import *
| >
| > However, we don't see people writing this kind of code. That
| > could mean that the double lookup has
On Thu, 05 May 2005 14:58:02 +0200
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I haven't followed the PEP 340 discussion in detail,
> but as the PEP doesn't list keywords that have been
> considered and rejected, I'd like to propose my own:
> use "after" instead of "block":
>
> after opening("
[ Reinhold Birkenfeld ]:
> Well, with it you could create suites with _any_ introducing
> identifier. Consider:
>
> with:
> (...)
>
> synchronized:
> (...)
>
> try:
> (...)
>
> transaction:
> (...)
>
>
> Do you understand my concern?
I definetely see your point. However,...
[ Shane Hathaway ]:
> I'd like to suggest a small language enhancement that would fix this
> example. Allow the break and continue statements to use a keyword,
> either "for" or "while", to state that the code should break out of both
> the block statement and the innermost "for" or "while" statem
[ Senra ]:
> > [ Guido ]:
> > > 1. Decide on a keyword to use, if any.
> >
> > Shouldn't be the other way around ?
> > Decide to use *no* keyword, if that could be avoided.
[ Reinhold ]:
> There is one problem with using no keyword: You cannot use arbitrary
> expressions
> in the new statem
[ Guido ]:
> Nice one. Should be a piece of cake to implement. Please talk to
> [EMAIL PROTECTED] about getting it checked into the PEP database.
>
> I'm +1 on accepting this now -- anybody against?
+1
Last week, while I was giving a Python course (in Rio de Janeiro-Brazil)
some students attempt
[ Guido ]:
> 1. Decide on a keyword to use, if any.
Shouldn't be the other way around ?
Decide to use *no* keyword, if that could be avoided.
In my large inexperience *no keyword* is much better (if feasible):
1) No name conflicts with previous code: block, blocktemplate, whatever
2)
[ Michael Walter ]:
> A couple of examples out of my tired head (solely from a user perspective) :-)
>
> Embedding domain specific language (ex.: state machine):
> ...
>
> Embedding domain specific language (ex.: markup language):
> ...
>
> Embedding domain-specific language (ex.: badly-designed
[ Simon Percivall ]:
> [ Terry Reedy ]:
> > with as :
> >
> > would parallel the for-statement header and read smoother to me.
> >
> > for as :
> >
> > would not need new keyword, but would require close reading to
> > distinguish
> > 'as' from 'in'.
>
> But it also moves the value to the righ
| > On Thu, Mar 24, 2005 at 11:36:41AM -0300, Rodrigo Dias Arruda Senra wrote:
| > > Edit libwebbrowser.tex as you see fit, then send it to me
| > > and I'll TeXify it back to you.
| >
| >Uploaded to http://python.org/sf/754022 . I am not a native English
|
On Thu, 24 Mar 2005 17:13:30 +0300
Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 24, 2005 at 11:11:11AM -0300, Rodrigo Dias Arruda Senra wrote:
> > However, if you could make the necessary changes to the documentation,
>
>I'll try, but certainly
On Thu, 24 Mar 2005 16:30:35 +0300
Oleg Broytmann <[EMAIL PROTECTED]> wrote:
>I've reworked the patch once more. I moved some common functionality
> into the UnixBrowser class and added two new features ...
I do not want to abuse your generosity.
However, if you could make the necessary chang
On Wed, 23 Mar 2005 21:29:30 +0300
Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> Suggested resolutions:
> http://python.org/sf/754022
>Review and apply! ;)
Reviewed.
Thank you Oleg, fine integration job.
I added a +1 comment to the tracker and copied
your remaining obs to 754022 history.
So a
[Rod Senra]:
> > Under some linux distros (I'm positive for some Mdk releases), Mozilla is
> > compiled dumping a lot of info to stdout/stderr. Since one of the goals of
> > webbrowser is to give the end-user a stress-free experience, there goes the
> > mentioned nullification .
[Oleg Broytmann]:
On Wed, 23 Mar 2005 15:40:20 +0300
Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> Hello!
>
>While I'm working on webbrowser...
Great.
> Why do all graphical browsers are called with their stdout/stderr redirected
> to /dev/null?
Under some linux distros (I'm positive for some Mdk releases),
Hi,
I propose a small change in webbrowse.py module.
At the present time:
"""
Under Unix, if the environment variable BROWSER exists, it is
interpreted to override the platform default list of browsers,...
"""
(extract from Python-2.4/Doc/html/lib/module-webbrowser.html)
I propose the following c
[ Pierre Barbier de Reuille ]:
They are called "sometrue" and "alltrue" ... IMHO, it explicits more
what it means :
alltrue(i<5 for i in l)
sometrue(i<5 for i in l)
+1
[ from a comment in GvR's blog ]
> > Why not,
> > if True in (x > 42 for x in S):
> > instead of "any" and why not
> > if not
[Evan Jones] :
--
2. Every N memory operations (or some other measurement of "time"),
reset this value and calculate a moving average of the number of pages.
This estimates the current memory requirements of the application.
> The challenge is how to determine a good measurement of "t
Evan Jones wrote:
This message is a follow up to a thread I started on python-dev back in
October, archived here:
First, there is slightly more overhead with programs that allocate a lot
of memory, release it, then reallocate it.
Summary of the changes:
- When freeing a page, if the arena is co
[ Guido van Rossum <[EMAIL PROTECTED]> ]
---
| One thing that bugs me: the article says 3 or 4 times that Python is
| slow, each time with a refutation ("but it's so flexible", "but it's
| fast enough") but still, they sure seem to harp on the point.
20 matches
Mail list logo
