Re: Old Man Yells At Cloud

[Rick Johnson]

Steve D'Aprano wrote:
> Paul Rubin wrote:
> > Steve D'Aprano writes:
> > > Having to spend a few hours being paid to migrate code
> > > using "print x" to "print(x)", or even a few months, is
> > > not a life-changing experience.
> > 
> > Didn't someone further up the thread mention some company
> > that had spent 1.5 years porting a py2 codebase to py3?
> 
> Its possible, but if so I missed it.  And did I mention one
> of the coders at the company I work, who decided to port
> our Python 2 code base to Python 3? He stayed behind one
> night after hours and did it in three hours. We've been
> talking about it for about two years.  What are we to make
> of anecdotes like these? Apart from the possibility that
> one, or the other, or both, is an exaggeration or lie[1]?

Your personal experience at one (small) company is hardly
relevant. And do you really expect this fine community to
belief, that Steven D'Aprano, yes, the man who's had a
hard-on for Python3 long before it was ever publically
released, has not been writing Python2.x code using
backported future feature for years? So why should this fine
community be surprised that your migration took roughly the
same amount of time that it took for Gilligan and his
cohorts to be stranded on an island? 

Just sit right back and you'll hear a tale
a tale of a some fateful "schmit",
that began with feature request,
one that floated his tiny ship.

The code monkey was a mighty patchin' man,
the BDFL brave and sure,
a handful of sycophants set sail that day,
for a three hour tour,
a three hour tour...

The patching started getting rough,
and compatibility would be lost.
And if not for the courage of the fearless crew
the erection would be lost.
The erection would be lost...

So this is the tale of our castaways,
here for a long long time.
They'll have to make the best of things,
as evangelism is an uphill climb. :-(

The first mate and his Skipper too,
will do their very best,
to make the others comf'terble,
in their Python-ideas-island nest.

No print statement, no rights, no tolerance,
not a single luxury,
like a north korean prison state
it's as tyrannical as can be.

So join us here each week my friends,
you're sure to get a smile,
from all the perverted castaways
here on Python3's fantasy Isle!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Paul Moore]

On 23 September 2017 at 12:37, Steve D'Aprano
 wrote:
> 95% of Python is unchanged from Python 2 to 3. 95% of the remaining is a 
> trivial
> renaming or other change which can be mechanically translated using a tool 
> like
> 2to3. Only the remaining 5% of 5% is actually tricky to migrate. If your code
> base is full of things relying on that 5% of 5%, then you'll struggle.
> Otherwise, is probably much easier than people expect.

And in my experience, one of the worst difficulties is the transition
to "clean" Unicode handling. I've seen many Python 2 codebases that
mostly-work, either by assuming often-but-not-always-true things like
"Everyone uses UTF-8", or "subprocesses always use the same encoding
as my code" and then introduce "fixes" by tactical re-encoding rather
than redesigning the code to "decode at the boundaries" - because it's
quicker to do so, and everyone has deadlines.

In those cases, the Python 3 transition can be hard, not because
there's a lot of complexity to writing Python 3 compatible code, but
because Python 3 has a stricter separation between bytes and (Unicode)
strings, and doesn't support sloppy practices that Python 2 lets you
get away with. You *can* write Unicode-clean code in Python 2 (and
then the transition is easy) but many people don't, and that's when
things get difficult. The worst cases here are people who know how to
write good Unicode-safe code, and do so in Python 2, but using a
different approach than the one Python 3 takes. Those people put
effort into writing correct code, and then have to change that, *just*
for the transition - they don't get the correctness benefit that
others do.

(I should also point out that writing Unicode-safe code is hard, from
a *design* perspective, because an awful lot of data comes to you
without a known encoding - text files, for example, or the output of a
subprocess. Sometimes you *have* to guess, or make assumptions, and
Python 3 tends to force you to make those assumptions explicit.
Ironically, it's often the better coders that find this hard, as they
are the ones who worry about error handling, or configuration options,
rather than just picking a value and moving on).

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Steve D'Aprano]

On Fri, 22 Sep 2017 04:05 pm, Paul Rubin wrote:

> Steve D'Aprano  writes:
>> Having to spend a few hours being paid to migrate code using "print x"
>> to "print(x)", or even a few months, is not a life-changing experience.
> 
> Didn't someone further up the thread mention some company that had spent
> 1.5 years porting a py2 codebase to py3?

Its possible, but if so I missed it.

And did I mention one of the coders at the company I work, who decided to port
our Python 2 code base to Python 3? He stayed behind one night after hours and
did it in three hours. We've been talking about it for about two years.

What are we to make of anecdotes like these? Apart from the possibility that
one, or the other, or both, is an exaggeration or lie[1]?

- perhaps one code base is bigger than the other;

- perhaps one is an unspeakable mess, and the other is nice clean code;

- perhaps one has masses of unit tests while the other barely even works;

- perhaps one company has good coders and the other has terrible coders;

- perhaps it was 1.5 years elapsed time, ten days effort (I've worked
  with people like that).

Who can say?

95% of Python is unchanged from Python 2 to 3. 95% of the remaining is a trivial
renaming or other change which can be mechanically translated using a tool like
2to3. Only the remaining 5% of 5% is actually tricky to migrate. If your code
base is full of things relying on that 5% of 5%, then you'll struggle.
Otherwise, is probably much easier than people expect.




[1] I admit it: mine was an exaggeration. It actually took him four hours.

-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Paul Rubin]

Steve D'Aprano  writes:
> Having to spend a few hours being paid to migrate code using "print x"
> to "print(x)", or even a few months, is not a life-changing experience.

Didn't someone further up the thread mention some company that had spent
1.5 years porting a py2 codebase to py3?

The issue of breaking the print statement isn't the difficulty of
converting old programs, or that the print statement is superior to the
print function or vice versa.  Reasonable people might believe that one
is slightly better than the other, but it would be hard to argue that
one is overwhelmingly better than the other.  So there's not a
convincing reason to change.

That calls the whole py3 movement into question, since its advocates so
vigorously defend unnecessary changes.  It's fine to fix broken stuff
(Unicode was broken, indexes escaping list comprehensions was broken)
but fixing highly visible stuff that wasn't broken makes the more subtle
changes easier to ignore.

Py3 imo would have been more successful if it introduced even more
breakage, but produced dramatic benefits (for example a 10x speedup) as
a result.  That would have been doable.  Instead we got minor benefits
and useless breakage.  Py4 as a result of learning the wrong lesson
won't break anything, so it won't be able to introduce dramatic benefits
either.  Will the 5th time (Py5) be the charm?  (I don't mean Pycharm).

Python is gaining ground in numerics and data science, which is great.
Micropython for embedded MCUs is also poised for popularity.  I don't
know how Python is doing at general systems stuff which is what I mostly
use it for.  I think Ruby is losing ground, and some of the ground it
has lost has been to Elixir.  An Elixir-like reimplementation of Python
might be an interesting avenue to pursue.  So would a dialect with less
pervasive dynamism than Python, but that could be compiled to fast
machine code with traditional Lisp techniques.  The dynamism would still
be available "opt-in" so you could turn it on when you wanted it, and
only those parts of your program would slow down.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Steve D'Aprano]

On Fri, 22 Sep 2017 02:00 pm, Rick Johnson wrote:

> I think it's grossly unfair to label those who's lives
> have been up-ended by the backwards incompatible changes of
> Python3 as "haters". 

Nobody, not one person, has ever had their life upended by Python 3.

People have their lives upended by war, by disease, by serious injury, by
natural disasters. They have their lives upended by losing their home to the
bank, or in an earthquake, or a hurricane. They have their lives upended by
cancer, by bombs, by serious car accidents, by floods and fires.

Having to spend a few hours being paid to migrate code using "print x"
to "print(x)", or even a few months, is not a life-changing experience.


> Most of these people did not want or 
> even need these changes, 

If they didn't want somebody else making the decision, they should have invented
their own language and used that instead.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Rick Johnson]

On Thursday, September 21, 2017 at 10:12:25 AM UTC-5, Steve D'Aprano wrote:
> [...]
> And remember that the Python core developers feel your pain
> too. They had to migrate a large code base (the Python std
> library) from 2 to 3. They had to write the 2to3
> translator. And they have to maintain two independent code
> bases, 2 and 3, in parallel, for a decade or more, and put
> up with thousands of internet haters going on and on and on
> and on about "Python 3 is destroying Python", year after
> year after year.
I think it's grossly unfair to label those who's lives
have been up-ended by the backwards incompatible changes of
Python3 as "haters". Most of these people did not want or
even need these changes, and they were just happy to be
using a language that was intuitive, productive and did not
distract them from solving whatever problem happened to need
solving at the moment.

Sure, i think all the changes are great (except for type
hints, and i'm withholding my judgment of async for the time
being...), and had these changes been a part of the original
language, Python would have been a better language for it.

Personally, i will not decide whether or not to migrate
until Python4, and i suspect i am not alone in this regard.
And if Py-dev feels betrayed by the community, well, they
should understand that we feel betrayed as well. We have
invested decades into this language, and to have our
investments ruined by changes we did not ask for is
devastating.

So, can we overcome this devastation?

Possibly.

But Py-dev needs to understand that breaking backwards
compatibility is no small thing, and they also need to
understand that alienating the Python2.X'ers is not helping
the migration to Python3. I assure you, this community
cannot endure another one of these "engineered natural
disasters".

One of the reasons we've been so loyal to Python, is that, at
least historically, we had faith in GvR's judgments. And
while his fabled time machine has saved our bums on more
than one occasion, these days, some of us are not so sure of
our capitan's navigational abilities, and are feeling a bit
like we are the unlucky passengers on the Titanic. Speaking
personally here, i know i could have overcome the backwards
incompatible thing _eventually_, but Python3, followed by
the introduction of type-hints has been such a earth
shattering 1-2-punch, that i'm really struggling to stay on
my feet at this point.

I mean, i guess i could delude myself and imagine that type-
hints don't exist, but that's about as realistic as ignoring
a giant dent in the side of my beautiful car. Sure, the car
drives just fine, but the ugly dent sours the experience.
:-(


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Chris Angelico]

On Fri, Sep 22, 2017 at 3:07 AM, Rhodri James  wrote:
> On 21/09/17 17:31, Chris Angelico wrote:
>>
>> For a good while, I was in the same position. But instead of massively
>> rewriting everything, all I did was to adjust the material to use
>> Py2/Py3 compatible syntax. Adding parens around your print calls won't
>> stop it from being Py2-compatible, and it means that the shift to Py3
>> becomes a lot easier.
>
>
> It's compatible syntax, but it doesn't half look weird in Py2.
>
 x=2
 print("x is", x)
> ('x is', 2)

>
> is very unfriendly to young beginners.  We did consider it, but decided it
> was a non-starter; it was less effort to ignore Py3 entirely.

True, it's only identical if you do the formatting explicitly:

print("x is %s" % x)

But that does happen to be a very common case.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Rhodri James]

On 21/09/17 17:31, Chris Angelico wrote:

For a good while, I was in the same position. But instead of massively
rewriting everything, all I did was to adjust the material to use
Py2/Py3 compatible syntax. Adding parens around your print calls won't
stop it from being Py2-compatible, and it means that the shift to Py3
becomes a lot easier.


It's compatible syntax, but it doesn't half look weird in Py2.

>>> x=2
>>> print("x is", x)
('x is', 2)
>>>

is very unfriendly to young beginners.  We did consider it, but decided 
it was a non-starter; it was less effort to ignore Py3 entirely.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Chris Angelico]

On Fri, Sep 22, 2017 at 1:59 AM, Rhodri James  wrote:
> On 21/09/17 16:12, Steve D'Aprano wrote:
>>
>> On Thu, 21 Sep 2017 08:19 pm, Rhodri James wrote:
>>
>>> (That's basically my gripe against print becoming a function in Python3.
>>>It makes a lot of sense as has already been pointed out, but it breaks
>>> every beginners tutorial.)
>>
>> Nobody made that decision lightly. It wasn't a spur of the moment
>> decision,
>> Guido didn't wake up one morning and say "Hey, how about we break a whole
>> lot
>> of the Python ecosystem for giggles!" You can't fix mistakes without
>> breaking
>> things that depend on those mistakes.
>
>
> Oh, I don't doubt it, and Python3 is the better for it.  It's just that my
> major use for Python at the time was teaching a summer course for 12-15 year
> olds, and switching to Python3 would have involved rewriting almost every
> worksheet we had.  So we didn't.
>
> (Looking at the worksheet sources on Github, the course still hasn't made
> the switch!)

For a good while, I was in the same position. But instead of massively
rewriting everything, all I did was to adjust the material to use
Py2/Py3 compatible syntax. Adding parens around your print calls won't
stop it from being Py2-compatible, and it means that the shift to Py3
becomes a lot easier. A handful of other minor changes here and there
(using the explicit // operator when floor division was important, or
ensuring that obsolete syntax wasn't used), and the course was solidly
in the 2-3 compatibility range. No cost to Py2 compatibility, and the
work could be done progressively.

Teaching people to put parens around their prints won't hurt them, and
might help them. It wasn't hard for us, because all our course
material is online; if you're working with printed worksheets, you may
end up with two versions going around (which would cause confusion -
"why does this have brackets and that not?"), so it could just be left
until there's edits being made for other reasons. Still, it can be on
the list of "if you're making changes, do this", like fixing typos or
spelling errors.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Rhodri James]

On 21/09/17 16:12, Steve D'Aprano wrote:

On Thu, 21 Sep 2017 08:19 pm, Rhodri James wrote:


(That's basically my gripe against print becoming a function in Python3.
   It makes a lot of sense as has already been pointed out, but it breaks
every beginners tutorial.)

Nobody made that decision lightly. It wasn't a spur of the moment decision,
Guido didn't wake up one morning and say "Hey, how about we break a whole lot
of the Python ecosystem for giggles!" You can't fix mistakes without breaking
things that depend on those mistakes.


Oh, I don't doubt it, and Python3 is the better for it.  It's just that 
my major use for Python at the time was teaching a summer course for 
12-15 year olds, and switching to Python3 would have involved rewriting 
almost every worksheet we had.  So we didn't.


(Looking at the worksheet sources on Github, the course still hasn't 
made the switch!)


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Steve D'Aprano]

On Thu, 21 Sep 2017 08:19 pm, Rhodri James wrote:

> (That's basically my gripe against print becoming a function in Python3.
>   It makes a lot of sense as has already been pointed out, but it breaks
> every beginners tutorial.)

Nobody made that decision lightly. It wasn't a spur of the moment decision,
Guido didn't wake up one morning and say "Hey, how about we break a whole lot
of the Python ecosystem for giggles!" You can't fix mistakes without breaking
things that depend on those mistakes.

That's why a whole lot of backward-incompatible changes were queued up to 
all happen at once, to minimize the disruption:

- clean up the naming of the standard library;

- make strings proper text rather than bytes;

- fix print and exec;

- get rid of the old, error-prone "except Error, name" syntax;

- get rid of dangerous input and rename raw_input;

- make map and zip iterators;

- get rid of redundant range and rename xrange;

- make dict.keys, items and values views, instead of having three 
  sets of methods (lists, views and iterators);

- get rid of the confusing bytes.encode and str.decode methods;

and any others I missed.

If you think the transition from 2 to 3 was painful, you should consider how it
would have been to introduce all those backward incompatible changes in dribs
and drabs over 2.4, 2.5, 2.6, 2.7 and beyond.

The alternative would be to *not* remove the old versions, and just keep all the
old cruft and obsolete code hanging around forever.

And remember that the Python core developers feel your pain too. They had to
migrate a large code base (the Python std library) from 2 to 3. They had to
write the 2to3 translator. And they have to maintain two independent code
bases, 2 and 3, in parallel, for a decade or more, and put up with thousands of
internet haters going on and on and on and on about "Python 3 is destroying
Python", year after year after year.

They were willing to do all this because they were looking at the long-term
health of the Python language, not just the immediate situation.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Rhodri James]

On 19/09/17 19:31, bartc wrote:

Can't you get around all those with things like sys.stdout.write?

If so, what was the point of having a discrete print statement/function 
at all?


Simplicity.  It is much easier to explain to a beginner that

print("Wombats are go!")

will write something to the console rather than expecting them to 
remember the incantation


import sys
sys.stdout.write("Wombats are go!\n")

(That's basically my gripe against print becoming a function in Python3. 
 It makes a lot of sense as has already been pointed out, but it breaks 
every beginners tutorial.)


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Pavol Lisy]

On 9/20/17, Steve D'Aprano  wrote:
> On Wed, 20 Sep 2017 02:55 pm, Pavol Lisy wrote:

Thanks Steve, I agree with most of your mail and really appreciate
interesting reading! :)

> (a) "you save one character (two keystrokes)"; and

First I have to admit that I forgot space! But if we like to be
pedantic (what I am not sure) then we compare  vs  so 1 vs 4 , right? So not two keystrokes but three?

> print ', '.join(str(obj) for obj in (foo, bar, baz))  # 52 chars
> # and builds up a potentially large string ahead of time

> print(foo, bar, baz, sep=', ')  # 30 chars
> # and DOESN'T build up a large string ahead of time
> # and is self-explanatory

I am totally on your side here! Just forgive me next:

print(f"{foo}, {bar}, {baz}")  # 29 :P

>> 3. "for sake of saving one character"? Could we really simplify
>> motivation of opposite side to just this? (what about breaking old
>> code?)
>
> I don't know what the motivation of the "print should be a statement!" side
> is,
> because they never say why it was better. (If they have said, I have never
> seen
> it.)

I am not sure if links below could bring a little light to this, but
probably it could be interesting:

Julia has print and println functions but has also printf macro. About
motivation why not function you could read here ->
https://stackoverflow.com/questions/19783030/in-julia-why-is-printf-a-macro-instead-of-a-function#19784718
and update of view is IMHO worth to read too ->
https://github.com/JuliaLang/julia/pull/11941#issuecomment-129966921
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Grant Edwards]

On 2017-09-19, Stefan Ram  wrote:
> Chris Angelico  writes:
>>On Wed, Sep 20, 2017 at 4:59 AM, Stefan Ram  wrote:
>>>I don't get this. For example, the contractual payment (cost) is
>>>47.21
>>>, the other party hands over
>>>50.25
>>>. Now I am supposed to add /what/ to the cost?
>>Start at the smallest end. You need to make 21 cents up to 25. So hand
>>back four pennies.
>
>   Yes, but to know this ("four") I have to do a /subtraction/:
>
>   25 - 21 = 4.

No, you don't.  You start at "21" and hand out pennies while counting
up to "25".

-- 
Grant Edwards   grant.b.edwardsYow! ... I have read the
  at   INSTRUCTIONS ...
  gmail.com

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Ben Bacarisse]

bartc  writes:

> Value-Added-Tax in the UK increased from 17.5% to 20%, ...

When it was 17.5% you could shock people not in the know by working it
out in your head since it's much simpler than it sounds: take a tenth,
halve it, halve it again, and add all three.

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Steve D'Aprano]

On Thu, 21 Sep 2017 01:06 am, Dennis Lee Bieber wrote:

> On Wed, 20 Sep 2017 10:08:18 +1000, Steve D'Aprano
>  declaimed the following:
> 
>>For what its worth: from Python 3.5 (I think) onwards the error you get is
>>customized:
>>
>>py> print 1
>>  File "", line 1
>>print 1
>>  ^
>>SyntaxError: Missing parentheses in call to 'print'
>>
> 
> So... "print" (the function") is still a special case for the
> interpreter...


One of Python's weaknesses is that many error messages are fairly obscure and
uninformative, and the devs are trying to fix that. If that means treating some
things as "special cases", so be it, because practicality beats purity.

But yes, print is specifically a special case because of its history in Python
2. And for exactly the same reason, exec() is also special-cased:

py> exec '1'
  File "", line 1
exec '1'
   ^
SyntaxError: Missing parentheses in call to 'exec'



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Thomas Jollans]

On 2017-09-19 16:30, D'Arcy Cain wrote:
> On 09/19/2017 06:46 AM, Larry Martell wrote:
>> True story - the other day I was in a store and my total was $10.12. I
> 
> One time I was at a cash with three or four items which were taxable.
> The cashier rung each one up and hit the total button.  She turned to me
> and said something like "$23.42 please."  She was surprised to see that
> I was already standing there with $23.42 in my hand.  "How did you do
> that" she asked.  She must have thought it was a magic trick.
> 

God I hate shopping in the US. There you are, adding up the prices on
the products you pick up, figuring out (approximately) how much you'll
owe, you go to pay, and the next thing you know there's some unspecified
(!) markup added to the price.

D'Arcy, I'm with the cashier. You're clearly a witch (or warlock).



-- 
Thomas Jollans
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Thomas Jollans]

On 2017-09-20 17:06, Dennis Lee Bieber wrote:
> On Wed, 20 Sep 2017 10:08:18 +1000, Steve D'Aprano
>  declaimed the following:
> 
>> For what its worth: from Python 3.5 (I think) onwards the error you get is
>> customized:
>>
>> py> print 1
>>  File "", line 1
>>print 1
>>  ^
>> SyntaxError: Missing parentheses in call to 'print'
>>
> 
>   So... "print" (the function") is still a special case for the
> interpreter...
> 

Thankfully just the interpreter, and not you or me.

Also, print is not alone in this regard:

Python 3.6.0 |Continuum Analytics, Inc.| (default, Dec 23 2016, 12:22:00)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print 1
  File "", line 1
print 1
  ^
SyntaxError: Missing parentheses in call to 'print'
>>> exec 'print 1'
  File "", line 1
exec 'print 1'
 ^
SyntaxError: Missing parentheses in call to 'exec'
>>> exec('print 1')
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1
print 1
  ^
SyntaxError: Missing parentheses in call to 'print'
>>>




-- 
Thomas Jollans
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Chris Angelico]

On Thu, Sep 21, 2017 at 1:06 AM, Dennis Lee Bieber
 wrote:
> On Wed, 20 Sep 2017 10:08:18 +1000, Steve D'Aprano
>  declaimed the following:
>
>>For what its worth: from Python 3.5 (I think) onwards the error you get is
>>customized:
>>
>>py> print 1
>>  File "", line 1
>>print 1
>>  ^
>>SyntaxError: Missing parentheses in call to 'print'
>>
>
> So... "print" (the function") is still a special case for the
> interpreter...

Yes, because of all the people migrating from Python 2. If print had
never been a statement, this special case wouldn't have been needed.
And it's only a special case in the handling of one specific exception
- at the point where you would otherwise get a generic error, it
checks to see if it could possibly be a Py2 print statement, and if
so, adjusts the text of the exception.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Steve D'Aprano]

On Wed, 20 Sep 2017 02:55 pm, Pavol Lisy wrote:

> On 9/19/17, Steve D'Aprano  wrote:
> 
> [...]
> 
>> The point is, we all make the occasional silly error. Doesn't mean we should
>> cripple our functions and fill the language with special cases like the
>> print
>> statement to avoid such rare errors. If print had always been a function,
>> and
>> someone suggested making it a statement, who would be willing to accept all
>> those disadvantages for the sake of saving one character?
> 
> I am not going to support print as a statement in this discussion!
> 
> But what you are describing is some kind of alternative history which
> did not happen.

Right. The philosophical term is "counterfactual", the more common term
is "hypothetical situation".

https://en.wikipedia.org/wiki/Counterfactual_conditional

It is sometimes called the historical subjunctive, after the subjunctive
grammatical tense:

https://www.goodreads.com/quotes/606824-it-s-subjunctive-history-you-know-the-subjunctive-the-mood-used

See also:

https://en.wikipedia.org/wiki/Subjunctive_possibility


> Question was not about crippling function to statement. (Which function?)
> 
> What I mean is that if we like to convince people that it was good
> decision then we need to use proper arguments.

The hypothetical question is a good argument. We want Python to be the language
it could possible be. Which would give us a better language?

1. Start with print statement, and change to print function. (This is what
really happened.)

2. Start with a print function, and change to a print statement. (This is a
hypothetical situation.)

I think that number 1 is *much better* than two.

Now consider that we already live in world number 1. print is now a function. To
anyone who argues that print was better as a statement, would you like to live
in world 2? Its not too late. We could say that the change in 1 was a terrible
mistake, and revert it, and then number 2 will be the actual world.

To make that come true, all you need do is make a strong enough argument for why
the print statement is *so much better* than the function that it is worth the
disruption of changing the language again.

But I'd be satisfied with any reason at all with the statement was better, apart
from:

(a) "you save one character (two keystrokes)"; and

(b) "that's what I was used to".


 
> For example some others which seems like not so proper to me:
> 
> 1. "learn-unlearn" argument could be viewed differently from opposite
> camp (they need to unlearn statement)

Beginners and novices don't have to unlearn the print statement, because they
haven't learned it yet.

A beginner to Python hasn't learned anything yet. They start to learn the
language, and discover that `len` needs parentheses. `int` needs parens. `str`
needs parens. `math.sqrt` needs parens. `chr` needs parens. `open` needs
parens. `str.find` needs parens. Dozens upon dozens, hundreds, even thousands
of functions and methods all need parens.

Except for `print`, which looks like a function but isn't.

So for `print`, they need to unlearn the rule "always use parentheses when
calling a function" and replace it with "except for print", or "but print is
not a function, so the rule doesn't apply". Either way, print is an exception
that has to be unlearned from the general rule.

I agree, once you have learned that print is special, then moving to Python 3
means you have to unlearn that print is special. Its not special any more in
Python 3.


> 2. "print foo" save more than one character ("print foo ," more than
> two characters)

Count the characters more closely:

print foo  # nine characters, including the space
print(foo)  # ten characters, including the parentheses

The difference between ten and nine is one, as I said.


Suppressing the newline at the end is a little shorter:

print foo,  #  ten characters
print(foo, end='')  # eighteen characters

but the loss of brevity is more than made up for by the gain in self-documenting
code.

Changing the separator between items is a big win for the print function:

print ', '.join(str(obj) for obj in (foo, bar, baz))  # 52 chars
# and builds up a potentially large string ahead of time

print(foo, bar, baz, sep=', ')  # 30 chars 
# and DOESN'T build up a large string ahead of time
# and is self-explanatory



> 3. "for sake of saving one character"? Could we really simplify
> motivation of opposite side to just this? (what about breaking old
> code?)

I don't know what the motivation of the "print should be a statement!" side is,
because they never say why it was better. (If they have said, I have never seen
it.) All they do is say "it was a terrible mistake to change, print was better
as a statement".

I *completely agree* that there was some pain in breaking backwards
compatibility. That's why Guido waited so many years before fixing his mistake
in making print a statement.

"print is a statement" was in Guido's list of regrets all the way back 

Re: Old Man Yells At Cloud

[Chris Angelico]

On Wed, Sep 20, 2017 at 4:01 PM, Steven D'Aprano
 wrote:
> The other reserved words are either:
>
> - values, like None, which can be included in expressions;
>
> - operators, like `is`, `or`, and `not`;
>
> - block statements, like `for x in seq` or `while flag` which
>   require a block;
>
> - statements, like `import` and `del`, which operate on names
>   rather than values.
>
> (Did I miss any?)
>
>
> print is the only one which could be a function, and looks like a
> function (apart from the lack of parens).

I'd add one additional variant that could be a function, and that's
'del' when used on something other than a simple name:

>>> del values[2]

Conceptually, this is very similar to values.pop(2), only it doesn't
return the value.

But for its simple-name form, where it reverses the effect of
assignment to a simple name, it has to be a statement.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Steven D'Aprano]

On Tue, 19 Sep 2017 18:43:43 -0700, Rick Johnson wrote:

> On Tuesday, September 19, 2017 at 12:55:14 PM UTC-5, Chris Angelico
> wrote:
>> On Wed, Sep 20, 2017 at 3:44 AM, Stefan Ram 
>> wrote:
>> > Steve D'Aprano  did *not* write [it was
>> > edited/abbreviated by me - S. R.]:
>> > |disadvantages:
>> > |0 - it makes print a special thing
> 
> No more "special" than any other reserved word in Python.

The other reserved words are either:

- values, like None, which can be included in expressions;

- operators, like `is`, `or`, and `not`;

- block statements, like `for x in seq` or `while flag` which
  require a block;

- statements, like `import` and `del`, which operate on names
  rather than values.

(Did I miss any?)


print is the only one which could be a function, and looks like a 
function (apart from the lack of parens). Hence people keep trying to do 
things like use it in lambdas:

https://www.quora.com/Why-does-putting-print-inside-a-Python-lambda-
function-raise-a-syntax-error

Since it *could* be a function, but isn't, that makes it special in a 
special way.


>> > |1 - beginners have to unlearn
> 
> Only if they decide to move to Python3 *AND* only if they decide to use
> the print function at _all_.

Even if you don't use print, you will still have to read other people's 
code that uses it.

And its not just a Python 3 issue. Long before there was a Python 3, 
people would over-generalise from function calls and add extraneous 
brackets around print's argument. It wouldn't matter if you were printing 
a single value, but if you printed two arguments, you would actually 
print a tuple instead.

Here are some more recent examples:

https://stackoverflow.com/questions/38254008/

https://stackoverflow.com/questions/36345800/


but if you have plenty of time on your hands to search the archives of 
this mailing list (newsgroup) you'll find people occasionally writing 
"print(...)" all the way back to Python 2.0 or 1.5.


Very possibly including me.


>> > |2 - `print(x, y)` is *not* the same as `print x, y`;
> 
> Well, duh!

Duh to *you and me*, perhaps, but not so obvious to everyone. See links 
above.

And especially not obvious to beginners, who have to learn that print is 
magically and unlike all other functions, doesn't require parentheses.


[...]
> I'll leave the remaining feature implementations as an exercise for the
> reader...

I already said that you can work around the crippling limitations of 
print by avoiding it.

So why have a standard print (pseudo-)function if it is so crippled and 
limited that it has to be worked around to be useful for anything more 
complicated than "Hello World"?

For the microscopic cost of requiring parens when calling the print 
function, you gain all the features of a function. That's a great 
tradeoff. Beginners have to learn to use parens for every other function 
they use. Having one more is an insignificant cost. And for advanced 
programmers, now you have a print function that is actually useful.


>> > |5 - it can't be mocked, shadowed, monkey-patched or replaced for
>> > testing;
> 
> So wrap sys.stdout.write with your own function and then mock it until
> it crys and runs home to mommy; shadow it until it reports you as a
> stalker; and monkey patch it until your sewing hand becomes racked with
> arthritic pain!

You aren't thinking it through far enough.

If it's *my* code, I can just use my editor to search for "print foo" and 
replace it with "awesome_print(foo)" and I'm done.

But if I'm using a library or some other piece of code that uses print, 
and I can't edit the source code (maybe I don't even have the source 
code), I need to mock it (etc). Now I'm completely out of luck, because 
you can't shadow or replace the print statement.

I *might* be able to hack up some sort of magic replacement for stdout, 
but that's easier said than done, and if the library is printing to other 
files I'm screwed. What am I going to do, chase down every single call to 
print? How? By scanning the .pyc files and disassembling the byte-code?

Sure, if you are willing to invest sufficiently large time, money and 
effort, there's a solution. But something which should take literally 
five seconds:

import nasty_library_that_uses_print as nasty
nasty.print = lambda *args: logger(*args)  # or similar

could take weeks of development effort to get right.


>> > |6 - and you can't even write help(print) in the interactive
>> > interpreter
> 
> Hmm, neither can you get help for these:
> 
> # PYTHON 2.x
> >>> help(del)
> SyntaxError: invalid syntax

Indeed you can't.

But there is a very good reason why del, if, else etc are statements. 
They *have to be*. For example, you can't write del as a function, 
because if you do, it won't receive the names of the variables, only 
their values.

It's a trade-off. With del, if, else etc, the value of them being 
statements far outweighs the 

Re: Old Man Yells At Cloud

[Chris Angelico]

On Wed, Sep 20, 2017 at 2:55 PM, Pavol Lisy  wrote:
> BTW if python would only bring "from __cleverness__ import
> print_function" how many people would accept your reasons and use it?
> And how many would rewrite old code?
>
> How many people would say something like: "Oh it is cool! Now I could
> rewrite my old code and monkey patch print!" ?

Cool thing is that now that 'print' isn't a keyword, you can actually
write that as:

from cleverness import print

and put whatever functionality you like into cleverness.py. The only
thing you *can't* do that way is mess with syntax - and if you want to
prototype a change to syntax, you can play with MacroPy. So you can
actually publish something and ask people to try using it.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Pavol Lisy]

On 9/19/17, Steve D'Aprano  wrote:

[...]

> The point is, we all make the occasional silly error. Doesn't mean we should
> cripple our functions and fill the language with special cases like the
> print
> statement to avoid such rare errors. If print had always been a function,
> and
> someone suggested making it a statement, who would be willing to accept all
> those disadvantages for the sake of saving one character?

I am not going to support print as a statement in this discussion!

But what you are describing is some kind of alternative history which
did not happen.

Question was not about crippling function to statement. (Which function?)

What I mean is that if we like to convince people that it was good
decision then we need to use proper arguments.

For example some others which seems like not so proper to me:

1. "learn-unlearn" argument could be viewed differently from opposite
camp (they need to unlearn statement)
2. "print foo" save more than one character ("print foo ," more than
two characters)
3. "for sake of saving one character"? Could we really simplify
motivation of opposite side to just this? (what about breaking old
code?)

BTW if python would only bring "from __cleverness__ import
print_function" how many people would accept your reasons and use it?
And how many would rewrite old code?

How many people would say something like: "Oh it is cool! Now I could
rewrite my old code and monkey patch print!" ?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[MRAB]

On 2017-09-20 01:41, Stefan Ram wrote:

Steve D'Aprano  writes:

A simple "autocorrect" in *what*? The interpreter? The editor? Both?


   I imagine something like this: When the editor gets the
   command to run the contents of the buffer as Python,
   it would then do the autocorrect in the buffer (making a
   backup first or preparing an undo feature) as a kind of
   preprocessor and then send the result to Python. But the
   user is encouraged to also continue to work with the result
   of the preprocessor.


Do you think Microsoft will consider adding it to Notepad? I seem to recall that
you use an editor which doesn't even auto-indent after a colon.


   In fact, in my courses, I often use Notepad.

   In my Python course, I will use the console that comes with
   Python and, later, I may introduce how to create source files
   with Notepad, but I will also show IDLE.

Notepad is very basic. There are many free and open-source text editors 
available. I suggest you try one!

--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Ethan Furman]

On 09/19/2017 09:37 AM, justin walters wrote:

On Tue, Sep 19, 2017 at 9:17 AM, Grant Edwards 
wrote:


On 2017-09-19, Jan Erik =?utf-8?q?Mostr=C3=B6m?= 
wrote:


And I'm amazed how often I see people trying to calculate

  change = sum handed over - cost

and then trying to figure out what bills/coins should be returned
instead of doing the simple thing of just adding to the cost.


When I was a kid, making change like that was something we were all
taught in school.  I have a feeling that's been dropped from most
curricula.

--
Grant Edwards   grant.b.edwardsYow! MMM-MM!!  So THIS
is
   at   BIO-NEBULATION!
   gmail.com

--
https://mail.python.org/mailman/listinfo/python-list




Not sure about the most recent decade, but back when I was in elementary
school(1995-2001-ish),
we definitely still learned math through how to make change.


Ah, but making change and counting change are not the same thing!

Making change: $3.61 from $10 . . . $6.39

Counting change: $3.61 from $10 --

 - (give four pennies back) $3.65
 - (give a dime back) $3.75
 - (give a quarter back) $4.00
 - (give a dollar back) $5.00
 - (give a five back) and $10.00!

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Rick Johnson]

On Tuesday, September 19, 2017 at 1:31:52 PM UTC-5, bartc wrote:
[...]

> Can't you get around all those with things like
> sys.stdout.write?

Yes.

> If so, what was the point of having a discrete print
> statement/function at all?

I believe the original intent was to create a universal
symbol for a "shortcut to sys.stdout.write". As you can
imagine, if every programmer is required to implement their
own version of print, not only is the wheel being re-
invented, many unique symbols would be used, and Python code
would be far less intuitive between authors.

Furthermore, i don't believe print should have ever been
expanded for use _outside_ of the most simple outputs. For
instance: using print for advanced things like redirecting
output is going beyond the scope of a special purpose
shortcut.

Finally, (and this is most important) i believe that when
print() and input() are over-utilized, noobs, especially
those who do not have an understanding of IO streams, fail
to realize that print() and input() are just shortcuts to
the more feature-rich objects living in the `sys` module. In
fact, for a noob who begins programming with Python
(especially when outside of a structured academic
environment) they are likely to never make the connection,
or, at least, not make the connection for a very long time.
And being that IO streams are one of the fundamentals of
programming, such a heavy reliance on shortcuts is harmful
to the intellectual development of these students.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Rick Johnson]

On Tuesday, September 19, 2017 at 12:55:14 PM UTC-5, Chris Angelico wrote:
> On Wed, Sep 20, 2017 at 3:44 AM, Stefan Ram  wrote:
> > Steve D'Aprano  did *not* write
> > [it was edited/abbreviated by me - S. R.]:
> > |disadvantages:
> > |0 - it makes print a special thing

No more "special" than any other reserved word in Python.

> > |1 - beginners have to unlearn

Only if they decide to move to Python3 *AND* only if they
decide to use the print function at _all_. Not everyone uses
print (function or statement). Many folks prefer the power
of the logging module, or use the implicit output of a
REPL.

> > |2 - `print(x, y)` is *not* the same as `print x, y`;

Well, duh! 

> > |3 - it has bizarre syntax that nobody would find normal

Only in advanced usage, which can be better handled by using
sys.stdout.write(...)

> > |4 - you can't pass keyword arguments

Only in advanced cases do you need to. In those cases, wrap
sys.stdout.write with your own function:

# PYTHON 2.x
>>> import sys
>>> def myPrintFunc(*args, **kw):
... sys.stdout.write(' '.join(str(arg) for arg in args))
... 
>>>  myPrintFunc("Monkey", "Patching", "is easy", 2, "do!")
Monkey Patching is easy 2 do!

I'll leave the remaining feature implementations as an
exercise for the reader...

> > |5 - it can't be mocked, shadowed, monkey-patched or replaced for testing;

So wrap sys.stdout.write with your own function and then
mock it until it crys and runs home to mommy; shadow it
until it reports you as a stalker; and monkey patch it until
your sewing hand becomes racked with arthritic pain!

> > |6 - and you can't even write help(print) in the interactive interpreter

Hmm, neither can you get help for these:

# PYTHON 2.x
>>> help(del)
SyntaxError: invalid syntax
>>> help(if)
SyntaxError: invalid syntax
>>> help(else)
SyntaxError: invalid syntax
>>> help(for)
SyntaxError: invalid syntax
>>> help(class)
SyntaxError: invalid syntax
>>> help(def)
SyntaxError: invalid syntax

And this doesn't work either:

>>> help(python)
Traceback (most recent call last):
  File "", line 1, in 
help(python)
NameError: name 'python' is not defined

nor this:

>>> help(BDFL)
Traceback (most recent call last):
  File "", line 1, in 
help(BDFL)
NameError: name 'BDFL' is not defined

nor even this:

>>> help("I've fallen and i can't get up!")
no Python documentation found for "I've fallen and i can't get up!"

Why, what a surprise!!!

These so-called "disadvantages" are nothing but absurdities
masquerading as debate, and more evidence that Steven, along
with Chris, are on a Python3 religious crusade to rid the
world of perceived infidels. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Rick Johnson]

On Tuesday, September 19, 2017 at 2:08:05 AM UTC-5, Steven D'Aprano wrote:
> [...]
> 5.6775 is a much more useful answer than Fraction(2271, 400). ("What's 
> that in real money?")

Steven, you're not using floats for currency are you? 

Tsk tsk!

Besides, if Python division returned a useless fraction like
Fraction(2271, 400), all you'd have to do is cast it to
something appropriate, which in the case of currency, would
be a decimal, not a float.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Steve D'Aprano]

On Wed, 20 Sep 2017 04:31 am, bartc wrote:

> On 19/09/2017 17:30, Steve D'Aprano wrote:

[snip list of problems with print]

> Can't you get around all those with things like sys.stdout.write?

If you had kept reading, you would have seen that I wrote:

Of course an experienced Python coder can work around all these 
problems. The main way to work around them is to *stop using print*.

Using sys.stdout.write has disadvantages:

- it only takes a single string argument;

- which makes you responsible for doing everything that print does:

  * converting arbitrary arguments to strings;
  * joining them with spaces (or some other separator);
  * appending a newline (or other delimiter) at the end;
  * flushing the buffer;

- it's about three times as long to type as "print";

- are you sure sys.stdout is pointing where you expect?

So to work around *those* problems, you end up writing your own helper function,
which invariably ends up being called something like print1.


> If so, what was the point of having a discrete print statement/function
> at all?

It is easily discoverable for beginners.

You don't have to learn the concepts of modules, importing, attribute access,
methods, files, string escapes \n etc before being able to display output to
the user.

Don't get me wrong. I love print. Even the print statement is better than
nothing. But once you get past the simple cases:

print "Hello World!"

you quickly run into its limitations.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Chris Angelico]

On Wed, Sep 20, 2017 at 4:59 AM, Stefan Ram  wrote:
> "Jan Erik =?utf-8?q?Mostr=C3=B6m?="  writes:
>>And I'm amazed how often I see people trying to calculate
>>change = sum handed over - cost
>>and then trying to figure out what bills/coins should be returned
>>instead of doing the simple thing of just adding to the cost.
>
>   I don't get this. For example, the contractual payment (cost) is
>
> 47.21
>
>   , the other party hands over
>
> 50.25
>
>   . Now I am supposed to add /what/ to the cost?

Start at the smallest end. You need to make 21 cents up to 25. So hand
back four pennies. Then make 47 dollars up to 50. Here in Australia,
that would mean a $1 coin and a $2 coin; in the US, probably three $1
notes. You count 'em off: starting at 47, hand a dollar, 48, another
dollar, 49, a third dollar, 50. Now you've added the change onto the
cost, reaching the amount paid.

It's more useful when the customer *hasn't* tried to be helpful; what
you're doing is rounding everything up to the next unit. I'm going to
assume pre-1992 Australian currency (when we still had 1c and 2c
coins) - feel free to adjust to your own. The cost is $47.21; the
customer handed over a $50 note. You say the parts in quotes.

* Quote the value of the bill. "Forty-seven dollars twenty-one."
* Build 21 cents up to 25. Two 2c coins: "23, 25"
* Build 25 cents up to 30. One 5c coin: "30"
* Build 30 up to 50. One 20c coin: "50"
* Build 50 up to the next dollar. One 50c coin: "48 dollars."
* Build that up to the amount paid. One $2 coin: "50."

Or of course you could use other denominations (maybe a pair of $1
coins if you're out of twos), in which case you'd say that
appropriately ("49, 50").

Does that make sense?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[bartc]

On 19/09/2017 17:26, Larry Martell wrote:

On Tue, Sep 19, 2017 at 10:30 AM, D'Arcy Cain  wrote:

On 09/19/2017 06:46 AM, Larry Martell wrote:


True story - the other day I was in a store and my total was $10.12. I



One time I was at a cash with three or four items which were taxable. The
cashier rung each one up and hit the total button.  She turned to me and
said something like "$23.42 please."  She was surprised to see that I was
already standing there with $23.42 in my hand.  "How did you do that" she
asked.  She must have thought it was a magic trick.


I was just in a clothing store this weekend and there was a rack of
clothes that was 50%. The sales clerk said everything on that rack was
an additional 25% off, so it's 75% off the original price. I asked is
it 75% off the original price or 25% off the 50% of the price. Said
it's the same thing. I said no it's not. She insisted it was. I said
no, let's take a simple example. If it was $100 and it was 75% off it
would be $25. But if it's 50% off and then 25% off that it will be
$37.50. She looked totally dumbfounded.



Most people (in the general population, doubtless not in this group) 
seem to be confused about things like that.


Your house has gone down in value by 30% this year; it will need to 
increase by 43% to be back where it was last year, not 30%.


Value-Added-Tax in the UK increased from 17.5% to 20%, everyone was 
talking about a 2.5% increase in prices. The increase would actually be 
just over 2.1% (a £100 ex-VAT price increases from £117.50 to £120.00).


Etc.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[justin walters]

On Tue, Sep 19, 2017 at 9:17 AM, Grant Edwards 
wrote:

> On 2017-09-19, Jan Erik =?utf-8?q?Mostr=C3=B6m?= 
> wrote:
>
> > And I'm amazed how often I see people trying to calculate
> >
> >  change = sum handed over - cost
> >
> > and then trying to figure out what bills/coins should be returned
> > instead of doing the simple thing of just adding to the cost.
>
> When I was a kid, making change like that was something we were all
> taught in school.  I have a feeling that's been dropped from most
> curricula.
>
> --
> Grant Edwards   grant.b.edwardsYow! MMM-MM!!  So THIS
> is
>   at   BIO-NEBULATION!
>   gmail.com
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


Not sure about the most recent decade, but back when I was in elementary
school(1995-2001-ish),
we definitely still learned math through how to make change.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Larry Martell]

On Tue, Sep 19, 2017 at 10:30 AM, D'Arcy Cain  wrote:
> On 09/19/2017 06:46 AM, Larry Martell wrote:
>>
>> True story - the other day I was in a store and my total was $10.12. I
>
>
> One time I was at a cash with three or four items which were taxable. The
> cashier rung each one up and hit the total button.  She turned to me and
> said something like "$23.42 please."  She was surprised to see that I was
> already standing there with $23.42 in my hand.  "How did you do that" she
> asked.  She must have thought it was a magic trick.

I was just in a clothing store this weekend and there was a rack of
clothes that was 50%. The sales clerk said everything on that rack was
an additional 25% off, so it's 75% off the original price. I asked is
it 75% off the original price or 25% off the 50% of the price. Said
it's the same thing. I said no it's not. She insisted it was. I said
no, let's take a simple example. If it was $100 and it was 75% off it
would be $25. But if it's 50% off and then 25% off that it will be
$37.50. She looked totally dumbfounded.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Grant Edwards]

On 2017-09-19, Jan Erik =?utf-8?q?Mostr=C3=B6m?=  wrote:

> And I'm amazed how often I see people trying to calculate
>
>  change = sum handed over - cost
>
> and then trying to figure out what bills/coins should be returned 
> instead of doing the simple thing of just adding to the cost.

When I was a kid, making change like that was something we were all
taught in school.  I have a feeling that's been dropped from most
curricula.

-- 
Grant Edwards   grant.b.edwardsYow! MMM-MM!!  So THIS is
  at   BIO-NEBULATION!
  gmail.com

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Rhodri James]

On 18/09/17 16:29, Ben Bacarisse wrote:

Steve D'Aprano  writes:


To answer your question, what do I mean by int/int being undefined, I'd have to
dig into areas of maths that either weren't taught in the undergrad courses I
did, or that I've long since forgotten about. Something
about... fields?



This is a pretty specialised area of maths. You won't learn anything
about it in high school. And possibly not undergrad maths degrees. I
seem to vaguely recall just barely touching on groups, but not rings
or fields.


When you said before that you thought that undefined division was rather
obscure I was going to mention that it's the basic difference between a
ring and a field; the intent being that you'd go "oh, yes, of course
it's not obscure at all".  I'm glad I didn't now, because you would not
have seen it as the simple notion I expected!

Teaching rings and fields is (or at least was 30 or so years ago) 1st
year undergraduate maths here in the UK.  Maybe it's changed.


I think I achieved a nodding acquaintance with rings, fields and vector 
spaces in Further Maths (pre-university), and then got the real deal in 
my first term at university.  I think they now happen later in the first 
year; looking at the on-line syllabus, the first two terms of IA Maths 
are now full of things that used to be taught at A-level.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Frank Millman]

"bartc"  wrote in message news:EN6wB.770830$uh.63078@fx28.am4...

On 19/09/2017 11:46, Larry Martell wrote:

>
> True story - the other day I was in a store and my total was $10.12. I
> pulled out a $20, and the cashier (probably age 23 or so) immediately
> entered $20 as the amount tendered. Then I said "Let me see if I have
> the $0.12." I did not, but I had $0.15 so I handed her $20.15. She
> literally froze in place with a classic deer in the headlights stare.
> I said "$10.03" She said "What?" I said "$10.03 is my change." She
> said "What?" I said "Just give me $10." She did not reply, opened the
> drawer below her register, rummaged around and came out with one of
> those giant key calculators, and with a look of dogged determination,
> did the calculation, looked at me and said proudly "$10.03 is your
> change."

My bill in a store came to £3.20 (GBP3.20), so I handed over £10.20.

I was given back £16.90 in change!

It turned out the cashier had entered £20.10 as the amount tendered. It 
was sorted out in the end.




My favourite true story on this subject -

In England, just after decimalisation was introduced, I was at a lunch with 
a few other people. When we asked the waitress for the bill, she brought out 
a hand-written list of what we had ordered (no computers or calculators in 
those days) and proceeded to add it up manually. The total, in new pence, 
came to four figures. She then, talking to herself, did the next bit of the 
calculation. 'Lets see, there are 100 new pence in a pound, so divide the 
total by 100, ...'. She worked the whole thing out using just pencil and 
paper, and then when she had written down the result, exclaimed 'Oh, it’s 
the same!'.


Frank Millman


--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[bartc]

On 19/09/2017 11:46, Larry Martell wrote:

On Mon, Sep 18, 2017 at 11:23 PM, Dan Sommers  wrote:

How relevant is the "people use calculators to do arithmetic" argument
today?  Okay, so I'm old and cynical, but I know [young] people who
don't (can't?) calculate a gratuity without an app or a web page.


I use a calculator all the time - not for calculating a tip though.
Sometimes I use bc (when I can't find my calculator in the morass of
my desk).

True story - the other day I was in a store and my total was $10.12. I
pulled out a $20, and the cashier (probably age 23 or so) immediately
entered $20 as the amount tendered. Then I said "Let me see if I have
the $0.12." I did not, but I had $0.15 so I handed her $20.15. She
literally froze in place with a classic deer in the headlights stare.
I said "$10.03" She said "What?" I said "$10.03 is my change." She
said "What?" I said "Just give me $10." She did not reply, opened the
drawer below her register, rummaged around and came out with one of
those giant key calculators, and with a look of dogged determination,
did the calculation, looked at me and said proudly "$10.03 is your
change."


My bill in a store came to £3.20 (GBP3.20), so I handed over £10.20.

I was given back £16.90 in change!

It turned out the cashier had entered £20.10 as the amount tendered. It 
was sorted out in the end.


Sometimes its easier not to be bother making the figures come out better.

--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Larry Martell]

On Mon, Sep 18, 2017 at 11:23 PM, Dan Sommers  wrote:
> How relevant is the "people use calculators to do arithmetic" argument
> today?  Okay, so I'm old and cynical, but I know [young] people who
> don't (can't?) calculate a gratuity without an app or a web page.

I use a calculator all the time - not for calculating a tip though.
Sometimes I use bc (when I can't find my calculator in the morass of
my desk).

True story - the other day I was in a store and my total was $10.12. I
pulled out a $20, and the cashier (probably age 23 or so) immediately
entered $20 as the amount tendered. Then I said "Let me see if I have
the $0.12." I did not, but I had $0.15 so I handed her $20.15. She
literally froze in place with a classic deer in the headlights stare.
I said "$10.03" She said "What?" I said "$10.03 is my change." She
said "What?" I said "Just give me $10." She did not reply, opened the
drawer below her register, rummaged around and came out with one of
those giant key calculators, and with a look of dogged determination,
did the calculation, looked at me and said proudly "$10.03 is your
change."
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Chris Angelico]

On Tue, Sep 19, 2017 at 7:31 PM, Steven D'Aprano
 wrote:
> On Tue, 19 Sep 2017 17:59:10 +1000, Chris Angelico wrote:
>
>> Aside from the backward compatibility concerns (which mean that this
>> can't be done in a language that calls itself "Python"), I'm not seeing
>> any reason that a human-friendly language can't spend most of its time
>> working with arbitrary-precision rationals, only switching to floats
>> when (a) the programmer explicitly requests it, or (b) when performing
>> operations that fundamentally cannot be performed with rationals.
>
>
> True, it can't be called Python. But it could be called
> EvenSlowerThanPythonYouReallyDontWantToDoAnySeriousNumericWorkWithThis
> instead.
>
>
>
> *wink*

I was thinking "Rational Python" to troll all the people who can't
tell the difference between a rational number and a rational person.

*wink*

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Steven D'Aprano]

On Tue, 19 Sep 2017 17:59:10 +1000, Chris Angelico wrote:

> Aside from the backward compatibility concerns (which mean that this
> can't be done in a language that calls itself "Python"), I'm not seeing
> any reason that a human-friendly language can't spend most of its time
> working with arbitrary-precision rationals, only switching to floats
> when (a) the programmer explicitly requests it, or (b) when performing
> operations that fundamentally cannot be performed with rationals.


True, it can't be called Python. But it could be called 
EvenSlowerThanPythonYouReallyDontWantToDoAnySeriousNumericWorkWithThis 
instead.



*wink*


-- 
Steven D'Aprano
“You are deluded if you think software engineers who can't write 
operating systems or applications without security holes, can write 
virtualization layers without security holes.” —Theo de Raadt
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Chris Angelico]

On Tue, Sep 19, 2017 at 5:07 PM, Steven D'Aprano
 wrote:
> On Tue, 19 Sep 2017 03:23:15 +, Dan Sommers wrote:
>
>> On Tue, 19 Sep 2017 01:56:29 +, Stefan Ram wrote:
>>
>>> Steve D'Aprano  writes:
>>
It is true that binary floats have some unexpected properties. They
aren't the real numbers that we learn in maths. But most people who
have been to school have years of experience with calculators training
them to expect computer calculations are sometimes "off". They do a sum
and get 2.9 instead of 3, or perhaps 3.1, and that's
just the way calculators work.
>>
>>>   It is possible that many calculators use base 10 and therefore such
>>>   surprises might be less common than in the world of programming
>>>   languages.
>>
>> How relevant is the "people use calculators to do arithmetic" argument
>> today?  Okay, so I'm old and cynical, but I know [young] people who
>> don't (can't?) calculate a gratuity without an app or a web page.
>
> Which is a form of calculator. People still learn to use calculators at
> school, they still use them at work. They use Excel, which is prone to
> the same issue.
>
> Calculating 15% of $37.85 returns 5.6775 in both Python and on my cheap
> four-function calculator, and I'm sure my phone would give the same
> answer.
>
> 5.6775 is a much more useful answer than Fraction(2271, 400). ("What's
> that in real money?")

Sounds like you want a display formatting feature. I wonder how Python
code would display a number...

>>> f = fractions.Fraction(2271, 400)
>>> "$%.2f" % f
'$5.68'

Looks like money to me.

> Ironically, your comment about ambiguity would be reasonable for, say,
> trig functions, logarithms, and the like. But in those cases, calculating
> the exact answer as a rational is usually impossible. Even something as
> simple as log(2) would require an infinite amount of memory, and infinite
> time, to express exactly as a fraction.

Yeah, logarithms would have to be defined to return floats.
Fortunately, the math module seems pretty happy to accept fractions:

>>> math.log(f)
1.7365109949975766
>>> math.sin(f)
-0.5693256092491197
>>> math.sqrt(f)
2.382750511488771

>> Yes, every once in a while, I get a result
>> with lots of digits, but that's usually while I'm developing an
>> algorithm, and then I can decide whether or not and when to coerce the
>> result to floating point.
>
> I guess that you must have pretty simple algorithms then. No square
> roots, no trig, no exponentiation except for positive integer powers,
> little or no iteration.
>
> Outside of some pretty specialised fields, there's a reason why the
> numeric community has standardised on floating point maths.

Aside from the backward compatibility concerns (which mean that this
can't be done in a language that calls itself "Python"), I'm not
seeing any reason that a human-friendly language can't spend most of
its time working with arbitrary-precision rationals, only switching to
floats when (a) the programmer explicitly requests it, or (b) when
performing operations that fundamentally cannot be performed with
rationals.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[bartc]

On 18/09/2017 15:04, Gregory Ewing wrote:

Dennis Lee Bieber wrote:

Pascal
provides print()/println() [okay, not /statements/ but /procedures/]


Actually write/writeln, and although they used parens like
procedures, they had special syntax for output formatting
that wasn't available to user-defined procedures, so they
were at least as special as the py2 print, maybe more so.


They HAD to be special, because that language was statically typed. You 
couldn't define a user-code procedure or function that took all possible 
types.


That doesn't apply in Python, but it is still useful for print to be a 
little special.


--
bartc

--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Ben Bacarisse]

Steve D'Aprano  writes:

> [...] try something more common:
>
> 1/2
>
> Most people aren't expecting integer division, but true division, and silently
> returning the wrong result (0 instead of 0.5) is a silent source of
> bugs.

I'm the sure that expectation depends on their background and previous
programming experience, and since I don't know much about most people
when they first write 1/2 in Python, I must conceded that you may be
right.  But is that really the point?  Was the result of 1/2 determined
by a poll to find out what most people expected?  If so, who were these
people -- the result would depend very largely on the selection?

But there is a stronger claim (which I think you also made) that a
floating point result is the correct one.  However, some people with
little experience of floating point arithmetic (I certainly can't say
most but it must be quite few) will expect

  1/10

to return a tenth.  For /them/, the floating point result is silently
wrong and a source of bugs.  If I were aiming a language at beginners,
I'd make 1/10 be a rational or a type error.

However, I don't think that is Python's main demographic, so 1/10 giving
something not quite one tenth may well be the correct design choice.


> And 1/2 doesn't have to return an int. Why is this such a big deal?

I'm sure it's not deliberate, but 1/2 is a bad example because it can be
exactly represented in the most common implementations.  To get a more
fruitful exchange of views, a division like 1/3 or 1/10 might be a
better example.


-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[bartc]

On 18/09/2017 04:23, Steve D'Aprano wrote:

On Mon, 18 Sep 2017 11:11 am, Rick Johnson wrote:


Speaking in _keystrokes_, and that's what really matters
here, a print function is always three more keystrokes than
a print statement.


Keystrokes only matter if you are hunt'n'peck typing and need to pause between
holding down the shift key and pressing the 9 key. Otherwise typing ( is little
different than typing 9, its pretty much all the same regardless of what
character you type. For an even half-arsed typist like myself, hitting the
shift and 9 keys happens almost simultaneously. Technically it might involve
two fingers but its effectively a single movement.

If you micro-analyse this, not all keystrokes are equivalent. They use different
fingers, different hands, the movements are different. The fact that some
characters need two simultaneous keypresses is not so important.


I don't hunt but my typing accuracy is very poor.

Shifted keys are harder (in having poorer success outcomes) because two 
keys are involved, the keys are somewhat outside the Qwerty zone so need 
a longer reach, and some synchronisation is needed (the shift must be 
pressed before the '(').


It's not as bad as it sounds but just means that unnecessary shifted 
punctuation is more of a PITA than if it wasn't necessary.


It's a lot worse doing this in C however; compare:

   print a

with:

   printf ("%d\n",a);

8 extra punctuation characters, of which half are shifted (on my 
keyboard). /And/ you have to select a suitable format code. Suddenly, 
having to type:


   print (a)

doesn't seem so bad.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Chris Angelico]

On Mon, Sep 18, 2017 at 1:23 PM, Steve D'Aprano
 wrote:
> On Mon, 18 Sep 2017 11:11 am, Rick Johnson wrote:
>
>> Speaking in _keystrokes_, and that's what really matters
>> here, a print function is always three more keystrokes than
>> a print statement.
>
> Keystrokes only matter if you are hunt'n'peck typing and need to pause between
> holding down the shift key and pressing the 9 key. Otherwise typing ( is 
> little
> different than typing 9, its pretty much all the same regardless of what
> character you type. For an even half-arsed typist like myself, hitting the
> shift and 9 keys happens almost simultaneously. Technically it might involve
> two fingers but its effectively a single movement.
>
> If you micro-analyse this, not all keystrokes are equivalent. They use 
> different
> fingers, different hands, the movements are different. The fact that some
> characters need two simultaneous keypresses is not so important.

The easiest non-micro analysis is that a *repeated* key is
significantly slower than virtually any pair of keystrokes.
Consequently, the slowest part of programming is the part where you
realize that you got something wrong, and hammer the Backspace key.
It's just logical!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Steve D'Aprano]

On Mon, 18 Sep 2017 11:11 am, Rick Johnson wrote:

> Speaking in _keystrokes_, and that's what really matters
> here, a print function is always three more keystrokes than
> a print statement.

Keystrokes only matter if you are hunt'n'peck typing and need to pause between
holding down the shift key and pressing the 9 key. Otherwise typing ( is little
different than typing 9, its pretty much all the same regardless of what
character you type. For an even half-arsed typist like myself, hitting the
shift and 9 keys happens almost simultaneously. Technically it might involve
two fingers but its effectively a single movement.

If you micro-analyse this, not all keystrokes are equivalent. They use different
fingers, different hands, the movements are different. The fact that some
characters need two simultaneous keypresses is not so important.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Tim Chase]

On 2017-09-18 01:41, INADA Naoki wrote:
> > > That said, I'm neither here nor there when it comes to
> > > using print-as-a-statement vs print-as-a-function.  I like
> > > the consistency it brings to the language, but miss the
> > > simplicity that Py2 had for new users.  I'd almost want to
> > > get it back as a feature of the REPL, even if it wasn't
> > > part of the language itself,  
> >
> > Agreed on that point. At least bring it back in the REPL.
> > The removal of the finger friendly print statement has
> > caused more tension in this community than any feature of
> > such small stature should ever cause.
> >
> >  
> >>> x = 42
> >>> x  
> 42
> 
> x (1 keystroke) is easy to type than `print x` (7 keystrokes).
> While sometimes print(x) is different x (which uses repr), it's
> enough for most cases.
> So I can't agree it's REPL unfriendly.

Compare PDB for things that are PDB commands.

  (Pdb) list
  1 j = 42
  2 x = 31
  3 import pdb; pdb.set_trace()
  4  -> j = 15
  5 x = 99
  [EOF]
  (Pdb) x
  31
  (Pdb) j
  *** The 'jump' command requires a line number
  (Pdb) print j
  *** SyntaxError: Missing parentheses in call to 'print'
  (Pdb) j 1
  > /home/tkc/test.py(1)()
  -> j = 42
  (Pdb) j(2)
  *** The 'jump' command requires a line number

You (obstinate interpreter) know what I want, know what I mean, can't
possibly interpret it as some other command. Yet insist on pedantic
parens when you (interpreter) know full well the intended parsing,
accepting "j 1" to jump to line one instead of making me type "j(1)".

:grumble:

old-man-shaking-his-fist-at-the-sky'ly yers,

-tkc














-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[INADA Naoki]

>
>
> > That said, I'm neither here nor there when it comes to
> > using print-as-a-statement vs print-as-a-function.  I like
> > the consistency it brings to the language, but miss the
> > simplicity that Py2 had for new users.  I'd almost want to
> > get it back as a feature of the REPL, even if it wasn't
> > part of the language itself,
>
> Agreed on that point. At least bring it back in the REPL.
> The removal of the finger friendly print statement has
> caused more tension in this community than any feature of
> such small stature should ever cause.
>
>
>>> x = 42
>>> x
42

x (1 keystroke) is easy to type than `print x` (7 keystrokes).
While sometimes print(x) is different x (which uses repr), it's enough for
most cases.
So I can't agree it's REPL unfriendly.

BTW, IPython is nice REPL and it has parenthee free function call.
I recommend you to use it if you're not happy with builtin REPL.

Regards,

-- 
Inada Naoki 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Steve D'Aprano]

On Mon, 18 Sep 2017 09:15 am, Rick Johnson wrote:

> On Sunday, September 17, 2017 at 9:42:34 AM UTC-5, Steve D'Aprano wrote:
>> On Sun, 17 Sep 2017 11:51 pm, Tim Golden wrote:
>> 
>> [Snip: Reasons why print function is better than print statement]
>> 
>> I've wanted to do all those things, and more. I love the
>> new print function. For the cost of one extra character,
>> the closing bracket,
> 
> Oops, _two_ characters! What about the opening "bracket"?

It replaces the space separating print from the arguments.

print spam, eggs, cheese

print(spam, eggs, cheese)

One extra character. See?



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Rick Johnson]

MRAB wrote:
> Rick Johnson wrote:
> > Steve D'Aprano wrote:
> >> Tim Golden wrote:
> > > 
> > > [Snip: Reasons why print function is better than print statement]
> > > 
> > > I've wanted to do all those things, and more. I love the
> > > new print function. For the cost of one extra character,
> > > the closing bracket,
> > 
> > Oops, _two_ characters! What about the opening "bracket"?
> > 
> What about the space that usually comes after 'print' in
> Python 2, but not in Python 3?

True. But let's not forget that spaces are one keystroke
whereas an open round-bracket is ^9 and a closing round-
bracket is ^0.

Speaking in _keystrokes_, and that's what really matters
here, a print function is always three more keystrokes than
a print statement.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Christopher Reimer]

> On Sep 17, 2017, at 2:19 PM, Ned Batchelder  wrote:
> 
>> On 9/16/17 1:38 AM, Steve D'Aprano wrote:
>> /rant on
>> 
>> So apparently everyone who disagrees that Python should be more like 
>> Javascript
>> is an old greybeard fuddy-duddy yelling "Get off my lawn!" to the cool kids 
>> --
>> and is also too stupid to know how dumb they are.
>> 
>> "Hi, I've been programming in Python for what seems like days now, and here's
>> all the things that you guys are doing wrong. I insist that you fix them
>> immediately, it doesn't matter how much code it will break, that's not
>> important. What is important is that Javascript programmers like me shouldn't
>> be expected to learn anything new or different when they program with 
>> Python."
>> 
>> /rant off
>> 
>> And no, for once it wasn't Ranting Rick.
> 
> The thing that struck me about the interaction (on Python-Ideas, btw) was 
> that Javascript actually is adding new language features at an impressive 
> pace, and many of them seem very Pythonic.  But they sometimes choose 
> different syntax.
> 
> For example, their "spread" operator is ..., where Python uses *:
> 
> new_list = [new_start, *old_list, new_end]
> 
> vs:
> 
> new_array = [new_start, ...old_array, new_end]
> 
> Making Python more like Javascript (in this case) would have required 
> breaking existing Python programs. Javascript could have use * as the spread 
> operator without breaking anyone. But they didn't, and I wonder if anyone 
> petitioned them to keep compatibility with Python to easy the plight of the 
> multi-lingual programmer.
> 
> --Ned.
> -- 
> https://mail.python.org/mailman/listinfo/python-list

I came across a blog post that pointed out that those who advocate for a 
particular JavaScript framework probably know enough JavaScript for the 
framework but not enough JavaScript to figure out a problem with the framework. 
Since frameworks are an abstraction of JavaScript, you really need to know 
JavaScript to avoid getting stuck with a framework. I know enough JavaScript to 
get the JQuery eye candy to work and I'm confused by all the frameworks 
available. I picked up a JavaScript ebook to familiarize myself with the 
language. This isn't the same JavaScript that I learned in the early 2000's. 

Chris R. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Tim Chase]

On 2017-09-17 16:15, Rick Johnson wrote:
> > I've wanted to do all those things, and more. I love the
> > new print function. For the cost of one extra character,
> > the closing bracket,  
> 
> Oops, _two_ characters! What about the opening "bracket"?

  >>> print(len('print "hello"'))
  13
  >>> print(len('print("hello")'))
  14

Plus two parens, minus one space = net +1 character.

-tkc



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[MRAB]

On 2017-09-18 00:15, Rick Johnson wrote:

On Sunday, September 17, 2017 at 9:42:34 AM UTC-5, Steve D'Aprano wrote:

On Sun, 17 Sep 2017 11:51 pm, Tim Golden wrote:

[Snip: Reasons why print function is better than print statement]

I've wanted to do all those things, and more. I love the
new print function. For the cost of one extra character,
the closing bracket,


Oops, _two_ characters! What about the opening "bracket"?

What about the space that usually comes after 'print' in Python 2, but 
not in Python 3?


[snip]
--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Rick Johnson]

Steve D'Aprano wrote:
> Tim Chase wrote:
> 
> > On 2017-09-18 00:42, Steve D'Aprano wrote:
> > > On Sun, 17 Sep 2017 11:51 pm, Tim Golden wrote:
> > > Presumably you've never wanted to print to something
> > > other than std.out. The syntax in Python 2 is horrid:
> > > 
> > > print >>sys.stderr, args
> > 
> > For those cases, the old syntax was sufficiently horrid
> > that indeed I didn't use it, but rather used
> > 
> >print "Normal output"
> >sys.stderr.write("error output!\n")
> > 
> > Yes, adding the \n manually is a minor annoyance, but it
> > wasn't much of an issue.
> 
> So, you don't like the extra parentheses with print. But
> you don't mind the parentheses in sys.stderr.write (16
> chars, versus five for print) or having to manually
> concatenate the strings and manually add a newline at the
> end. Because apparently using print and sys.stderr.write is
> simpler than print with parens.

It seems odd, but i have a custom function i created for my
own REPL named "pLine()", and i never have a problem
remembering to type the "(" and the ")", but for `print`, i
always forget, or when i do remember, it feels so
"unnatural". This can only mean one thing: old habits die
hard. And anyone with experience in Python<3 has typed the
old print statement so many times that the syntax has become
reflexive. And try as i may, i cannot overcome this habit. I
always get frustrated and go back to the warm fuzzies of my
Python2 interpreter. O:-)

"You wanna go where everybody spells print the same..."

Cheers!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Rick Johnson]

Tim Chase wrote:
> Steve D'Aprano wrote:
> > Tim Golden wrote:

> > Presumably you've never wanted to print to something other
> > than std.out. The syntax in Python 2 is horrid:
> > 
> > print >>sys.stderr, args
> 
> For those cases, the old syntax was sufficiently horrid
> that indeed I didn't use it, but rather used
> 
>print "Normal output"
>sys.stderr.write("error output!\n")
> 
> Yes, adding the \n manually is a minor annoyance, but it
> wasn't much of an issue.

A backwards compatible stderr.writeln() method would fix
that minor annoyance. 

[...]

> That said, I'm neither here nor there when it comes to
> using print-as-a-statement vs print-as-a-function.  I like
> the consistency it brings to the language, but miss the
> simplicity that Py2 had for new users.  I'd almost want to
> get it back as a feature of the REPL, even if it wasn't
> part of the language itself,

Agreed on that point. At least bring it back in the REPL.
The removal of the finger friendly print statement has
caused more tension in this community than any feature of
such small stature should ever cause.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Rick Johnson]

On Sunday, September 17, 2017 at 9:42:34 AM UTC-5, Steve D'Aprano wrote:
> On Sun, 17 Sep 2017 11:51 pm, Tim Golden wrote:
> 
> [Snip: Reasons why print function is better than print statement]
> 
> I've wanted to do all those things, and more. I love the
> new print function. For the cost of one extra character,
> the closing bracket,

Oops, _two_ characters! What about the opening "bracket"?

> [...]
> The print statement was only good for the most simple uses.
> The print function is a powerful, useful and first-class
> component of your programming toolbox.

I agree that the new print function is better than the old
print statement, but the best solution would have been to
keep both. I (like TJG), become frustrated when i forget to
type the parenthesis and get a syntax error. And most times,
i didn't need the extended functionality of a print function
anyway, i just needed a finger-friendly print statement.

> 
> [...]
> > Funnily enough, the two arguments most often advanced for
> > print-as-function seem to me to cancel each other out.
> 
> Arguments by whom?  There's a whole raft of things wrong
> with print as a statement.

The print statement lacks the intuitive features of a
function, but most times, you don't need these features.

"PRACTICALITY BEATS PURITY"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Ned Batchelder]

On 9/16/17 1:38 AM, Steve D'Aprano wrote:

/rant on

So apparently everyone who disagrees that Python should be more like Javascript
is an old greybeard fuddy-duddy yelling "Get off my lawn!" to the cool kids --
and is also too stupid to know how dumb they are.

"Hi, I've been programming in Python for what seems like days now, and here's
all the things that you guys are doing wrong. I insist that you fix them
immediately, it doesn't matter how much code it will break, that's not
important. What is important is that Javascript programmers like me shouldn't
be expected to learn anything new or different when they program with Python."

/rant off

And no, for once it wasn't Ranting Rick.


The thing that struck me about the interaction (on Python-Ideas, btw) 
was that Javascript actually is adding new language features at an 
impressive pace, and many of them seem very Pythonic.  But they 
sometimes choose different syntax.


For example, their "spread" operator is ..., where Python uses *:

    new_list = [new_start, *old_list, new_end]

vs:

    new_array = [new_start, ...old_array, new_end]

Making Python more like Javascript (in this case) would have required 
breaking existing Python programs. Javascript could have use * as the 
spread operator without breaking anyone. But they didn't, and I wonder 
if anyone petitioned them to keep compatibility with Python to easy the 
plight of the multi-lingual programmer.


--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Tim Chase]

On 2017-09-17 14:16, bartc wrote:
> print() is used for its side-effects; what relevant value does it
> return?

depending on the sink, errors can be returned (at least for the
printf(3) C function).  The biggest one I've encountered is writing
to a full disk.  The return value is how many characters were
written.  In an ideal world,

  data = "Hello" * 1000
  results = print(data)
  assert len(results) == len(data)

but if your disk is nearly full and you're redirecting data to it:

   $ python myprog.py > output.txt

it's feasible that you instruct print() to send 5000 characters but
only 4000 of them get written to the disk.  You might want to check
that condition and handle it in some more graceful way.

-tkc





-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[MRAB]

On 2017-09-17 19:59, Chris Angelico wrote:

On Mon, Sep 18, 2017 at 4:35 AM, Steve D'Aprano
 wrote:

So why doesn't it return a fractions.Fraction instead? That way, you
still get "one half" instead of zero, but it's guaranteed to be
accurate. And having 1/3 be a literal meaning "one third" would avoid
all the problems of "1/3 + 1/3 + 1/3 != 3/3". What is the
justification for int/int => float and not rational?


(1) Guido doesn't like fractions for the built-in maths operators, because of
his experience with ABC where quite simple calculations would end up with
bloody enormous fractions with millions of digits in both the numerator and
denominator, running slower and slower, for a number where the actual precision
was maybe three or four decimal places.


Okay, that's reasonable. A counter-argument is that if you want
reduced accuracy to improve performance, you can always ask for it (by
casting to float), but I do see the disadvantage of slow rationals by
default.


(2) Fractions didn't exist in the standard library when true division was
introduced.


Really? When was true division added? I thought the fractions module
had been there for several 2.x versions.


The fractions module was introduced in Python 2.6.

[snip]
--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Tim Daneliuk]

On 09/16/2017 09:59 AM, Tim Daneliuk wrote:
> On 09/16/2017 12:38 AM, Steve D'Aprano wrote:
>> /rant on
>>
>> So apparently everyone who disagrees that Python should be more like 
>> Javascript
>> is an old greybeard fuddy-duddy yelling "Get off my lawn!" to the cool kids 
>> --
>> and is also too stupid to know how dumb they are.
>>
>> "Hi, I've been programming in Python for what seems like days now, and here's
>> all the things that you guys are doing wrong. I insist that you fix them
>> immediately, it doesn't matter how much code it will break, that's not
>> important. What is important is that Javascript programmers like me shouldn't
>> be expected to learn anything new or different when they program with 
>> Python."
>>
>> /rant off
>>
>> And no, for once it wasn't Ranting Rick.
>>
>>
>>
>>
> 
> Well, the whole integer floor division thing years ago was the beginning
> of the end - Python was doomed ...
> 


Ummm  I was KIDDING via hyperbole ... sheesh ...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Chris Angelico]

On Mon, Sep 18, 2017 at 4:35 AM, Steve D'Aprano
 wrote:
>> So why doesn't it return a fractions.Fraction instead? That way, you
>> still get "one half" instead of zero, but it's guaranteed to be
>> accurate. And having 1/3 be a literal meaning "one third" would avoid
>> all the problems of "1/3 + 1/3 + 1/3 != 3/3". What is the
>> justification for int/int => float and not rational?
>
> (1) Guido doesn't like fractions for the built-in maths operators, because of
> his experience with ABC where quite simple calculations would end up with
> bloody enormous fractions with millions of digits in both the numerator and
> denominator, running slower and slower, for a number where the actual 
> precision
> was maybe three or four decimal places.

Okay, that's reasonable. A counter-argument is that if you want
reduced accuracy to improve performance, you can always ask for it (by
casting to float), but I do see the disadvantage of slow rationals by
default.

> (2) Fractions didn't exist in the standard library when true division was
> introduced.

Really? When was true division added? I thought the fractions module
had been there for several 2.x versions.

> (3) Fractions are slow to work with. They were even slower until a few years 
> ago
> when Python got a C accelerated version. Floats are much faster.

Yes, they are. And byte strings are probably faster to work with than
Unicode text. Python doesn't use performance as a primary definition
of semantics.

> (4) For many purposes, the arbitrary precision of fractions is *spurious*
> precision. Like the old saw says:
>
> "Measure with micrometer, mark with chalk, cut with axe."
>
> You're taking physical quantities which are typically measured to a precision 
> of
> three or four decimal places, if not less, then doing calculations on them to 
> a
> precision of potentially millions of decimal places. There may be a few places
> where that is justified, but as the default behaviour, its spurious precision
> and such overkill as to be ludicrous.

And printing "one eleventh" to a dozen decimal places is just as
spurious. Or when you do arithmetic of any kind on decimals. It's not
a problem unique to rationals. But I agree, sometimes you'll have more
precision than you want.

> (5) Most people are used to dealing with floating point numbers, from other
> languages, from calculators, from school maths. Floats are quirky but 
> familiar.
>
> (6) Fractions are surprising and hard to deal with. Quickly now, without 
> using a
> calculator or Python, how big is this number?
>
> 2523720122311461/140737488355328
>
> Is it more or less than 50?
>
> Which would you rather see, the above fraction or its decimal equivalent,
> 17.93211?

If int/int yielded rational, you would have two ways you could work:

1) Fractions: 2523720122311461/140737488355328
2) Floats: 2523720122311461.0/140737488355328

And if you want to know if it's more or less than 50, you could simply compare:

>>> f = fractions.Fraction('2523720122311461/140737488355328')
>>> f
Fraction(2523720122311461, 140737488355328)
>>> f < 50
True
>>> f > 50
False

Sure, it's harder to eyeball. But comparisons are certainly possible.

Basically, you trade one set of weirdnesses for another.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Steve D'Aprano]

On Mon, 18 Sep 2017 04:09 am, Tim Chase wrote:

> On 2017-09-18 00:42, Steve D'Aprano wrote:
>> On Sun, 17 Sep 2017 11:51 pm, Tim Golden wrote:
>> Presumably you've never wanted to print to something other than
>> std.out. The syntax in Python 2 is horrid:
>> 
>> print >>sys.stderr, args
> 
> For those cases, the old syntax was sufficiently horrid that indeed I
> didn't use it, but rather used
> 
>print "Normal output"
>sys.stderr.write("error output!\n")
> 
> Yes, adding the \n manually is a minor annoyance, but it wasn't much
> of an issue.

So, you don't like the extra parentheses with print. But you don't mind the
parentheses in sys.stderr.write (16 chars, versus five for print) or having to
manually concatenate the strings and manually add a newline at the end. Because
apparently using print and sys.stderr.write is simpler than print with parens.


[...]
> That said, I'm neither here nor there when it comes to using
> print-as-a-statement vs print-as-a-function.  I like the consistency
> it brings to the language, but miss the simplicity that Py2 had for
> new users.

What simplicity? It adds complexity, not simplicity: do you need brackets or
not? Why is print special? When do I use print and when do I use
sys.stdout.write? Decisions decisions.

print(len mylist, "items in the list")

> I'd almost want to get it back as a feature of the REPL, 

Oh yes, that's an excellent idea: make it even harder for beginners to learn
when they do and don't need parentheses :-(



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Steve D'Aprano]

On Mon, 18 Sep 2017 03:00 am, Chris Angelico wrote:

>> The distinction between Python floats and real numbers ℝ is a red-herring. It
>> isn't relevant.
> 
> You said:
> 
 (I have a degree in maths, and if we ever
 covered areas where int/int was undefined, it was only briefly, and I've
 long since forgotten it.)
> 
> So what do YOU mean by "int/int" being "undefined"? And I referred to
> real numbers because YOU referred to a degree in maths.

Yes, I referred to a maths degree. I referred to lots of things. And real
numbers are still irrelevant. The problem with Python 2 division is not because
of the difference between mathematically pure reals and actual Python floats.
It is because a/b would do two *different* things depending on whether both a
and b were floats or not.

To answer your question, what do I mean by int/int being undefined, I'd have to
dig into areas of maths that either weren't taught in the undergrad courses I
did, or that I've long since forgotten about. Something about... fields? The
reals and the rationals are both fields, and they're closed under division.
Ints *aren't* a field, because the integers aren't closed under division.

("Closed" means that dividing a rational number by another rational number gives
a rational number, for example.)

This is a pretty specialised area of maths. You won't learn anything about it in
high school. And possibly not undergrad maths degrees. I seem to vaguely recall
just barely touching on groups, but not rings or fields. It's perfectly
possibly for somebody to do a post-grad degree in maths and not touch this
stuff. Hell, I don't even know if I'm right to say that int/int division
is "undefined". It's could be that even mathematicians who work in this area
will say "of course its defined, you just don't always get an int". Or that
they'll say "the question isn't even wrong". 

If you read the Wikipedia page on it:

https://en.wikipedia.org/wiki/Algebraic_structure

you'll see reference to category theory, and monoids, things which Haskell loves
and most other people run screaming from.

The bottom line is, before you can sensibly justify making int/int an illegal
operation (a compile-time error in Haskell) you need to be thinking about some
pretty hairy areas of maths. To say that 11/2 cannot be calculated and isn't
5.5, you're thinking in areas that most mathematically educated people don't
even know exist, let alone care about.


[...]
>> This isn't some theoretical problem that might, maybe, perhaps, be an issue
>> for some people sometimes. It was a regular source of actual bugs leading to
>> code silently returning garbage.
> 
> So why doesn't it return a fractions.Fraction instead? That way, you
> still get "one half" instead of zero, but it's guaranteed to be
> accurate. And having 1/3 be a literal meaning "one third" would avoid
> all the problems of "1/3 + 1/3 + 1/3 != 3/3". What is the
> justification for int/int => float and not rational?

(1) Guido doesn't like fractions for the built-in maths operators, because of
his experience with ABC where quite simple calculations would end up with
bloody enormous fractions with millions of digits in both the numerator and
denominator, running slower and slower, for a number where the actual precision
was maybe three or four decimal places.

(2) Fractions didn't exist in the standard library when true division was
introduced.

(3) Fractions are slow to work with. They were even slower until a few years ago
when Python got a C accelerated version. Floats are much faster.

(4) For many purposes, the arbitrary precision of fractions is *spurious*
precision. Like the old saw says:

"Measure with micrometer, mark with chalk, cut with axe."

You're taking physical quantities which are typically measured to a precision of
three or four decimal places, if not less, then doing calculations on them to a
precision of potentially millions of decimal places. There may be a few places
where that is justified, but as the default behaviour, its spurious precision
and such overkill as to be ludicrous.

For most purposes, calculating with C doubles is more precision than you'll ever
need in a lifetime, and for the exceptions, well, if you're dealing with
use-cases that Double isn't enough for, you probably know enough to take
alternative steps.

(5) Most people are used to dealing with floating point numbers, from other
languages, from calculators, from school maths. Floats are quirky but familiar.

(6) Fractions are surprising and hard to deal with. Quickly now, without using a
calculator or Python, how big is this number?

2523720122311461/140737488355328

Is it more or less than 50?

Which would you rather see, the above fraction or its decimal equivalent,
17.93211?


But hey, if some languages (Lisp? Scheme?) want to use rationals instead of
floats as their default numeric type, more power to them.


>> Can you demonstrate any failure of dividing two ints n/m which wouldn't
>> equally fail if you 

Re: Old Man Yells At Cloud

[Chris Angelico]

On Sun, Sep 17, 2017 at 11:03 PM, Steve D'Aprano
 wrote:
> On Sun, 17 Sep 2017 08:43 pm, Chris Angelico wrote:
>
>> On Sun, Sep 17, 2017 at 5:54 PM, Steve D'Aprano
>>  wrote:
>>> To even *know* that there are branches of maths where int/int isn't defined,
>>> you need to have learned aspects of mathematics that aren't even taught in
>>> most undergrad maths degrees. (I have a degree in maths, and if we ever
>>> covered areas where int/int was undefined, it was only briefly, and I've 
>>> long
>>> since forgotten it.)
>>
>> How about this:
>>
> (1<<1)/2
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> OverflowError: integer division result too large for a float
>>
>> int/int is now undefined.
>
> No, it's perfectly defined: you get an overflow error if the arguments are too
> big to convert, or an underflow error if the denominator is too small, or a
> divide by zero error if you divide by zero...
>
>
> What do you make of this?
>
> py> float(1<<1)/2.0
> Traceback (most recent call last):
>   File "", line 1, in 
> OverflowError: int too large to convert to float
>
>
> Would you like to argue that this shows that coercing ints to floats
> is "undefined"?
>
>
> Overflow and underflow errors are limitations of the float data type. We could
> fix that in a couple of ways:
>
> - silently underflow to zero (as Python already does!) or infinity, as needed;
>
> - use a bigger ~~boat~~ float;
>
> - or even an arbitrary precision float;
>
> - or return a rational number (fraction or similar);
>
> - or introduce a float context that allows you to specify the behaviour
>   that you want, as the decimal module does.
>
> There may be other solutions I haven't thought of. But these will do.
>
> The distinction between Python floats and real numbers ℝ is a red-herring. It
> isn't relevant.

You said:

>>> (I have a degree in maths, and if we ever
>>> covered areas where int/int was undefined, it was only briefly, and I've 
>>> long
>>> since forgotten it.)

So what do YOU mean by "int/int" being "undefined"? And I referred to
real numbers because YOU referred to a degree in maths.

>> In Py2, it perfectly correctly returns
>> another integer (technically a long), but in Py3, it can't return a
>> float, so it errors out.
>
> Apart from your "correctly", which I disagree with, that's a reasonable
> description. The problem is that your example returns the correct result by
> accident. Forget such ludicrously large values, and try something more common:
>
> 1/2
>
> Most people aren't expecting integer division, but true division, and silently
> returning the wrong result (0 instead of 0.5) is a silent source of bugs.
>
> This isn't some theoretical problem that might, maybe, perhaps, be an issue 
> for
> some people sometimes. It was a regular source of actual bugs leading to code
> silently returning garbage.

So why doesn't it return a fractions.Fraction instead? That way, you
still get "one half" instead of zero, but it's guaranteed to be
accurate. And having 1/3 be a literal meaning "one third" would avoid
all the problems of "1/3 + 1/3 + 1/3 != 3/3". What is the
justification for int/int => float and not rational?

>> In Python 2 and 3, a small integer can be implicitly promoted to float:
>>
> user_input = 3.14159
> print(user_input + 1)
>> 4.14159
>
> Yes, as it should. Why force the user to call float() on one argument when the
> interpreter can do it? What advantage is there?
>
> Can you demonstrate any failure of dividing two ints n/m which wouldn't 
> equally
> fail if you called float(n)/float(m)? I don't believe that there is any such
> failure mode. Forcing the user to manually coerce to floats doesn't add any
> protection.

I don't think there is either, but by forcing people to coerce to
float, you force them to accept the consequences of floats. Again,
rationals (fractions.Fraction), implemented with a pair of
arbitrary-precision integers, are a superset of integers, so you can
genuinely upcast.

Upcasting from one type to a non-superset of that type is problematic.
Upcasting to a perfect superset isn't.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Steve D'Aprano]

On Sun, 17 Sep 2017 11:51 pm, Tim Golden wrote:

> Print-as-a-function removed one small simplicity 

Presumably you've never wanted to print to something other than std.out. The
syntax in Python 2 is horrid:

print >>sys.stderr, args

Presumably you've never wanted to print using a separator other than space. You
simply can't do it at all in Python 2.

Presumably you've never wanted to print and suppress the newline at the end of
the line. The Python 2 syntax is obscure, error-prone, and easy to miss:

print a, b, c, d,  # WOT?

Presumably you've never wanted to pass print to something as a function. It
can't be done in Python 2:

something.register(callback=print)  # SyntaxError

Presumably you've never wanted to control when the output buffer is flushed.
That's another thing you can't do in Python 2.

Presumably you've never wanted to monkey-patch an existing function that used
print by shadowing the built-in. You can't do that in Python 2, since print
isn't a regular name, it can't be mocked or shadowed or replaced.

I've wanted to do all those things, and more. I love the new print function. For
the cost of one extra character, the closing bracket, it gives you much, much
more than the old print statement ever did.

print(value, ..., sep=' ', end='\n', file=sys.stdout, flush=False)

No more cryptic and ugly syntax for printing to a file. Setting the argument
separator is easy. Instead of an obscure and easy to miss trick to suppress the
end of line, you use an obvious and self-explanatory keyword argument. The
function is easy to extend in the future with extra keyword arguments. It is
trivial to pass around, like any other function, and easy to mock or shadow.

The print statement was only good for the most simple uses. The print function
is a powerful, useful and first-class component of your programming toolbox.

[...]
> Funnily enough, the two arguments most often advanced for
> print-as-function seem to me to cancel each other out.

Arguments by whom?

There's a whole raft of things wrong with print as a statement. Arguably, none
of them *alone* are sufficient to condemn it, but overall, it makes the print
statement substandard. 


> Argument 1 is 
> "this way you can redefine print to be, eg, write_to_this_log"; and 
> Argument 2 is "but no-one uses print in real code anyway" -- more or
> less what Mark offered just now.

That second one is neither an argument in favour of changing print, nor correct.
People do use print in real code, but even if they didn't, that's not in and of
itself a reason to change print.


> Well if no-one uses it in real code, then its ability to be redefined is
> moot. (Or, rather, the strength of that argument is diminished).
> 
> In my own code I'm obviously quite capable of defining a function p()
> which does whatever I want in terms of printing etc.

Sure you can. But where the ability to mock print shines is when you're dealing
with an already existing function that you cannot change and that already uses
print.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Leam Hall]

Hmm... scratch the "young" and "Javascripters". Why lump them together 
since I bet it's just a vocal few? Better to have said "people who don't 
want to really learn the new language".


On 09/17/2017 06:03 AM, Leam Hall wrote:
Different view, I guess. I'm glad all the young Javascripters have that 
issue. As an old guy trying to re-learn more python it gives me an 
advantage. I'm usually interested in the best thislanguage-native way to 
do something. Doing so makes me learn the language faster and tends to 
generate better code.


That said, I'll often steal what I've learned before to understand the 
new. Some helpful folks on IRC asked why I was using getopt instead of 
argparse. Mostly because I come from a bash background. Looking at 
Python's argparse would have stumped me if I hadn't already done the 
same thing with Ruby's argparse.


I'm still trying to figure out how to convert a string to unicode in 
Python 2. I've done it in Ruby 1.8.7 so I assume Python 2 can do it and 
that I'm just a bit slow.


Leam

--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Abdur-Rahmaan Janhangeer]

as someone who really dislike js, i have to admit : python's globals are
really really bad !

js is a charm at that a real charm !

Abdur-Rahmaan Janhangeer,
Mauritius
abdurrahmaanjanhangeer.wordpress.com

On 16 Sep 2017 09:40, "Steve D'Aprano"  wrote:

> /rant on
>
> So apparently everyone who disagrees that Python should be more like
> Javascript
> is an old greybeard fuddy-duddy yelling "Get off my lawn!" to the cool
> kids --
> and is also too stupid to know how dumb they are.
>
> "Hi, I've been programming in Python for what seems like days now, and
> here's
> all the things that you guys are doing wrong. I insist that you fix them
> immediately, it doesn't matter how much code it will break, that's not
> important. What is important is that Javascript programmers like me
> shouldn't
> be expected to learn anything new or different when they program with
> Python."
>
> /rant off
>
> And no, for once it wasn't Ranting Rick.
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Leam Hall]

Different view, I guess. I'm glad all the young Javascripters have that 
issue. As an old guy trying to re-learn more python it gives me an 
advantage. I'm usually interested in the best thislanguage-native way to 
do something. Doing so makes me learn the language faster and tends to 
generate better code.


That said, I'll often steal what I've learned before to understand the 
new. Some helpful folks on IRC asked why I was using getopt instead of 
argparse. Mostly because I come from a bash background. Looking at 
Python's argparse would have stumped me if I hadn't already done the 
same thing with Ruby's argparse.


I'm still trying to figure out how to convert a string to unicode in 
Python 2. I've done it in Ruby 1.8.7 so I assume Python 2 can do it and 
that I'm just a bit slow.


Leam
--
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Steve D'Aprano]

On Sun, 17 Sep 2017 04:00 am, Stefan Ram wrote:

> Steve D'Aprano  writes:
>>"Hi, I've been programming in Python for what seems like days now, and here's
>>all the things that you guys are doing wrong.
> 
>   I never ever have written a line of Python 2. I started with
>   Python 3.6.0. Yet a very frequent mistake of mine is the
>   imission of parentheses after »print«.

That's remarkable.

Do you also forget the parentheses around `len`, and `iter`, and `math.sin()`?
If not, what's so special about print?

Javascript (at least the Rhino interpreter, if not others) includes a print
function. It too requires parentheses:

js> print 21
js: "", line 5: missing ; before statement
js: print 21
js: ...^
js> print(21)
21


>   WRT my other common errors, It thought of writing
>   a program that autocorrects my source code as follows:
[...]
>   Whenever the next line is indented more, add "def" to
>   what looks like a call (and does not start with »class«
>   or »def«;
> 
> f( x ):
> return x * x

Seriously Stefan, forgetting colons is one thing, but if you regularly forget to
start function definitions with "def", I fear that you're just not paying
attention to what you are doing.

Do you occasionally find yourself halfway down the street after leaving home
when you realise you're not wearing any pants? :-)



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[Tim Daneliuk]

On 09/16/2017 12:38 AM, Steve D'Aprano wrote:
> /rant on
> 
> So apparently everyone who disagrees that Python should be more like 
> Javascript
> is an old greybeard fuddy-duddy yelling "Get off my lawn!" to the cool kids --
> and is also too stupid to know how dumb they are.
> 
> "Hi, I've been programming in Python for what seems like days now, and here's
> all the things that you guys are doing wrong. I insist that you fix them
> immediately, it doesn't matter how much code it will break, that's not
> important. What is important is that Javascript programmers like me shouldn't
> be expected to learn anything new or different when they program with Python."
> 
> /rant off
> 
> And no, for once it wasn't Ranting Rick.
> 
> 
> 
> 

Well, the whole integer floor division thing years ago was the beginning
of the end - Python was doomed ...
-- 
https://mail.python.org/mailman/listinfo/python-list