Re: [Python-Dev] PEP 340 -- loose ends
[ 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) ':' is already a block (broader sense) indication 3) Improved readbility: from PEP 340 def locking_opening(lock, filename, mode=r): block locking(lock): block opening(filename) as f: yield f from PEP 340 def locking_opening(lock, filename, mode=r): locking(lock): opening(filename) as f: yield f 4) Better to make the language parser more complex than the language exposed to end-users Following the PEP and this thread, it seems to me that __no keyword__ is less preferable than __some keyword__(=='block' so far), and I wonder why is not the reverse. Perhaps I missed something ? Besides, I think this solves many issues AOP was trying to tackle in a much cleaner, elegant -- therefore pythonic -- way. Outstanding. best regards, Senra -- Rodrigo Senra -- MSc Computer Engineerrodsenra(at)gpr.com.br GPr Sistemas Ltdahttp://www.gpr.com.br/ Personal Blog http://rodsenra.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Unifying try-except and try-finally
[ 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 attempted to use try/except/finally blocks. I had to dig the grammar to prove to them that it was __not already__ supported. cheers, Senra -- Rodrigo Senra -- MSc Computer Engineerrodsenra(at)gpr.com.br GPr Sistemas Ltdahttp://www.gpr.com.br/ Personal Blog http://rodsenra.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defmacro (was: Anonymous blocks)
[ 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 database table): ... ..., which might actually prove someone's point that the language designer shouldn't allow people to do such things. The whole macros issue comes to a tradeoff between power+expressiviness X readability. IMVHO, macros are readability assassins. The power (for any developer) to introduce new syntax is *not* a desirable feature, but something to be avoided. And that alone should be a stronger argument than a hundred use cases. cheers, Senra -- Rodrigo Senra -- MSc Computer Engineerrodsenra(at)gpr.com.br GPr Sistemas Ltdahttp://www.gpr.com.br/ Personal Blog http://rodsenra.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: anonymous blocks
[ Simon Percivall ]: [ Terry Reedy ]: with target as value: would parallel the for-statement header and read smoother to me. for target as value: would not need new keyword, but would require close reading to distinguish 'as' from 'in'. But it also moves the value to the right, removing focus. Wouldn't from be a good keyword to overload here? in/with/for/ value from target: BODY I do not have strong feelings about this issue, but for completeness sake... Mixing both suggestions: from target as value: BODY That resembles an import statement which some may consider good (syntax/keyword reuse) or very bad (confusion?, value focus). cheers, Senra -- Rodrigo Senra -- MSc Computer Engineerrodsenra(at)gpr.com.br GPr Sistemas Ltdahttp://www.gpr.com.br/ Personal Blog http://rodsenra.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: webbrowser.py
| 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. wink | | Uploaded to http://python.org/sf/754022 . I am not a native English | speaker, and this is the first time I've edited a TeX file. Please | correct my grammar, spelling, TeX, whatever... Outstanding work Oleg. I read it through and wouldn't change a bit. I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok regarding grammar, TeX and ... whatever wink. I recommend to apply both files. However, I would withdraw the third file -- webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org best regards, Senra -- ,_ | ) Rodrigo Senra rsenra |at| acm.org |(__ --- _((|__|] GPr Sistemas http://www.gpr.com.br _ |(|___|] IC - Unicamp http://www.ic.unicamp.br/~921234 ___(|__|] L___(|_|]--- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: webbrowser.py
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 changes to the documentation, since it will be easier to you than anyone else right know, I'll gladly check the consistency between code and docs. tchau, Senra -- Rodrigo Senra rsenra _at_ acm _dot_ org http://www.ic.unicamp.br/~921234 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: webbrowser.py
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 not in TeX format... Edit libwebbrowser.tex as you see fit, then send it to me and I'll TeXify it back to you. wink tchau, Rod -- Rodrigo Senra MSc Computer Engineer [EMAIL PROTECTED] GPr Sistemas Ltda http://www.gpr.com.br ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: webbrowser.py
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 commiter-dev just have to mind about 754022. I also added elinks support - currently it is very similar to links, but I am going to extend its remote capabilities. (Yes, that small text-mode broswer supports remoting, windows and tabs! Who'd think?!.) Also I'm going to add new-tab support similar to new-window for Mozilla/Firefox and elinks. Excellent. cheers, Rod Senra ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
[ Pierre Barbier de Reuille ]: They are called sometrue and alltrue ... IMHO, it explicits more what it means : alltrue(i5 for i in l) sometrue(i5 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 False in (x 42 for x in S): instead of all? Because any and all have shortcut semantics (they return as soon as they can determine the final result). [ Guido ]: -- See my blog: http://www.artima.com/forums/flat.jsp?forum=106thread=98196 Do we even need a PEP ? In the absence of a PEP, soon will see in c.l.p discussions like: For completeness sake shouldn't there be a optimiztion version for nonetrue() ? def nonetrue(S): for x in S: if x: return False return True why not allfalse() ? Due to the previous use of sometrue(), guess it becomes easier to remeber nonetrue() than allfalse(). One may argue for aliasing(nonetrue, allfalse), and we are back to _builtin pollution_. So, people might fallback to any() and all(),realising that: '''not all()''' meaning somefalse() '''not any()''' meaning nonetrue()==allfalse() All I'm saying: +1 for the PEP. OFF-TOPIC: It is curious though that we choose to read an *implicit* True in [all(), any()] instead of an implicit False. I guess that is a moral or ethical choice coming from the Human realm, favouring Truth instead of Falsity. But that difference does not hold in the Boolean realm wink. best regards, Senra -- Rodrigo Senra MSc Computer Engineer [EMAIL PROTECTED] GPr Sistemas Ltda http://www.gpr.com.br ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improving the Python Memory Allocator
[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 time. Ideally, if the application was idle for a while, you would perform some housekeeping like this. Does Python's cyclic garbage collector currently do this? If so, I could hook this management stuff on to its calls to gc.collect() IMVHO, any measurement of time chosen would hurt performance of non-memory greedy applications. OTOH, makes sense for the developers of memory greedy applications (they should be aware of it wink) to call gc.collect() periodically. Therefore, *hooking* gc.collect() sounds about right to me, let the janitoring pace be defined by those who really care about it. Looking forward to see this evolve, Senra -- Rodrigo Senra MSc Computer Engineer [EMAIL PROTECTED] GPr Sistemas Ltda http://www.gpr.com.br ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
