Re: [Python-Dev] Adding a conditional expression in Py3.0
On Saturday 2005-09-24 04:21, Terry Reedy wrote: > Never wrote a single line, and may have not read one (in DDJ? Byte?) for > 15-20 years. How do *you* read such C? Cond 'Qmark' ? I seldom have to read C code aloud, and the ?: operator is rare-ish; but I would suggest reading a?b:c as "a chooses b else c" or (shaving a syllable) "a gives b else c" or something like that. Or, ploddingly but unambiguously, "a query b colon c". > Now, can you honestly say that you would (naively) read > > return foo if bar else baz > > and be certain you knew what it meant? I can't imagine *actually* reading it as if "foo" were the condition. But I can imagine reading it, to begin with, as if it were a Perlish conditionalized statement: "(return foo) if bar else ... aw heck, that can't be right". Which is probably benign but slows down comprehension. -- g ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Trasvesal thought on syntax features
I don't remember where I read (here around probably) that having a "client pluggable" syntax was not good for python because then ,and more blah blah.I believed it was a rule of the thumb.. But ,when a client programmer like me writes code he tries to give a clean, unambigous interface/syntax for a possible under user.Having a fixed set of keywords and not overridable syntactic sugar is just a limit.Once a sound set of unittest is written with documentation, every useful library would add its keywords. What I start thinking reading here is that if you let redefine, instead: 1) print statement :I will redefine it like now , no matter if python 3.0 is not selling it any more in the language 2) on A take B or C: How ever and whatever one would like to write, this expression could be definable, ending all the pathetic blah blah (hope not to offend) Thanks for jour job anyway. Paolino ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] IMPORTANT: release24-maint branch is FROZEN from 2005-09-28 00:00 UTC for 2.4.2
So here we go - the release24-maint branch will be frozen from midnight UTC on Wednesday the 28th (about 36 hours from now). This is to cut 2.4.2 (final). If you have any pending patches you want to see landed on the branch, mail me about them - and do it soon! There's been a bunch of fixes since 2.4.2c1, but nothing that I judge making it worthwhile doing a 2.4.2c2. I'm open to other opinions here, of course. Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IMPORTANT: release24-maint branch is FROZEN from 2005-09-28 00:00 UTC for 2.4.2
On Mon, Sep 26, 2005, Anthony Baxter wrote: > > So here we go - the release24-maint branch will be frozen from > midnight UTC on Wednesday the 28th (about 36 hours from now). This is > to cut 2.4.2 (final). > > If you have any pending patches you want to see landed on the branch, > mail me about them - and do it soon! > > There's been a bunch of fixes since 2.4.2c1, but nothing that I judge > making it worthwhile doing a 2.4.2c2. I'm open to other opinions > here, of course. After my experience doing weekly code rollouts for the past year, I'm somewhere between +0 and +1 on doing another release candidate. OTOH, doing a brownbag 2.4.3 won't kill us, and few people will use a release candidate instead of waiting. Still your call. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 350: Codetags
Micah Elliott <[EMAIL PROTECTED]> wrote: > ``FIXME (XXX, DEBUG, BROKEN, REFACTOR, REFACT, RFCTR, OOPS, SMELL, NEEDSWORK, > INSPECT)`` >*Fix me*: Areas of problematic or ugly code needing refactoring or >cleanup. I think the standard should not have codetags that are synonyms. This is Python and there should be only one way to do it. One problem with synonyms is that they makes it harder to search using tools like grep. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
