[Python-ideas] Consistency in naming [was Re: ...ALL CAPS] (off-list)

[Ned Batchelder]

James, frankly, it sounds to me like you have found things you don't 
like about Python, and are frustrated that your ideas here have not been 
celebrated.  That's far from "decline."  The process for changing Python 
is fundamentally conservative, which can be frustrating.  I understand 
that.  I myself have experienced that frustration.

But claiming that Python is in decline, or that something "is the only 
real chance of having a successful Python language" is just hysteria 
that won't win over anyone.

Now you say Python isn't growing? Do you mean in features, or usage? 
Either is obviously false. Perhaps you mean that it isn't growing the 
way that you want?

There are things I would change about Python if I could, but I am not 
the BDFL, and neither are you.  Python is imperfect, because it is made 
by people, over more than 25 years, and it's got to balance competing 
demands.

It's clear that you are smart and have energy to dedicate to the future 
of Python.  I hope you find a productive way to contribute.

(Sorry for top-posting...)

--Ned.

On 2/3/19 12:34 PM, James Lu wrote:
> Python’s decline is in not growing.
>
> Sent from my iPhone
>
> On Feb 3, 2019, at 11:20 AM, Ned Batchelder <ned at nedbatchelder.com 
> <mailto:ned at nedbatchelder.com>> wrote:
>
>> James, you say below, "This kind of readability issue, datetime.now, 
>> is an example of what’s contributing to Python’s decline."
>>
>> Do you have any evidence of Python's decline?  Lots of metrics 
>> (albeit simplistic ones) point to Python growing in popularity:
>>
>>   * https://www.techrepublic.com/article/fastest-growing-programming-language-pythons-popularity-is-still-climbing/
>>   * https://www.netguru.com/blog/why-python-is-growing-so-quickly-future-trends
>>   * https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-worlds-most-popular-coding-language
>>
>> Are there indicators we are missing?
>>
>> --Ned.
>>
>> On 2/2/19 11:56 PM, James Lu wrote:
>>> Sent from my iPhone
>>>
>>>> On Feb 2, 2019, at 3:41 AM, Steven D'Aprano<steve at pearwood.info>  wrote:
>>>>
>>>>> On Sat, Feb 02, 2019 at 12:06:47AM +0100, Anders Hovmöller wrote:
>>>>>
>>>>>> - the status quo means "no change", so there is no hassle there;
>>>>> Not quite true. There is a constant hassle of "do I need to write
>>>>> datetime.datetime.now() or datetime.now()?"
>>>> My point was that there is no hassle from *making a change* if you don't
>>>> actually make a change. (There may, or may not, be other, unrelated
>>>> hassles.)
>>>>
>>>> Besides, I'm not seeing that this is any worse than any other import. Do
>>>> I call spam.Eggs.make() or Eggs.make()? If you don't remember what you
>>>> imported, the names don't make much difference.
>>>>
>>>> I accept that datetime.datetime reads a bit funny and is a bit annoying.
>>>> If we had the keys to the time machine and could go back a decade to
>>>> version 3.0, or even further back to 1.5 or whenever the datetime module
>>>> was first created, it would be nice to change it so that the class was
>>>> DateTime. But changing it *now* is not free, it has real, serious costs
>>>> which are probably greater than the benefit gained.
>>> Why can’t we put “now” as a property of the module itself, reccomend that, and formally deprecate but never actually remove datetime.datetime.now?
>>>>> I solved this at work by changing all imports to follow the "from
>>>>> datetime import datetime" pattern and hard banning the other
>>>>> statically in CI. But before that people suffered for years.
>>>> Oh how they must have suffered *wink*
>>>>
>>>> I'm surprised that you don't do this:
>>>>
>>>> from datetime import datetime as DateTime
>>>>
>>>>
>>>>> I have a colleague who likes to point that the future is longer than
>>>>> the past. It's important to keep that perspective.
>>>> Actually, no, on average, the projected lifespan of technologies,
>>>> companies and cultural memes is about the same as their current age. It
>>>> might last less, or it might last more, but the statistical expectation
>>>> is about the same as the current age. So on average, "the future" is
>>>> about the same as "the past".
>>>>
>>>> Python has been around not quite 30 years now, so we can expect that it
>>>> will probably last another 30 years. But chances are not good that it
>>>> will be around in 300 years.
>>> A big reason why projects last as long as you say they last is that the maintainers get un-ambitious, they get used to relaxing in the language they know so well, they are no longer keen on change.
>>>
>>> This kind of readability issue, datetime.now, is an example of what’s contributing to Python’s decline.
>>>
>>> Bottom line: if someone submits a PR for this, will anyone merge it?
>>>> -- 
>>>> Steve
>>>> _______________________________________________
>>>> Python-ideas mailing list
>>>> Python-ideas at python.org
>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>> Code of Conduct:http://python.org/psf/codeofconduct/
>>> _______________________________________________
>>> Python-ideas mailing list
>>> Python-ideas at python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct:http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190203/70ed4468/attachment-0001.html>