On Fri, Feb 6, 2009 at 2:47 AM, Scott Dial <scott(a)scottdial.com> wrote:
> I don't think reducing my post to "[noise]" or calling people idiots is
> at all beneficial. I'd appreciate it if you toned down the condescension
> in the future.
Ahh. I accidentally listed you as the To: recipient. I meant [noise]
to be the thread in general, not your contribution. Sorry about that.
The 'idiots' comment was meant tongue-in-cheek. Didn't mean for
anyone to take offense.
Let's everyone be happy, ok?
On 5-Feb-09, at 3:36 PM, Andre Roberge wrote:
>> Yes I agree with you that many people like colons. What bothers me
>> is that
>> some people dislike them, but not given the choice to avoid them.
>> We don't
>> like semicolons in Python, but what would stop a hard-core C users
>> to end
>> every statement with a semicolon? They have the choice.
> I have seen *very* few code samples where semi-colon were used - and
> most were by people just learning Python (and familiar with some other
> language). If it were up to me, semi-colon would not be allowed -
> again, for consistency.
Semicolons are bad but are because you'll need them sometimes for one-
liners. You can use colons too if you wish. Now the inconsistency is
that semicolons are optional but colons are required. I did not
propose to eliminate colons all together; just make them optional so
we have the choice.
>> And I would also argue that many of those like colons not because
>> really feel colons improve readability, but that they have get used
>> colons in the first place. You like colons, I don't. How do you
>> know another
>> Python user will like them or not? By making trailing colons
>> OPTIONAL, we
>> can probably have the chance to field test. If people really think
>> improve readability that much, they can still use them, just like
>> we feel
>> semicolons are line noise and void them if possible, even though we
>> CAN use
>> them. I don't think we will ever lose anything to make colons
> The emphasis for Python is improved readability (*perhaps* at the
> expense of a small extra burden when writing, i.e. when adding
> colons). I do find code more readable with colons (and have from day
> 1 when I started learning Python). Apparently you don't. But, if you
> are given the choice and write code without colons and I read it, I
> know that it will be less readable for me. So I do disagree with the
> opinion that we would would not ever lose anything by making colons
> optional. Either they stay or they are removed - don't allow both.
I agree readability counts. That's why I love Python. And that's also
why I don't like colons--they are line noise. Semicolons improve
readability; they tell you exactly where lines end (esp. in case of
line continuation), in the same way colons tell you where suites end.
What do you feel if you see a piece of Python code full of semicolons
at the end of every statement? That will probably be the same feeling
I have when facing colons at the end of every suite.
And unfortunately, we allow both for semicolons.
Le Thu, 5 Feb 2009 16:12:17 +0000,
Mark Dickinson <dickinsm(a)gmail.com> a écrit :
> On Thu, Feb 5, 2009 at 1:22 PM, spir <denis.spir(a)free.fr> wrote:
> > Hello,
> > I wonder why there is no difference in syntax between binding and rebinding. Obviously, the semantics is not at all the same, for humans as well as for the interpreter:
> > * Binding: create a name, bind a value to it.
> > * Rebinding: change the value bound to the name.
> > I see several advantages for this distinction and no drawback.
> How would you write code like:
> my_result = 
> for item in items:
> a = <some intermediate result computed from item>
> my_result.append(<something computed from a>)
> where a is bound for the first time on the first iteration
> of the loop, and rebound on all subsequent iterations?
Yes, good point!
That's probably a reason why in some languages loops create local scopes/namespaces. In which case the issue disappears, as 'a' is newly created for each iteration. An incremental value (e.g. a sum) is first defined/initialized outside the loop instead.
I takes this as different, but related, issue; because the intention and meaning here is really to have an 'a' for each iteration, matching each item. It is not a value that will evoluate along with the loop cycles, as a sum would: it is not rebinding. Conceptually, 'a' is thus a loop-local name.
Maybe a special case for loops, where such "utility short-life names" are common? Not very nice.
If "a=..." is allowed even when 'a' exists, and recreates the name, then a distinction with rebinding still holds, in the sense that explicit rebinding is possible (including in non-local scope). But we lose the side-effect of getting a NameError in case the programmer errorneously types an existing name.
la vida e estranya
la vida e estranya
I have found several posts of people (including Python commiters)
asking for the removal of name mangling in Python,
(the latest in 2006 in python-3000). I have searched in the various
mailing lists and I can't find a clear status on this.
If someone knows please let me know.
Otherwise : I would like to propose this feature to be removed because
it brakes Python philosophy imho.
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/