Re: seeking deeper (language theory) reason behind Python design choice

[Ian Kelly]

On Thu, May 10, 2018 at 11:45 PM, Steven D'Aprano
 wrote:
> To be honest, I'm having trouble thinking of a good use-case for "while
> True", now that we have infinite iterators. Most cases of
>
> while True:
> x = get_item()
> if not x: break
> process(x)
>
> are better written as:
>
> for x in iterator:
> process(x)

x = get_item()
while True:
x = process(x)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: seeking deeper (language theory) reason behind Python design choice

[Ian Kelly]

On Thu, May 10, 2018 at 11:17 PM, Steven D'Aprano
 wrote:
> To answer your question from a later post:
>
> In what way does "while True" in the general case pretend
> to be an infinite loop?
>
> It doesn't *pretend* to be an infinite loop. It *is* an infinite loop
> which breaks out early.
>
> I realise that all infinite loops end up breaking out early, even if it's
> only when you power-cycle the device. But code ought to match intent, and
> "while condition which can never be false" shouts from the mountain tops
> that it is an infinite loop. The simpler the condition, the more loudly
> it shouts, and you can't get simpler than True.
>
> (The one thing that beats "while True" as an indicator of an infinite
> loop is the old Hypertalk syntax "repeat forever".)

How about the asyncio event loop's run_forever and run_until_complete
methods? run_forever also implies an infinite loop, except that you
can stop the event loop at any time. The other choice,
run_until_complete, requires that you already know when you want to
stop when you call it. Another way of looking at it, run_forever is
like a while loop and run_until_complete is like a for loop.

So if you know you want to stop the loop at some point, but you don't
know when, what do you do to express your intent?

> and if we came across it in real life, we'd surely question the sanity of
> the developer who wrote it. Why should while loops be any different?
>
> while True:
> if not condition: break  # equivalent to GOTO 99
> block
> LABEL 99
>
> I understand that *today*, using existing Python syntax, there is
> sometimes no avoiding that (except, possibly, with something worse). I
> get that. But if we had the choice to move the condition into the while
> condition, we ought to take it.

This is a straw man. As I already replied to Chris, this is not the
type of while True I've been arguing for. Obviously in this case the
condition should be moved into the while statement.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Print Failure or success based on the value of the standalone tool

[Chris Angelico]

On Fri, May 11, 2018 at 1:38 PM, Cameron Simpson  wrote:
> Returning to system() versus the subprocess module, there are other reasons
> to prefer the subprocess module. The biggest is that os.system() runs a
> shell command, a string passed to the programme /bin/sh. As such, that
> string is subject to all manner of syntax - anything the shell can
> understand.

Another good point about subprocess is that you can capture the OUTPUT
of the called command, not just its return value. Hence it is the
easiest and most obvious solution to the OP's problem - that
os.system() leaves the output going to the screen, and thus cannot
succeed or fail based on it.

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

Re: Suggestion for a "data" object syntax

[Ian Kelly]

On Mon, May 7, 2018 at 9:45 PM, Mikhail V  wrote:
> Here is an idea for 'data object' a syntax.
> For me it is interesting, how would users find such syntax.
> I personally find that this should be attractive from users
> perspective.
> Main aim is more readable presenting of typical data chunks
> and some typical data types (tuples/lists) directly in code.
> Further this should significantly simplify typing.
>
> *Example 1. Multi-line strings*
>
> Here is a 3 lines multi-line string, it will be automatically 'dedented'
> by the parser by one level of indent:
>
> data === S :
> this is multi-line string
> escape chars: same as in strings (\\, \\n, \\t ...) ,
> but "no need to 'escape' quotes"

My reaction #1: why 'S'? Python strings have a name: it's 'str'. They
don't need an additional, even more opaque name on top of that. If I
could go back in time and change the name of the type from 'str' to
'string', I would.

My reaction #2: what's the point of this construct? Python already has
multi-line strings that can be used as expressions, not as statements
only. Why do we need this syntax also? This is also not really
homomorphic with the proposed tuple syntax since that uses
tab-separated fields whereas this is just freeform text.

My reaction #3: Not a fan of adding an '===' operator. We already have
'=' and '=='. Javascript is another language that uses '===' to mean
something completely different from this proposal (it's another
equality operator) and it's a mess there. Come up with something else.

My reaction #4: Come to think of it, in keeping with other assigment
operators like '+=' and '*=' and '//=', if 'a === b' must exist then
it should mean 'a = a == b'. :-)

> *Example 2. Tuples*
>
> Tuple is a data block with normal Python elements.
>
> data === T :
> 123"hello"
> abc + d
>
> Here the separators of elements are : tab character,
> new line (and maybe some white-space character like em-space?)
> The above construct will be direct synonym for:
>
> data = (1, 2, 3, "hello", a, b, c + d)
>
> Benefits are easy to see: say I want a tuple of strings:
>
> data === T :
> "foo bar"
> "hello world"
> "to be continued..."
>
> VS current:
>
> data = (
> "foo bar" ,
> "hello world" ,
> "to be continued..." ,
> )
>
> Main problem with the latter are commas, it is not easy
> to type

In what bizarro world are commas harder to type than tabs? At least if
I type a comma I know I'll get a comma. If I type a tab then it
depends on my editor settings what I'll actually get.

> and, whats more important - hard to notice missing commas.

But it's totally easy to notice missing tabs, right? Not.

> And brackets of course does not make it nicer either.
>
> The above are typical cases where I see clear win, and
> IMO they are quite common constructs.
>
> More complicated examples :
>
>
> *Example 3. Two-dimensional tuple.*
>
> data === T/T :

What about T/S? S/T? S/S? Are these allowed? How would they work? I
hope you see my point from above about how these syntaxes are not
really homomorphic.

Also, why is there a division operator here?

> 123"hello"
> ab c + de f
>
> is a synonym for:
>
> data = (
> (1, 2, 3, "hello") ,
> (a, b, c + d, e, f ) )

If this is supposed to be a tabular format then why is the second row
allowed to have a different number of elements than the first row?

What about named fields? Is there a proposal for extending this syntax
to allow construction of dicts or namedtuples?

> The rule here is: TAB character is inner elements' separator, and the
> new line is outer elements' separator. Line continuation
> character is  \  (to help with long lines).

So brackets and commas are too ugly, but line continuation characters
are just fine?

> *The benefits is just as in above examples :
> readability and 'typeability' boost.*

Sorry, I don't see it. For presentation of data this may be fine, but
for code inside a program I'm much more interested in the organization
of the data than the data itself. Commas and brackets make the
organization clear. Tabs obscure it.

> *Main rules: *
> - the definition is allowed  only as a statement (no passing as argument)

Point for the existing syntax, which can be used as an expression.

> - (imo) data starts always as a new line after the header
> - implicit string concatenation disallowed

So this would be a syntax error?

foo === T:
"one" "two" "three"

That seems reasonable, but what about this?

foo === T/T:
"this is a very " \
"long string " \
"needing to be " \
"broken up over " \
"several lines"

> So the question is, how do you like such syntax

I see a lot of disadvantages and not many real advantages.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Meaning of abbreviated terms

[Steven D'Aprano]

On Fri, 11 May 2018 07:20:36 +, Bob Martin wrote:

> in 793605 20180511 044309 T Berger  wrote:
>>On Saturday, May 5, 2018 at 6:45:46 PM UTC-4, MRAB wrote:
>>> On 2018-05-05 17:57, T Berger wrote:
>>> > What does the "p" in "plist" stand for? Is there a python glossary
>>> > that spells out the meanings of abbreviated terms?
>>> >
>>> "plist" is "property list". It's listed in the Python documentation.
>>
>>Thanks for the answer. Missed it till now.
> 
> In IBM-speak it was parameter list.



But that's not where plists came from, was it? As I understand it, the 
plist data format was invented by Apple, and they called it a property 
list.


-- 
Steve

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

Re: Meaning of abbreviated terms

[Bob Martin]

in 793605 20180511 044309 T Berger  wrote:
>On Saturday, May 5, 2018 at 6:45:46 PM UTC-4, MRAB wrote:
>> On 2018-05-05 17:57, T Berger wrote:
>> > What does the "p" in "plist" stand for?
>> > Is there a python glossary that spells out the meanings of abbreviated 
>> > terms?
>> >
>> "plist" is "property list". It's listed in the Python documentation.
>
>Thanks for the answer. Missed it till now.

In IBM-speak it was parameter list.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Steven D'Aprano]

On Thu, 10 May 2018 23:23:33 -0600, Ian Kelly wrote:

> On Thu, May 10, 2018 at 9:21 PM, Steven D'Aprano
>  wrote:
>> On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed
>> prefixes for octal:
>>
>>> Personally I would have preferred the "t".
>>
>> "t" for octal, hey?
>>
>> That would be annoying if we ever get trinary literals.
>>
>> n for binary
>> t for octal
>> i for trinary
>> or should that be r for ternary?
>> o for duodecimal
> 
> I prefer it because it's the first letter of a syllable and it's not
> "o", not because it's the third letter of the word.

You should have said. Since you quoted the PEP, I inferred you were 
agreeing with the PEP's suggestion:

even to use a "t" for "ocTal" and an "n" for "biNary" to
go along with the "x" for "heXadecimal".

Note the "go along with". The X of hexadecimal, and the N of binary, are 
the *last* letter of a syllable, not the first, so I didn't think that 
"first letter of a syllable" was the rule you were applying. If it were, 
you would have picked "C" for oc-tal, not t.

So I guess the rule is:

"first letter of the word, if the word starts with
B, or the last letter of the first syllable, if the
syllable ends with X, or first letter of the second
syllable if it starts with C, or some random letter
so long as its not O"

:-)


> Most of those
> suggestions make no sense. Why would we ever want ternary literals
> anyway?

https://en.wikipedia.org/wiki/Ternary_numeral_system#Practical_usage



-- 
Steve

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

Re: Suggestion for a "data" object syntax

[Ian Kelly]

On Thu, May 10, 2018 at 6:34 PM, Mikhail V  wrote:
> On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano
>  wrote:
>> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote:
>>
>
>>> but I propose Tab-separated elements.
>>
>> We already have tab-separated elements in Python. It is allowed to use
>> tabs between any whitespace separated tokens.
>
> Yes, exactly. So in the proposed syntactic construct, it is *not*
> allowed to insert tabs between _any_ tokens.
> Namely if you will insert tabs _inside_ equations,
> like:
> a  + b

Then these are not ordinary expressions, are they? They're a different
type of expression and will require a modified parser. This adds
complexity.

>>> If I allow commas as well, this will become not so simple, probably.
>>> Also I don't propose syntax for e-mail code exchange, but rather syntax
>>> for *work* an this can potentially help a lot of people in everyday
>>> work.
>>
>> /head-desk
>>
>> You: "I have invented amazing new syntax that cannot be exchanged by
>> email. Here, let me email some examples to you."
>
> "GvR have invented amazing new syntax that cannot be preserved
> by sending it by e-mail"!
> (not me)
>
> Do you understand that basically any python code sent by e-mail converts tabs 
> to
> spaces, thus the only way to receive it - is to send binary file?

Um, no, this is false. We send Python code by email all the time.

There are essentially three cases of tabs that can occur in Python:

1) Tabs as indentation: Python permits the use of both tabs and spaces
as indentation, but it requires consistency; if one line is indented
with a tab and three spaces, then the next line in the same block must
also use a tab and three spaces. Therefore, if the tabs are converted
to spaces, they will be converted to the same number of spaces
throughout the block. Indents and dedents remain intact, indentation
is therefore not ruined, and the meaning of the program is not
changed.

2) Tabs as other whitespace: Other tabs in the program, such as in
expressions, don't matter at all. They can safely be replaced with
spaces, and the meaning of the program is not changed.

3) Tabs that appear in strings: This one I'll grant you. A replaced
tab inside a string may alter the meaning of the program. However,
note two things: tabs are rarely used in strings, and when they do
appear it's usual to write them as \t rather than with an actual tab
character.

In any case, the use of tabs is entirely optional. For the most part,
programs can be safely emailed whether they contain tabs or not, the
exception being tabs in strings which are better written as \t. In the
case of your proposed syntax however, the tabs are *required*, and it
is not possible to email a program containing such a construct at all.
Contrary to your assertion, this is *far* different from the status
quo.

>>> Also I don't know what kind of human thinks that this:
>>>  a + b
>>>  is two elements "a" and "+ b"
>>> What is "+ b"?
>>
>> It is unary plus followed by b.
>>
>> If you don't know Python's existing syntax, how can you possibly expect
>> to invent new syntax?
>
> Wow! Uncle Steven knows Python operators.
> My question was: why would you have "+ b" in
> the first place in your code? So you treat the worst-case scenario
> as a normal case - interesting approach  indeed!

When you're designing a language syntax, you need to account for *all*
the cases, not just the ones that you personally would use.

> By the way, since you are into unrealistic worst-case scenarios:
> Imagine you start with Python learning, how you'd like such constructs:
>
> L = [a + b, c, d]
> L = [a + b, (c, d)]
>
> For a starter, reading this will be quite painful.

I don't know, I find that much less painful than:

L === T:
a + b   c   d

> Yes, I have told already that there are _some_ cases when
>  tabulation formatting can cause visual confusion.
> *But why do you blame me*?
> It just the issues with editor's incompleteness.
> Simple feature like "set the minimal tab size" would have solved
> this issue by 100%. Maybe it even exists in some editors,
> I would not be surprised at least.

That's great, but if I'm editing a file on an embedded system over a
serial port and the only editor I have available is nano, I should be
able to use it. You can't just assume that everybody has a fully
featured editor (and knows how to use it -- what was that point you
made just above about beginners?)

>  I hope you are not seriously thinking that there is good syntax
>  that gives retro-tools, wacky people, not wacky people,
>  pros, etc. same opportunities.

Why not? The existing Python syntax is fine for this.

> For instance, there is real demand on adding new control characters
> to syntax, so as IDE developers can utilize those for making
> better user experience. If you apply same one-sided principles here
> then you behave good to one group of people, but just ignorant
> to other group of people who want better new experienc

Re: seeking deeper (language theory) reason behind Python design choice

[Steven D'Aprano]

On Thu, 10 May 2018 20:38:39 -0600, Ian Kelly wrote:

> Would you also contend that generator functions are wrong because they
> pretend to be normal functions?

You're going to need to be more specific. In what way are they not normal 
functions? You call them like normal functions, providing arguments like 
normal functions, and receiving a result just like normal functions.

If you call a function like iter(), you also get back an iterator, just 
as you do when you call a generator. Is iter() not a normal function?

We also call classes, and callable instances, as if they were normal 
functions. Is that also a problem?

I guess the answer depends on what we mean by "function":

- an instance of FunctionType

- a thing we call to get back a result

or possibly both, as context requires.


> def totally_not_a_generator(n):
> while True:
> if n % 2 == 0:
> n //= 2
> else:
> n = n * 3 + 1
> stealthily = n
> yield stealthily
> if n == 1:
> return n

I must admit, I'm a little perplexed. In what way is this totally not a 
generator? (To be precise, a generator function.) The inspect module 
thinks it is (and so do I): 

py> inspect.isgeneratorfunction(totally_not_a_generator)
True

as well as a function:

py> inspect.isfunction(totally_not_a_generator)
True


It's not a *generator object*, but it returns one:


py> inspect.isgenerator(totally_not_a_generator)
False
py> inspect.isgenerator(totally_not_a_generator(99))
True


-- 
Steve

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

Re: seeking deeper (language theory) reason behind Python design choice

[Steven D'Aprano]

On Fri, 11 May 2018 05:17:59 +, Steven D'Aprano wrote:

> On Fri, 11 May 2018 03:29:57 +0300, Marko Rauhamaa wrote:
[...]
> To answer your question from a later post:
> 
> In what way does "while True" in the general case pretend to be an
> infinite loop?

Oops, sorry, that was Ian Kelly who asked that, not Marko.



-- 
Steve

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

Re: seeking deeper (language theory) reason behind Python design choice

[Steven D'Aprano]

On Fri, 11 May 2018 01:51:47 +0300, Marko Rauhamaa wrote:

> Paul Rubin :
> 
>> Marko Rauhamaa  writes:
>>> It turns out "while True" is the most natural choice in about half of
>>> the while loops.
>>
>> Maybe the rest would be "repeat until" if Python had that?
> 
> No. "Repeat until" is a relatively infrequent need.

And again, YMMV. In my experience, most "while True" loops would be 
better off written as a "repeat... until True" loop. But since Python 
doesn't have syntax for such repeat until loops, our work-around is to 
use a while True and break out of it at the end of the loop.

To be honest, I'm having trouble thinking of a good use-case for "while 
True", now that we have infinite iterators. Most cases of

while True:
x = get_item()
if not x: break
process(x)

are better written as:

for x in iterator:
process(x)



-- 
Steve

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Gene Heskett]

On Thursday 10 May 2018 23:21:11 Steven D'Aprano wrote:

> On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed
>
> prefixes for octal:
> > Personally I would have preferred the "t".
>
> "t" for octal, hey?
>
> That would be annoying if we ever get trinary literals.
>
> n for binary
> t for octal
> i for trinary
> or should that be r for ternary?
> o for duodecimal
>
> and of course, x for hexadecimal.
>
> I can just imagine the Stackoverflow posts now...
>
>
> --
> Steve

We'll all be needing nomex underwear I fear.


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Ian Kelly]

On Thu, May 10, 2018 at 9:21 PM, Steven D'Aprano
 wrote:
> On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed
> prefixes for octal:
>
>> Personally I would have preferred the "t".
>
> "t" for octal, hey?
>
> That would be annoying if we ever get trinary literals.
>
> n for binary
> t for octal
> i for trinary
> or should that be r for ternary?
> o for duodecimal

I prefer it because it's the first letter of a syllable and it's not
"o", not because it's the third letter of the word. Most of those
suggestions make no sense. Why would we ever want ternary literals
anyway?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Print Failure or success based on the value of the standalone tool

[Cameron Simpson]

On 11May2018 06:53, Ganesh Pal  wrote:

On Thu, May 10, 2018, 22:31 Rob Gaddi

By not using os.system, it's been superseded for reasons exactly like
yours.  https://docs.python.org/3/library/subprocess.html is your friend.


Can someone please help me understand this better for me with a program .
Will the  returncode of subprocess still not be  0 or -ve number ?

My requirement is let the  test_standalone_tool.py script which is a
wrapper around standalone_tool.py print pass /fail based on the possible
values I.e True , False and None

I'm not sure weather if I need to i.e replace os.system with subprocess or
make changes in standalone_tool.py to return 0 or -1( use sys.exit())


Your problem is with standalone_tool.py. os.system() returns the exit status of 
the shell which ran your command, and that is in turn the exit status of the 
last command the shell ran i.e. your command.


Your problem is that standalone_tool.py does not return a relevant exit status.  
As far as Python is concerned your script ran to completion and Python returns 
an exit status of 0 unless you arrange otherwise.


Consider this small script:

 #!/usr/bin/python

 import sys

 def func():
   return 1

 if func() == 1:
   # indicate success as an exit status
   sys.exit(0)
 else:
   # indicate failure as an exit status
   sys.exit(1)

Your script doesn't call sys.exit(), and as such, unless it outright aborts 
(for example, from an exception) Python itself returns a 0 exit status.  
Therefore your standalone_tool.py always has an exit status of 0. Make a 
suitable call to sys.exit() at the end to return a meaningful exit status.


Returning to system() versus the subprocess module, there are other reasons to 
prefer the subprocess module. The biggest is that os.system() runs a shell 
command, a string passed to the programme /bin/sh. As such, that string is 
subject to all manner of syntax - anything the shell can understand.


For example, if you wanted to pass a filename as an argument to your script you 
would need to ensure that nothing in the filename could be misinterpreted as 
punctuation. For example, a filename containing spaces would be handled as 2 
distinct arguments by the shell unless you quote the name.


Using the subprocess module you can pass such items directly to your script 
instead of going _through_ the shell as an intermediate command. Compare:


 import os
 import subprocess

 os.system('standalone_tool.py my-filename-here')
 subprocess.run(['standalone_tool.py', 'my-filename-here'])

The former invokes the shell (/bin/sh) with the string 'standalone_tool.py 
my-filename-here', which the shell interprets. The latter directly runs your 
script.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: seeking deeper (language theory) reason behind Python design choice

[Steven D'Aprano]

On Fri, 11 May 2018 03:29:57 +0300, Marko Rauhamaa wrote:

>> Now do you understand what I mean about putting the condition into the
>> loop header?
> 
> Thanks, but no thanks. The "while True" idiom beats that one hands down.

Why do you think it is better to lie to the reader and tell them they are 
entering an infinite loop, only to later on say "Ha ha, fooled you!"?

It doesn't matter whether it is one line later, or sixteen pages later. 
The initial "while True" suggests an infinite loop, because the loop 
condition is *always* True, so the loop never ends.

To answer your question from a later post:

In what way does "while True" in the general case pretend
to be an infinite loop?

It doesn't *pretend* to be an infinite loop. It *is* an infinite loop 
which breaks out early.

I realise that all infinite loops end up breaking out early, even if it's 
only when you power-cycle the device. But code ought to match intent, and 
"while condition which can never be false" shouts from the mountain tops 
that it is an infinite loop. The simpler the condition, the more loudly 
it shouts, and you can't get simpler than True.

(The one thing that beats "while True" as an indicator of an infinite 
loop is the old Hypertalk syntax "repeat forever".)

If we want to communicate the intent of our code, the while-condition 
ought to be in the loop header *if possible*. (I appreciate it isn't 
always possible.)

We wouldn't write this:

# let's pretend we have GOTO
if True:
if not condition: GOTO 99
block
LABEL 99


and if we came across it in real life, we'd surely question the sanity of 
the developer who wrote it. Why should while loops be any different?

while True:
if not condition: break  # equivalent to GOTO 99
block
LABEL 99

I understand that *today*, using existing Python syntax, there is 
sometimes no avoiding that (except, possibly, with something worse). I 
get that. But if we had the choice to move the condition into the while 
condition, we ought to take it.


> As for the "is not None" test, I generally want to make it explicit
> because
> 
>  1. that's what I mean and
> 
>  2. there's a chance in some context of confusing None with other falsey
> values.

Indeed #2 is correct, and of course *in general* we ought to be explicit 
when testing for None. But in the case of regexes, I doubt that testing 
for None is *actually* what you mean. It's merely what you *think* you 
mean *wink*

To be precise, the rule is that re.match() returns a true object (a 
MatchObject) if the search succeeded, and a false object (documented as 
None) if it fails. But we surely don't care that the failure case is 
*specifically* None. It should make no difference at all if re.match() 
returned False instead, or a falsey MatchObject with all fields left 
empty, since we never use it.

So we ought not care that it is specifically None.

Testing for None particularly makes sense if you need a sentinel and:

- you don't distinguish between truthy and falsey values at all;

- or you want to distinguish between truthy values, falsey values,
  and leave None to stand in for things which are neither ("maybe"?).

The re.match case doesn't meet either of those conditions.

Of course, none of this is to say that testing for None is "wrong". 
re.match is documented as returning None, and a backwards-incompatible 
change is exceedingly unlikely. So you're safe there. It's just 
unnecessary.



-- 
Steve

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

Re: Meaning of abbreviated terms

[T Berger]

On Saturday, May 5, 2018 at 6:45:46 PM UTC-4, MRAB wrote:
> On 2018-05-05 17:57, T Berger wrote:
> > What does the "p" in "plist" stand for?
> > Is there a python glossary that spells out the meanings of abbreviated 
> > terms?
> > 
> "plist" is "property list". It's listed in the Python documentation.

Thanks for the answer. Missed it till now.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: seeking deeper (language theory) reason behind Python design choice

[Steven D'Aprano]

On Thu, 10 May 2018 22:59:03 +0300, Marko Rauhamaa wrote:

> It turns out "while True" is the most natural choice in
> about half of the while loops.


YMMV.

In my case, it is more like about one in ten.




-- 
Steve

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Steven D'Aprano]

On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed 
prefixes for octal:

> Personally I would have preferred the "t".

"t" for octal, hey?

That would be annoying if we ever get trinary literals.

n for binary
t for octal
i for trinary
or should that be r for ternary?
o for duodecimal

and of course, x for hexadecimal.

I can just imagine the Stackoverflow posts now...


-- 
Steve

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Steven D'Aprano]

On Thu, 10 May 2018 17:36:39 +0100, bartc wrote:

> I wonder why someone would take a feature generally agreed to be a
> poorly designed feature of C, and incorporate it into a new language.

Because in 1991 or thereabouts, when Guido was designing the language for 
the first time, he thought it was a good idea since Python was intended 
to be a glue language to act as an interface to C libraries, and he 
probably imagined it would mostly be used by people familiar with C.

In hindsight that turned out to be one of the less great ideas, but the 
only people who have no bad ideas are those who have no ideas at all.


>> That changed in Python 3. If you slim
>> the start of PEP 3127, you'll learn the new notation.
> 
> What, 0O100 instead of 0100? Yeah that's a big improvement...

Then write it as 0o100 like sensible people do.


> Fortunately octal doesn't get used much.

Indeed.


-- 
Steve

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Bob van der Poel]

On Thu, May 10, 2018 at 6:36 PM, Gene Heskett  wrote:

> On Thursday 10 May 2018 20:55:58 bartc wrote:
>
> > On 11/05/2018 01:25, Marko Rauhamaa wrote:
> > > Chris Angelico :
> > >> Octal makes a lot of sense in the right contexts.
> > >
> > > I think octal is a historical relic from a time when people weren't
> > > yet comfortable with hexadecimal.
> >
> > It's a relic from when machines had word sizes that were multiples of
> > three bits, or were divided up on 3-bit boundaries.
> >
> > --
> > bartc
>
> Maybe so, but isn't it time to fix that?  The first "computer" I ever got
> to take home and learn how it worked, was a Quest Super Elf, had an RCA
> 1802 processor on it. This was winter of 77-78, and it had a monitor
> that spoke hexidecimal. I spent that winter exploring it before I set
> out to write the program it would run until June 30th 2008 when we
> switched from Never Twice Same Color to digital.
>
> So other than the *nix chmod, and some similar stuff in
> os9/nitros9/amigados, I have never had to deal with octal. I'm sure the
> security people would be pleased if another bit could be expanded into
> the permissions that chmod controls, so lets deprecate octal and be done
> with it. Computers haven't read a single 8 bit byte in years, some
> reading 128 or 256 bits in a single read cycle today. Bring the language
> into the 21st century.
>
> Its a dirty job, but somebody will have to do it eventually, why not now?
>

I agree with my freind Gene! And, if it is really necessary to retain
octal, why not preface it with anything BUT a "0". I've been hit by this a
few times in the past. I used lots of hex over the years, but don't recall
ever using octal ... except in frustrating moments when I needed to change
permission bits.

-- 

 Listen to my FREE CD at http://www.mellowood.ca/music/cedars 
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: b...@mellowood.ca
WWW:   http://www.mellowood.ca
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: seeking deeper (language theory) reason behind Python design choice

[Ian Kelly]

On Thu, May 10, 2018 at 7:10 PM, Chris Angelico  wrote:
> On Fri, May 11, 2018 at 10:29 AM, Marko Rauhamaa  wrote:
>> Chris Angelico :
>>
>>> But for the loop itself, you absolutely CAN write this more logically.
>>> I'll take your second version as a template:
>>>
>>> def split_cmd(self, cmd):
>>> args = []
>>> while (match := self.TERM_PTN.match(cmd)) is not None:
>>> args.append(match.group('term'))
>>> if not match.group('sep'):
>>> verb = args.pop(0).upper()
>>> return verb, args
>>> cmd = cmd[match.end(0):]
>>> return None, None
>>>
>>> And, if this is actually a regex, "is not None" is unnecessary:
>>>
>>> while match := self.TERM_PTN.match(cmd):
>>>
>>> Now do you understand what I mean about putting the condition into the
>>> loop header?
>>
>> Thanks, but no thanks. The "while True" idiom beats that one hands down.
>
> Because you're used to it? Or because it's somehow more logical to
> pretend that this is an infinite loop? Explain in more detail.

In what way does "while True" in the general case pretend to be an
infinite loop? The break / return is right there for anyone to see.

Would you also contend that generator functions are wrong because they
pretend to be normal functions?

def totally_not_a_generator(n):
while True:
if n % 2 == 0:
n //= 2
else:
n = n * 3 + 1
stealthily = n
yield stealthily
if n == 1:
return n

py> print(totally_not_a_generator(42))  # Lies!

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

Re: seeking deeper (language theory) reason behind Python design choice

[Ian Kelly]

On Tue, May 8, 2018 at 11:50 PM, Chris Angelico  wrote:
> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly  wrote:
>>
>> while True:
>> if we_are_done():
>> break
>> # do some stuff
>> ...
>> if error_occurred():
>> break
>> notify_user()
>>
>>
>> Fixed, using idiomatic Python and without needing to use assignment in
>> an expression.
>
> Why is it that "while True" is idiomatic Python for a non-infinite
> loop? Is it merely because Python currently has no other way to spell
> certain loops? Surely it would be more idiomatic to encode the loop's
> termination condition in the header, if it were possible.

In the case of the code above you're correct; the condition could be
moved directly into the while. The loop that I adapted first assigned
we_are_done() to flag and then asserted that flag would be checked
again later. I neglected to maintain this part when I rewrote it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Chris Angelico]

On Fri, May 11, 2018 at 11:36 AM, Gene Heskett  wrote:
> So other than the *nix chmod, and some similar stuff in
> os9/nitros9/amigados, I have never had to deal with octal. I'm sure the
> security people would be pleased if another bit could be expanded into
> the permissions that chmod controls, so lets deprecate octal and be done
> with it.

What do you mean, "another bit"? Currently, the chmod command on my
system can manage nine primary bits (rwx for each of ugo), plus
setuid, setgid, and sticky. Plus there's a flag for "this is a
symbolic link" and another for "this is a directory", and at least one
or two for devices.

> Computers haven't read a single 8 bit byte in years, some
> reading 128 or 256 bits in a single read cycle today. Bring the language
> into the 21st century.

Remind me how you parse an IP packet (v4 or v6). Do you work with 256
bits at a time?

And if you say "nobody parses network packets in Python", it's a lot
more likely that you'll do network debugging in Python than that
you'll care how exactly your CPU retrieves data from DRAM.

Marking octal literals with "0o" was the right decision. Excising
octal from the language would not be.

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Gene Heskett]

On Thursday 10 May 2018 20:55:58 bartc wrote:

> On 11/05/2018 01:25, Marko Rauhamaa wrote:
> > Chris Angelico :
> >> Octal makes a lot of sense in the right contexts.
> >
> > I think octal is a historical relic from a time when people weren't
> > yet comfortable with hexadecimal.
>
> It's a relic from when machines had word sizes that were multiples of
> three bits, or were divided up on 3-bit boundaries.
>
> --
> bartc

Maybe so, but isn't it time to fix that?  The first "computer" I ever got 
to take home and learn how it worked, was a Quest Super Elf, had an RCA 
1802 processor on it. This was winter of 77-78, and it had a monitor 
that spoke hexidecimal. I spent that winter exploring it before I set 
out to write the program it would run until June 30th 2008 when we 
switched from Never Twice Same Color to digital.

So other than the *nix chmod, and some similar stuff in 
os9/nitros9/amigados, I have never had to deal with octal. I'm sure the 
security people would be pleased if another bit could be expanded into 
the permissions that chmod controls, so lets deprecate octal and be done 
with it. Computers haven't read a single 8 bit byte in years, some 
reading 128 or 256 bits in a single read cycle today. Bring the language 
into the 21st century.

Its a dirty job, but somebody will have to do it eventually, why not now?

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Print Failure or success based on the value of the standalone tool

[Ganesh Pal]

On Thu, May 10, 2018, 22:31 Rob Gaddi

>
>
> By not using os.system, it's been superseded for reasons exactly like
> yours.  https://docs.python.org/3/library/subprocess.html is your friend.
>

Can someone please help me understand this better for me with a program .
Will the  returncode of subprocess still not be  0 or -ve number ?

My requirement is let the  test_standalone_tool.py script which is a
wrapper around standalone_tool.py print pass /fail based on the possible
values I.e True , False and None

I'm not sure weather if I need to i.e replace os.system with subprocess or
make changes in standalone_tool.py to return 0 or -1( use sys.exit())

Regards,
Ganesh
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: seeking deeper (language theory) reason behind Python design choice

[Chris Angelico]

On Fri, May 11, 2018 at 10:29 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> But for the loop itself, you absolutely CAN write this more logically.
>> I'll take your second version as a template:
>>
>> def split_cmd(self, cmd):
>> args = []
>> while (match := self.TERM_PTN.match(cmd)) is not None:
>> args.append(match.group('term'))
>> if not match.group('sep'):
>> verb = args.pop(0).upper()
>> return verb, args
>> cmd = cmd[match.end(0):]
>> return None, None
>>
>> And, if this is actually a regex, "is not None" is unnecessary:
>>
>> while match := self.TERM_PTN.match(cmd):
>>
>> Now do you understand what I mean about putting the condition into the
>> loop header?
>
> Thanks, but no thanks. The "while True" idiom beats that one hands down.

Because you're used to it? Or because it's somehow more logical to
pretend that this is an infinite loop? Explain in more detail.

> As for the "is not None" test, I generally want to make it explicit
> because
>
>  1. that's what I mean and
>
>  2. there's a chance in some context of confusing None with other falsey
> values.
>

With the standard library re module, there is no such chance. So it's
pointlessly explicit about something that won't ever happen.

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Chris Angelico]

On Fri, May 11, 2018 at 10:25 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> Octal makes a lot of sense in the right contexts.
>
> I think octal is a historical relic from a time when people weren't yet
> comfortable with hexadecimal.

And any other situation where it makes more sense to group bits into
threes instead of fours. For instance, if you have a six-bit byte,
there's no point using hex. Or if you're working with seven-bit bytes
and use the high bit as a continuation marker.

>> Allowing octal literals is a Good Thing.
>
> I think it's just unavoidable mainly because of os.chmod.

And a variety of other contexts. Yes, chmod is probably the only one
that typical people will come across, but atypical people who read
packet diagrams are just as likely to group bits in other ways than
octets.

If you were to create a new programming language _today_, you MIGHT be
able to get away with not having any form of octal literal (and force
people to use something like int("100644", 8) to define file modes).
Emphasis on might. For any language that's been around for 20+ years,
octal was too important to not retain, and too useful even today to
discard as a mere historical relic.

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[bartc]

On 11/05/2018 01:25, Marko Rauhamaa wrote:

Chris Angelico :


Octal makes a lot of sense in the right contexts.


I think octal is a historical relic from a time when people weren't yet
comfortable with hexadecimal.


It's a relic from when machines had word sizes that were multiples of 
three bits, or were divided up on 3-bit boundaries.


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

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano
 wrote:
> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote:
>

>> but I propose Tab-separated elements.
>
> We already have tab-separated elements in Python. It is allowed to use
> tabs between any whitespace separated tokens.

Yes, exactly. So in the proposed syntactic construct, it is *not*
allowed to insert tabs between _any_ tokens.
Namely if you will insert tabs _inside_ equations,
like:
a  + b

Then it will not work (it will parse 2 elements) .

So -  the simple answer, which follows directly from the
proposal: no, you don't insert tabs inside equations in this construct.
In simple words, if you want to do it nevertheless - this proposal is
not for you.

*But I am glad that at least you have managed to formulate your concern
finally,  thanks.*


>> If I allow commas as well, this will become not so simple, probably.
>> Also I don't propose syntax for e-mail code exchange, but rather syntax
>> for *work* an this can potentially help a lot of people in everyday
>> work.
>
> /head-desk
>
> You: "I have invented amazing new syntax that cannot be exchanged by
> email. Here, let me email some examples to you."

"GvR have invented amazing new syntax that cannot be preserved
by sending it by e-mail"!
(not me)

Do you understand that basically any python code sent by e-mail converts tabs to
spaces, thus the only way to receive it - is to send binary file?

Maybe you should've made more influence on that in the past and now we
all would have to use spaces only to format the code.
Also maybe include C-brackets so as not to worry when e-mail clients
add extra spaces in front of lines?


>> Also I don't know what kind of human thinks that this:
>>  a + b
>>  is two elements "a" and "+ b"
>> What is "+ b"?
>
> It is unary plus followed by b.
>
> If you don't know Python's existing syntax, how can you possibly expect
> to invent new syntax?

Wow! Uncle Steven knows Python operators.
My question was: why would you have "+ b" in
the first place in your code? So you treat the worst-case scenario
as a normal case - interesting approach  indeed!

By the way, since you are into unrealistic worst-case scenarios:
Imagine you start with Python learning, how you'd like such constructs:

L = [a + b, c, d]
L = [a + b, (c, d)]

For a starter, reading this will be quite painful.

Yes, I have told already that there are _some_ cases when
 tabulation formatting can cause visual confusion.
*But why do you blame me*?
It just the issues with editor's incompleteness.
Simple feature like "set the minimal tab size" would have solved
this issue by 100%. Maybe it even exists in some editors,
I would not be surprised at least.

 I hope you are not seriously thinking that there is good syntax
 that gives retro-tools, wacky people, not wacky people,
 pros, etc. same opportunities.

For instance, there is real demand on adding new control characters
to syntax, so as IDE developers can utilize those for making
better user experience. If you apply same one-sided principles here
then you behave good to one group of people, but just ignorant
to other group of people who want better new experience.

Seriously, your sarcasm is pretty one-sided.
You should try to think a bit wider.


>> I don't want spaces or tabs visible - there is toggle "show tabs"
>> and "toggle show space" for that
>
> /head-desk
>
> You: "This syntax doesn't need tabs and spaces to be visible. Just use
> the Show Tabs and Show Spaces commands on your editor to make them
> visible."

Yep!  Just toggle them if you want to find out. That's a good feature!

And you know, **head-desk'ing too often (and without reason) may
be not good to you.**
We need healthy Steven.


>
>>> Using a particular editor is not and will not be a mandatory
>>> requirement for Python.
>>
>> Using outdated tools or being PEBCAK are not and will not be
>> justification for language syntax improvements.
>
> It is not your choice of what editors people are permitted to use in
> order to read and write Python.

Yeah, but most people do not want to sit with technologies from 80's,
especially when many new possibilities are already available.
And that's why the scene of editors is changing so fast,
there is a lot that makes it easier to work.


>>> - the first one can include nested data structures, while
>>>   the second cannot.
>>
>> Why it can't? did you read the original e-mail?
>
> Of course I did. You said:
>
> "So the idea is to cover only first two levels of
> nesting of course."
>
> With bracket syntax, I can cover unlimited levels of nesting. Yours
> cannot.

Ok, that was a typo, it must be:

"So the idea is to _hide brackets for_ first two levels of
nesting of course."

Thanks for noticing. So it can, but that's not an easy one to
implement.



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

Re: seeking deeper (language theory) reason behind Python design choice

[Marko Rauhamaa]

Chris Angelico :

> But for the loop itself, you absolutely CAN write this more logically.
> I'll take your second version as a template:
>
> def split_cmd(self, cmd):
> args = []
> while (match := self.TERM_PTN.match(cmd)) is not None:
> args.append(match.group('term'))
> if not match.group('sep'):
> verb = args.pop(0).upper()
> return verb, args
> cmd = cmd[match.end(0):]
> return None, None
>
> And, if this is actually a regex, "is not None" is unnecessary:
>
> while match := self.TERM_PTN.match(cmd):
>
> Now do you understand what I mean about putting the condition into the
> loop header?

Thanks, but no thanks. The "while True" idiom beats that one hands down.

As for the "is not None" test, I generally want to make it explicit
because

 1. that's what I mean and

 2. there's a chance in some context of confusing None with other falsey
values.


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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Marko Rauhamaa]

Chris Angelico :

> Octal makes a lot of sense in the right contexts.

I think octal is a historical relic from a time when people weren't yet
comfortable with hexadecimal.

> Allowing octal literals is a Good Thing.

I think it's just unavoidable mainly because of os.chmod.


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

Re: seeking deeper (language theory) reason behind Python design choice

[Chris Angelico]

On Fri, May 11, 2018 at 8:49 AM, Marko Rauhamaa  wrote:
> def split_cmd(self, cmd):
> args = []
> while True:
> match = self.TERM_PTN.match(cmd)
> if match is None:
> return None, None
> args.append(match.group('term'))
> if not match.group('sep'):
> break
> cmd = cmd[match.end(0):]
> verb = args.pop(0).upper()
> return verb, args
>
> You *could* get rid of True. For example:

Yes, you could. For a start, you'd want to add a docstring so someone
else can figure out what on earth is going on here. For instance, I
don't understand why, even after iterating several times, a regex
match failure instantly results in you returning (None, None); is that
an error condition? If so, why is it not raising an exception? What
kind of regex is this (at least, it looks like you're doing regex
work), and can you use re.split() instead of all this? Why are you
uppercasing the verb? Why an ALL_CAPS name (usually a constant) being
referenced from an object (self)? So much of this doesn't look even
slightly Pythonic.

But for the loop itself, you absolutely CAN write this more logically.
I'll take your second version as a template:

def split_cmd(self, cmd):
args = []
while (match := self.TERM_PTN.match(cmd)) is not None:
args.append(match.group('term'))
if not match.group('sep'):
verb = args.pop(0).upper()
return verb, args
cmd = cmd[match.end(0):]
return None, None

And, if this is actually a regex, "is not None" is unnecessary:

while match := self.TERM_PTN.match(cmd):

Now do you understand what I mean about putting the condition into the
loop header?

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Chris Angelico]

On Fri, May 11, 2018 at 8:43 AM, bartc  wrote:
> This is Wrong, and would have been just as obviously wrong in 1989.

Having spent many years programming in C and working on Unix, I
strongly disagree. This was *not* obviously wrong. It's easy to say
"but look at the real world"; but in the 80s and 90s, nobody would
have said that it was "obviously wrong" to have the native integer
wrap when it goes past a certain number of bits. And in fact, your
description of the real world makes it equally obvious that numbers
should have a fixed width:

> If my car odometer says 075300, it means I've done 75,300 miles or km, not 
> 31424

You might actually have done 1,075,300 ticks, or 2,075,300, or any
other number that ends with those six digits. That's OBVIOUSLY right,
because you can look at your odometer or a pocket calculator and see
that numbers don't need to have infinite precision.

Octal makes a lot of sense in the right contexts. Allowing octal
literals is a Good Thing. And sticking letters into the middle of a
number doesn't make that much sense, so the leading-zero notation is a
decent choice. It's all very well to argue that it's a suboptimal
choice; but you have to remember that you're arguing that point from
2018, and we have about thirty years of experience using Python. The
choice was most definitely not fundamentally wrong. Ten years ago, the
point was revisited, and a different choice made. That's all.

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

Re: seeking deeper (language theory) reason behind Python design choice

[Marko Rauhamaa]

Paul Rubin :

> Marko Rauhamaa  writes:
>> It turns out "while True" is the most natural choice in about half of
>> the while loops.
>
> Maybe the rest would be "repeat until" if Python had that?

No. "Repeat until" is a relatively infrequent need.


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

Re: seeking deeper (language theory) reason behind Python design choice

[Marko Rauhamaa]

Chris Angelico :
> On Fri, May 11, 2018 at 5:59 AM, Marko Rauhamaa  wrote:
>> Joking aside, to answer Chris's question, of course you can use a
>> real condition with "while". However, you shouldn't force it or try
>> to avoid "while True". It turns out "while True" is the most natural
>> choice in about half of the while loops.
>
> So if I understand you correctly, you're saying that a real condition
> is better, but "while True" is the best option half the time. In other
> words, "while True" is the ONLY option half the time, since any other
> option would be better.

A real example:

def split_cmd(self, cmd):
args = []
while True:
match = self.TERM_PTN.match(cmd)
if match is None:
return None, None
args.append(match.group('term'))
if not match.group('sep'):
break
cmd = cmd[match.end(0):]
verb = args.pop(0).upper()
return verb, args

You *could* get rid of True. For example:

def split_cmd(self, cmd):
args = []
match = self.TERM_PTN.match(cmd)
while match is not None:
args.append(match.group('term'))
if not match.group('sep'):
verb = args.pop(0).upper()
return verb, args
cmd = cmd[match.end(0):]
match = self.TERM_PTN.match(cmd)
return None, None

However, that would be a slight stylistic degradation because

 1. the redundant matching statement is redundant and

 2. an abnormal return is at the bottom of the function.


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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[bartc]

On 10/05/2018 18:58, Skip Montanaro wrote:

I wonder why someone would take a feature generally agreed to be a
poorly designed feature of C, and incorporate it into a new language.


I think you might be looking at a decision made in the late 1980s through a
pair of glasses made in 2018.

As a C programmer back then I never had a problem with C's octal number
notation. People coming from C, C++ or Java to Python at that time would
certainly have understood that syntax. It's only in the past 15 years or so
that we've seen tons of people coming to Python as a first language for
whom leading zero notation would be unfamiliar.


I'm pretty sure I would have had exactly the same opinion in 1989.

Decimal numbers in code should reflect their usage in everyday life as 
much as possible.


And in everyday life, leading zeros do not change the base of a number 
so that it becomes octal. If my car odometer says 075300, it means I've 
done 75,300 miles or km, not 31424:


   mileages = ( # python 2
215820,
121090,
075300,
005105)

   for m in mileages:
print m,"miles"

Output:

   215820 miles
   121090 miles
   31424 miles
   2629 miles

This is Wrong, and would have been just as obviously wrong in 1989.

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

Re: seeking deeper (language theory) reason behind Python design choice

[Peter Pearson]

On Wed, 09 May 2018 12:51:15 -0700, Paul Rubin wrote:
> Dennis Lee Bieber  writes:
>>  Yes, code reviews may catch such errors... and later, when the
>> summary of errors is analyzed for suggestions on how to reduce them --
>> the odds are good that "assignment expressions" will be banned in the
>> style documents for that language at the company.
>
> I don't think I've worked on any C programs with that style restriction
> and I can't think of any times when I found that type of bug in deployed
> code.  I've made the error once or twice while coding, but caught it
> right away during inspection or testing.  Banning it seems
> counterproductive.  I could imagine having it flagged by a compiler
> warning that can be locally disabled by a pragma.  

Interestingly, the problem is broader than inadvertently making the
mistake yourself; it includes catching deliberate misdirection by
others.  In the famous "Linux Backdoor Attempt of 2003"
(https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/),
somebody who I think never got caught introduced these lines
into the code for the wait4 function:

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;

Setting the user ID to zero confers root privileges.

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[bartc]

On 10/05/2018 19:51, Chris Angelico wrote:

On Fri, May 11, 2018 at 4:31 AM, bartc  wrote:

   2x100  (4)   Binary
   3x100  (9)   Ternary
   4x100  (16)  Quaternary
   5x100  (25)  etc
   6x100  (36)
   7x100  (49)
   8x100  (64)  Octal
   9x100  (81)
   ...   (Not implemented 11x to 15x, nor 10x or 16x)
   0x100  (256) Hex


YAGNI much? How often do you need a base-9 literal in your code??


I've used base-4 a couple of times, but not base 9 yet, excepting when 
toying with stuff. But you need to be able to print numbers in those 
bases too [not Python, or C]:


a := 3x22   # base-3
println a:"x9"  # displays  in base-9

It's interesting to see the patterns that arise when doing arithmetic in 
mixed bases.


Anyway, those extra bases were easier to leave in than to exclude.

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Skip Montanaro]

> Bear in mind that Unix file modes are traditionally written in octal,
> because they have no meaning as numbers. They're more like
> enumerations, or bitfields.

The current chmod(2) man page says that the type of the second is mode_t,
but back in the early days, it appears it was just declared to be int.
Here's 2.11BSD dated 1986:

https://www.freebsd.org/cgi/man.cgi?query=chmod&sektion=2&apropos=0&manpath=2.11+BSD

By 1991, 4.3BSD declared the second arg to be mode_t:

https://www.freebsd.org/cgi/man.cgi?query=chmod&sektion=2&apropos=0&manpath=4.3BSD+NET%2f2

(I find it odd that the above service doesn't include 4.2BSD man pages, but
I digress.)

Octal notation matched up better with the sizes of the individual groups.
Hex and base 10 are worthless for this, as their boundaries don't line up
with the number of bits used in each group. Binary consumes too much space
and no "chunkiness." Octal was "just right."

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

Re: seeking deeper (language theory) reason behind Python design choice

[Chris Angelico]

On Fri, May 11, 2018 at 5:59 AM, Marko Rauhamaa  wrote:
> Mikhail V :
>
>> On Wed, May 9, 2018 at 8:50 AM, Chris Angelico  wrote:
>>> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly  wrote:
 while True:
>>>
>>> Why is it that "while True" is idiomatic Python for a non-infinite
>>> loop? Is it merely because Python currently has no other way to spell
>>> certain loops? Surely it would be more idiomatic to encode the loop's
>>> termination condition in the header, if it were possible.
>>
>> Don't know about 'idiomatic', but the above spelling is exactly what i
>> tend to use lately for almost all loops. It noticeably reduces
>> cognitive load. Though lately more often i prefer "while 1:" so it
>> makes the nodes more lightweight and distinct from the rest lines. And
>> not even official declaration of "idiomatic" as something else will
>> make me switch back.
>
> How about:
>
>while ...:
>do_stuff()
>if done:
>break
>do_more_stuff()
>
> where ... is the Ellipsis.
>
> Joking aside, to answer Chris's question, of course you can use a real
> condition with "while". However, you shouldn't force it or try to avoid
> "while True". It turns out "while True" is the most natural choice in
> about half of the while loops.

So if I understand you correctly, you're saying that a real condition
is better, but "while True" is the best option half the time. In other
words, "while True" is the ONLY option half the time, since any other
option would be better.

My point is that creating a way to write more conditions as actual
loop headers is an improvement in Pythonicity, not a worsening of it.
It is not fundamentally Pythonic to write a non-infinite loop as
"while True"; that is a limitation caused by the inability to
represent certain conditions in any better way.

It is NOT idiomatic to use "while True" and then write your condition
just inside the loop.

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

Re: seeking deeper (language theory) reason behind Python design choice

[Marko Rauhamaa]

Mikhail V :

> On Wed, May 9, 2018 at 8:50 AM, Chris Angelico  wrote:
>> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly  wrote:
>>> while True:
>>
>> Why is it that "while True" is idiomatic Python for a non-infinite
>> loop? Is it merely because Python currently has no other way to spell
>> certain loops? Surely it would be more idiomatic to encode the loop's
>> termination condition in the header, if it were possible.
>
> Don't know about 'idiomatic', but the above spelling is exactly what i
> tend to use lately for almost all loops. It noticeably reduces
> cognitive load. Though lately more often i prefer "while 1:" so it
> makes the nodes more lightweight and distinct from the rest lines. And
> not even official declaration of "idiomatic" as something else will
> make me switch back.

How about:

   while ...:
   do_stuff()
   if done:
   break
   do_more_stuff()

where ... is the Ellipsis.

Joking aside, to answer Chris's question, of course you can use a real
condition with "while". However, you shouldn't force it or try to avoid
"while True". It turns out "while True" is the most natural choice in
about half of the while loops.


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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Grant Edwards]

On 2018-05-10, Jon Ribbens  wrote:

> This whole thread is reminding me PHP 2, which would magically treat
> the second parameter of ChMod() as octal, because clearly if weak
> typing is good then *no* typing must be best of all!
>
>   ChMod($filename, 644); // second parameter is actually 420 base 10

Aaargh.  That's awful.

I didn't think it was possible for my opinion of PHP to get any lower.

I was wrong.

-- 
Grant Edwards   grant.b.edwardsYow! I wonder if I could
  at   ever get started in the
  gmail.comcredit world?

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

Re: Is this a bug or a feature in TkInter?

[Terry Reedy]

On 5/10/2018 2:12 PM, charmingold...@gmail.com wrote:

I'm learning to use TkInter in Python and came across this example program from 
'Thinking in TkInter' (http://thinkingtkinter.sourceforge.net) - see below.

Two buttons 'button1' and 'button2' are defined. The bug is that event.widget 
returns '.!frame.!button' from a button1 event.


The internal pathname of a widget is generated by tkinter for 
interaction with tk.  '.' is the name given to the root Tk widget. 
Before a couple of years ago, children were given random 8(I 
believe)-digit names.  So you might have seen something like 
.88023535.29038503.  Now, the path component for a widget is '!' + 
widgetName (+ number suffix if needed).  A number suffix is only needed 
to avoid duplication after the first widget of a given class for a 
particular parent.


 i.e. it somehow drops the '1' from the widget name.

There never was a '1' to be dropped.


 Events on button2 are correctly reported.


Is this a bug or a feature?


from tkinter import *

class MyApp:
def __init__(self, parent):
self.myParent = parent
self.myContainer1 = Frame(parent)
self.myContainer1.pack()

button_name = "OK"
self.button1 = Button(self.myContainer1,
command=self.buttonHandler(button_name, 1, "Good 
stuff!"))


This calls self.buttonHandler and binds the return value, None, to 
command.  Functions bound to 'command' must not require arguments.  Add 
'lambda:' before 'self' and the above will work.  Nothing is printed 
until you click the button and the printing is repeated each time you click.




# self.button1.bind("", self.buttonHandler_a(event, button_name, 
1, "Good stuff!"))


Functions bound to events must take one argument, the event.  Add 
'lambda event:' before 'self' and the above works when the focus is on 
button1 and you hit return.


Repeat both fixes for button 2.


self.button1.configure(text=button_name, background="green")
self.button1.pack(side=LEFT)
self.button1.focus_force()  # Put keyboard focus on button1

button_name = "Cancel"
self.button2 = Button(self.myContainer1,
command=self.buttonHandler(button_name, 2, "Bad  
stuff!"))

# self.button2.bind("", self.buttonHandler_a(event, button_name, 
2, "Bad  stuff!"))
self.button2.configure(text=button_name, background="red")
self.button2.pack(side=LEFT)


def buttonHandler(self, arg1, arg2, arg3):
print("buttonHandler routine received arguments:", 
arg1.ljust(8), arg2, arg3)

def buttonHandler_a(self, event, arg1, arg2, arg3):
print("buttonHandler_a received event", event)
self.buttonHandler(arg1, arg2, arg3)

print("\n"*100) # clear the screen
print("Starting program tt077.")
root = Tk()
myapp = MyApp(root)
print("Ready to start executing the event loop.")
root.mainloop()
print("Finished   executing the event loop.")





--
Terry Jan Reedy

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Skip Montanaro]

> This whole thread is reminding me PHP 2, which would magically treat
> the second parameter of ChMod() as octal, because clearly if weak
> typing is good then *no* typing must be best of all!

>ChMod($filename, 644); // second parameter is actually 420 base 10

I knew there was a reason I never used PHP...

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Chris Angelico]

On Fri, May 11, 2018 at 5:04 AM, Jon Ribbens  wrote:
> On 2018-05-10, Skip Montanaro  wrote:
>>> I wonder why someone would take a feature generally agreed to be a
>>> poorly designed feature of C, and incorporate it into a new language.
>>
>> I think you might be looking at a decision made in the late 1980s through a
>> pair of glasses made in 2018.
>>
>> As a C programmer back then I never had a problem with C's octal number
>> notation. People coming from C, C++ or Java to Python at that time would
>> certainly have understood that syntax. It's only in the past 15 years or so
>> that we've seen tons of people coming to Python as a first language for
>> whom leading zero notation would be unfamiliar.
>
> This whole thread is reminding me PHP 2, which would magically treat
> the second parameter of ChMod() as octal, because clearly if weak
> typing is good then *no* typing must be best of all!
>
>   ChMod($filename, 644); // second parameter is actually 420 base 10

Bear in mind that Unix file modes are traditionally written in octal,
because they have no meaning as numbers. They're more like
enumerations, or bitfields. The second parameter happens to be equal
to the base 10 number 420, but that's completely useless. A file mode
of 100644 means something; a file mode of 0x81a4 or 33188 decimal
means nothing. PHP went for crazy magic there, but if the API had been
built such that the "644" is passed as a string, it would have been
completely sane and entirely useful.

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Jon Ribbens]

On 2018-05-10, Skip Montanaro  wrote:
>> I wonder why someone would take a feature generally agreed to be a
>> poorly designed feature of C, and incorporate it into a new language.
>
> I think you might be looking at a decision made in the late 1980s through a
> pair of glasses made in 2018.
>
> As a C programmer back then I never had a problem with C's octal number
> notation. People coming from C, C++ or Java to Python at that time would
> certainly have understood that syntax. It's only in the past 15 years or so
> that we've seen tons of people coming to Python as a first language for
> whom leading zero notation would be unfamiliar.

This whole thread is reminding me PHP 2, which would magically treat
the second parameter of ChMod() as octal, because clearly if weak
typing is good then *no* typing must be best of all!

  ChMod($filename, 644); // second parameter is actually 420 base 10

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Chris Angelico]

On Fri, May 11, 2018 at 4:31 AM, bartc  wrote:
>   2x100  (4)   Binary
>   3x100  (9)   Ternary
>   4x100  (16)  Quaternary
>   5x100  (25)  etc
>   6x100  (36)
>   7x100  (49)
>   8x100  (64)  Octal
>   9x100  (81)
>   ...   (Not implemented 11x to 15x, nor 10x or 16x)
>   0x100  (256) Hex

YAGNI much? How often do you need a base-9 literal in your code??

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

Re: seeking deeper (language theory) reason behind Python design choice

[Mikhail V]

On Wed, May 9, 2018 at 8:50 AM, Chris Angelico  wrote:
> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly  wrote:
>>
>> while True:
>> if we_are_done():
>> break
>> # do some stuff
>> ...
>> if error_occurred():
>> break
>> notify_user()
>>
>>
>> Fixed, using idiomatic Python and without needing to use assignment in
>> an expression.
>
> Why is it that "while True" is idiomatic Python for a non-infinite
> loop? Is it merely because Python currently has no other way to spell
> certain loops? Surely it would be more idiomatic to encode the loop's
> termination condition in the header, if it were possible.

Don't know about 'idiomatic', but the above spelling is exactly what i
tend to use lately for almost all loops. It noticeably reduces cognitive load.
Though lately more often i prefer "while 1:" so it makes
the nodes more lightweight and distinct from the rest lines.
And not even official declaration of "idiomatic" as something else will
make me switch back.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to use an API (xsd format) in Python?

[Mark Lawrence]

On 10/05/18 19:10, richardchau...@gmail.com wrote:

On Thursday, May 10, 2018 at 1:54:11 PM UTC-4, Chris Angelico wrote:


I need to get some data from CME Group which provides a public API to download 
(xsd)
What packages should I use in Python to access this data through this API. 
Thank you.


Depends a lot on the API, and I have no idea what CME Group is doing
(or who that even is); but my first thought would be to grab the
'requests' package. If it's any sort of HTTP download, requests is
usually the best way to do it.

ChrisA


They provide Margin Requirements numbers attached to each future contract. The 
XSD file provide the XML Schema. I'm not sure what to do with that xsd.

https://www.cmegroup.com/confluence/display/EPICSANDBOX/Margin+Service+API+-+Requests



Is this http://www.davekuhlman.org/generateDS.html of any use to you?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[bartc]

On 10/05/2018 18:03, Ian Kelly wrote:

On Thu, May 10, 2018 at 10:36 AM, bartc  wrote:

What, 0O100 instead of 0100? Yeah that's a big improvement...

Fortunately octal doesn't get used much.


The PEP discusses this:

"""
Proposed syntaxes included things like arbitrary radix prefixes, such
as 16r100 (256 in hexadecimal), and radix suffixes, similar to the
100h assembler-style suffix. The debate on whether the letter "O"
could be used for octal was intense -- an uppercase "O" looks
suspiciously similar to a zero in some fonts. Suggestions were made to
use a "c" (the second letter of "oCtal"), or even to use a "t" for
"ocTal" and an "n" for "biNary" to go along with the "x" for
"heXadecimal".

For the string % operator, "o" was already being used to denote octal.
Binary formatting is not being added to the % operator because PEP
3101 (Advanced String Formatting) already supports binary, %
formatting will be deprecated in the future.

At the end of the day, since uppercase "O" can look like a zero and
uppercase "B" can look like an 8, it was decided that these prefixes
should be lowercase only, but, like 'r' for raw string, that can be a
preference or style-guide issue.
"""

Personally I would have preferred the "t".




In my own [syntax] designs, for a long time I used:

  100H   (256) Hex
  100B   (4)   Binary

in addition to decimal. Then I when I switched to 0x for hex (so that I 
could write 0xABC instead of needing to write 0ABCH with a leading 
zero), it was easy to extend that scheme:


  2x100  (4)   Binary
  3x100  (9)   Ternary
  4x100  (16)  Quaternary
  5x100  (25)  etc
  6x100  (36)
  7x100  (49)
  8x100  (64)  Octal
  9x100  (81)
  ...   (Not implemented 11x to 15x, nor 10x or 16x)
  0x100  (256) Hex

I think Ada does something similar for example 2#100#.

However I wouldn't be bothered at having to use for example OCT(377), 
HEX(FF), BIN(_) or even OCTAL(377), although it's a bit clunky. 
At least it will be obvious; more so than 0o100.


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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Skip Montanaro]

> I wonder why someone would take a feature generally agreed to be a
> poorly designed feature of C, and incorporate it into a new language.

I think you might be looking at a decision made in the late 1980s through a
pair of glasses made in 2018.

As a C programmer back then I never had a problem with C's octal number
notation. People coming from C, C++ or Java to Python at that time would
certainly have understood that syntax. It's only in the past 15 years or so
that we've seen tons of people coming to Python as a first language for
whom leading zero notation would be unfamiliar.

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

Is this a bug or a feature in TkInter?

[charmingoldgit]

I'm learning to use TkInter in Python and came across this example program from 
'Thinking in TkInter' (http://thinkingtkinter.sourceforge.net) - see below.

Two buttons 'button1' and 'button2' are defined. The bug is that event.widget 
returns '.!frame.!button' from a button1 event. i.e. it somehow drops the '1' 
from the widget name. Events on button2 are correctly reported.

Is this a bug or a feature?


from tkinter import *

class MyApp:
def __init__(self, parent):
self.myParent = parent   
self.myContainer1 = Frame(parent)
self.myContainer1.pack()

button_name = "OK"
self.button1 = Button(self.myContainer1,
command=self.buttonHandler(button_name, 1, "Good 
stuff!"))

# self.button1.bind("", self.buttonHandler_a(event, 
button_name, 1, "Good stuff!"))
self.button1.configure(text=button_name, background="green")  
self.button1.pack(side=LEFT)
self.button1.focus_force()  # Put keyboard focus on button1

button_name = "Cancel"
self.button2 = Button(self.myContainer1, 
command=self.buttonHandler(button_name, 2, "Bad  
stuff!")) 
 
# self.button2.bind("", self.buttonHandler_a(event, 
button_name, 2, "Bad  stuff!"))
self.button2.configure(text=button_name, background="red")
self.button2.pack(side=LEFT)   


def buttonHandler(self, arg1, arg2, arg3):   
print("buttonHandler routine received arguments:", 
arg1.ljust(8), arg2, arg3)

def buttonHandler_a(self, event, arg1, arg2, arg3):
print("buttonHandler_a received event", event)
self.buttonHandler(arg1, arg2, arg3)

print("\n"*100) # clear the screen
print("Starting program tt077.")
root = Tk()
myapp = MyApp(root)
print("Ready to start executing the event loop.")
root.mainloop()
print("Finished   executing the event loop.")

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

Re: How to use an API (xsd format) in Python?

[richardchausse]

On Thursday, May 10, 2018 at 1:54:11 PM UTC-4, Chris Angelico wrote:

> > I need to get some data from CME Group which provides a public API to 
> > download (xsd)
> > What packages should I use in Python to access this data through this API. 
> > Thank you.
> 
> Depends a lot on the API, and I have no idea what CME Group is doing
> (or who that even is); but my first thought would be to grab the
> 'requests' package. If it's any sort of HTTP download, requests is
> usually the best way to do it.
> 
> ChrisA

They provide Margin Requirements numbers attached to each future contract. The 
XSD file provide the XML Schema. I'm not sure what to do with that xsd.

https://www.cmegroup.com/confluence/display/EPICSANDBOX/Margin+Service+API+-+Requests
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to use an API (xsd format) in Python?

[Chris Angelico]

On Fri, May 11, 2018 at 3:49 AM,   wrote:
> I need to get some data from CME Group which provides a public API to 
> download (xsd)
> What packages should I use in Python to access this data through this API. 
> Thank you.

Depends a lot on the API, and I have no idea what CME Group is doing
(or who that even is); but my first thought would be to grab the
'requests' package. If it's any sort of HTTP download, requests is
usually the best way to do it.

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

How to use an API (xsd format) in Python?

[richardchausse]

I need to get some data from CME Group which provides a public API to download 
(xsd)
What packages should I use in Python to access this data through this API. 
Thank you. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[MRAB]

On 2018-05-10 18:03, Ian Kelly wrote:

On Thu, May 10, 2018 at 10:36 AM, bartc  wrote:

What, 0O100 instead of 0100? Yeah that's a big improvement...

Fortunately octal doesn't get used much.


The PEP discusses this:

"""
Proposed syntaxes included things like arbitrary radix prefixes, such
as 16r100 (256 in hexadecimal), and radix suffixes, similar to the
100h assembler-style suffix. The debate on whether the letter "O"
could be used for octal was intense -- an uppercase "O" looks
suspiciously similar to a zero in some fonts. Suggestions were made to
use a "c" (the second letter of "oCtal"), or even to use a "t" for
"ocTal" and an "n" for "biNary" to go along with the "x" for
"heXadecimal".

For the string % operator, "o" was already being used to denote octal.
Binary formatting is not being added to the % operator because PEP
3101 (Advanced String Formatting) already supports binary, %
formatting will be deprecated in the future.

At the end of the day, since uppercase "O" can look like a zero and
uppercase "B" can look like an 8, it was decided that these prefixes
should be lowercase only, but, like 'r' for raw string, that can be a
preference or style-guide issue.
"""

Personally I would have preferred the "t".

I've seen Q used instead, although that was years ago. (It might've been 
a suffix, I don't remember exactly.)

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Ian Kelly]

On Thu, May 10, 2018 at 10:36 AM, bartc  wrote:
> What, 0O100 instead of 0100? Yeah that's a big improvement...
>
> Fortunately octal doesn't get used much.

The PEP discusses this:

"""
Proposed syntaxes included things like arbitrary radix prefixes, such
as 16r100 (256 in hexadecimal), and radix suffixes, similar to the
100h assembler-style suffix. The debate on whether the letter "O"
could be used for octal was intense -- an uppercase "O" looks
suspiciously similar to a zero in some fonts. Suggestions were made to
use a "c" (the second letter of "oCtal"), or even to use a "t" for
"ocTal" and an "n" for "biNary" to go along with the "x" for
"heXadecimal".

For the string % operator, "o" was already being used to denote octal.
Binary formatting is not being added to the % operator because PEP
3101 (Advanced String Formatting) already supports binary, %
formatting will be deprecated in the future.

At the end of the day, since uppercase "O" can look like a zero and
uppercase "B" can look like an 8, it was decided that these prefixes
should be lowercase only, but, like 'r' for raw string, that can be a
preference or style-guide issue.
"""

Personally I would have preferred the "t".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Ian Kelly]

On Thu, May 10, 2018 at 5:49 AM, D'Arcy Cain  wrote:
> On 2018-05-10 07:28 AM, Skip Montanaro wrote:
>> https://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax
>
> Funny stuff:
>
> Python could either:
>
> 1. silently do the wrong thing...
> 2. immediately disabuse him...
> 3. let him continue to think...
>
> Some people passionately believe that (c) is the correct answer
>
> I guess  uses letters in the writer's browser.

That's not even the strongest reason for disallowing leading zeroes
rather than silently changing them to decimal. It should be disallowed
simply because the meaning was previously different.

If I have programs that use 0775 expecting it to be equivalent to
0b11101, and it suddenly changes to 775 when I upgrade to Python
3, that's going to silently introduce weird bugs into my program,
whereas disallowing it means that I immediately get a SyntaxError and
will know to fix it. It's mystifying to me that the PEP doesn't
discuss this transitional issue at all.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Print Failure or success based on the value of the standalone tool

[Rob Gaddi]

On 05/10/2018 09:48 AM, Ganesh Pal wrote:

I have to test a standalone tool from a python script and I am using
os.system() to run the tool . I need to take decision based on the return
value of the standalone tool .

But since os.system merely throws the output value to STDOUT  & returns the
exit status (0 => no error) of the shell , how can I make this print Fail
or Pass based on the return value of the standalone tool.

In the below example ( return_values() function)



[snip]

By not using os.system, it's been superseded for reasons exactly like 
yours.  https://docs.python.org/3/library/subprocess.html is your friend.



--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Re: seeking deeper (language theory) reason behind Python design choice

[Rob Gaddi]

On 05/10/2018 03:02 AM, bartc wrote:

On 10/05/2018 09:09, Marko Rauhamaa wrote:

bartc :

When typing in code (in various languages), I have a habit of typing
"..." at places that need to be implemented. For example:

 if count:
 ...
 else:
 do_something_smart()
 break

the idea being that "..." will surely trigger a syntax error if I forget
to address it.

I was mildly amused when Python happily executed such code. "..." is a
valid expression and thus, a valid statement.


I wondered what it meant, so I typed in:

    print (...)

and it displayed:

    Ellipsis

which wasn't very enlightening.



No, but if you ever have difficulty remembering how to spell "ellipsis", 
it's good to know Python comes with a built-in reference.


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Print Failure or success based on the value of the standalone tool

[Ganesh Pal]

I have to test a standalone tool from a python script and I am using
os.system() to run the tool . I need to take decision based on the return
value of the standalone tool .

But since os.system merely throws the output value to STDOUT  & returns the
exit status (0 => no error) of the shell , how can I make this print Fail
or Pass based on the return value of the standalone tool.

In the below example ( return_values() function)



Example:



# cat standalone_tool.py

#!/usr/bin/env python

# script name: standalone_tool.py

import random

def return_values():

""" My Demo function"""

# After Execution the actual tools returns True, False, None as return
types

x = random.choice([True, False, None])

print x

return x

return_values()



>>> ret = os.system('python standalone_tool.py')

True

>>> ret

0



 # vi test_standalone_tool.py

#!/usr/bin/env python

import os

# script name: test_standalone_tool.py



for i in range(2):

retcode = os.system('python standalone_tool.py')

print retcode

if retcode:

print "The standalone tool returned False. Failure"

else:

print "The standalone tool returned True. Successful"



1# python test_standalone_tool.py

None

0

The standalone tool returned True. Successful

True

0

The standalone tool returned True. Successful



The above problem is because we are referring to the exit status of the
shell, Is there an easy way to print Failure or success based on the value
returned by python standalone_tool.py .  I am on Linux with Python 2.7 and
sorry for the longish post


Regards,

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[bartc]

On 10/05/2018 12:28, Skip Montanaro wrote:


This gave the following error:

Syntax Error: invalid token: C:\Users\Virgil Stokes\Desktop\Important
Notes_Files\CheckProcessingDate_02.py, line 7, pos 17
d0 = date(2018,02,01)



Note that this is a Python syntax error. It actually has nothing to do with
the datetime module. In Python before version 3, leading zeroes were how
you specified octal (base 8) numbers.


I wonder why someone would take a feature generally agreed to be a 
poorly designed feature of C, and incorporate it into a new language.


Especially one with a very different syntax that doesn't need to be 
backwards compatible.


 That changed in Python 3. If you slim

the start of PEP 3127, you'll learn the new notation.


What, 0O100 instead of 0100? Yeah that's a big improvement...

Fortunately octal doesn't get used much.

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[AK]

On 2018-05-10 13:52, D'Arcy Cain wrote:

On 2018-05-10 07:39 AM, AK wrote:

Try (should work from both PY2 and PY3):

d0 = date(2018,0o2,0o1)


Bad advice.  Those numbers are decimal, not octal,  You should use
"date(2018,2,1)" here.  Works in PY2, PY3 and for my birthday, Sept 4.


It was only an evidence that it was PY3/PY2 compatibility issue - not a 
solution/correct way.
Of course simple use of decimal constants like date(2018, 2, 1) is most 
correct.


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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[D'Arcy Cain]

On 2018-05-10 07:28 AM, Skip Montanaro wrote:
> https://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax

Funny stuff:

Python could either:

1. silently do the wrong thing...
2. immediately disabuse him...
3. let him continue to think...

Some people passionately believe that (c) is the correct answer

I guess  uses letters in the writer's browser.

-- 
D'Arcy J.M. Cain
Vybe Networks Inc.
http://www.VybeNetworks.com/
IM:da...@vex.net VoIP: sip:da...@vybenetworks.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[D'Arcy Cain]

On 2018-05-10 07:39 AM, AK wrote:
> Try (should work from both PY2 and PY3):
> 
> d0 = date(2018,0o2,0o1)

Bad advice.  Those numbers are decimal, not octal,  You should use
"date(2018,2,1)" here.  Works in PY2, PY3 and for my birthday, Sept 4.

-- 
D'Arcy J.M. Cain
Vybe Networks Inc.
http://www.VybeNetworks.com/
IM:da...@vex.net VoIP: sip:da...@vybenetworks.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[AK]

On 2018-05-10 12:43, Virgil Stokes wrote:

Module info:

Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 
bit (AMD64)]

[...]

I tried first to use Python's built-in datetime module as follows:

from datetime import date, timedelta

  d0 = date(2018,02,01)

This gave the following error:

Syntax Error: invalid token: C:\Users\Virgil Stokes\Desktop\Important 
Notes_Files\CheckProcessingDate_02.py, line 7, pos 17

d0 = date(2018,02,01)

Then I used pip to install the datetime module and the same error 
occurred! However, when I removed the leading 0's no syntax error was 
reported and the correct result was returned.


It is not a datetime problem. It is PY3 compatibility problem.
Try (should work from both PY2 and PY3):

d0 = date(2018,0o2,0o1)

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Steven D'Aprano]

On Thu, 10 May 2018 12:43:33 +0200, Virgil Stokes wrote:

> Why does the datetime.date  module (both built-in and site-package) not
> accept leading 0's?


This has nothing to do with the datetime module. Syntax Error means it it 
prohibited by the language, not the module.

In Python 2, leading zeroes result in octal (base 8) numbers, which is 
harmless when there is a single digit below 8:

py> 05  # Python 2 octal
5


but mysterious if there is an 8 or 9 digit:

py> 09
  File "", line 1
09
 ^
SyntaxError: invalid token


and a source of errors when there are no 8 or 9 digits:

py> 0123  # pad one hundred twenty-three to four digits
83

So in Python 3, the syntax for octal digits was changed to use a 0o 
prefix, to match the 0x for hexadecimal and 0b for binary, and a bare 
leading 0 made an error.


-- 
Steve

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

Re: Leading 0's syntax error in datetime.date module (Python 3.6)

[Skip Montanaro]

>
> This gave the following error:
>
> Syntax Error: invalid token: C:\Users\Virgil Stokes\Desktop\Important
> Notes_Files\CheckProcessingDate_02.py, line 7, pos 17
> d0 = date(2018,02,01)
>

Note that this is a Python syntax error. It actually has nothing to do with
the datetime module. In Python before version 3, leading zeroes were how
you specified octal (base 8) numbers. That changed in Python 3. If you slim
the start of PEP 3127, you'll learn the new notation.

https://www.python.org/dev/peps/pep-3127/

There is a section in that document about removal of the old syntax:

https://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax

Which is what bit you.

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

Leading 0's syntax error in datetime.date module (Python 3.6)

[Virgil Stokes]

Module info:

Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 
bit (AMD64)]


C:\Python36>pip show datetime
Name: DateTime
Version: 4.2
Summary: This package provides a DateTime data type, as known from Zope 
2. Unless you need to communicate with Zope 2 APIs, you're probably 
better off using Python's built-in datetime module.

Home-page: http://pypi.python.org/pypi/DateTime
Author: Zope Foundation and Contributors
Author-email: zope-...@zope.org
License: ZPL 2.1
Location: c:\python36\lib\site-packages
Requires: zope.interface, pytz

I tried first to use Python's built-in datetime module as follows:

from datetime import date, timedelta

 d0 = date(2018,02,01)

This gave the following error:

Syntax Error: invalid token: C:\Users\Virgil Stokes\Desktop\Important 
Notes_Files\CheckProcessingDate_02.py, line 7, pos 17

d0 = date(2018,02,01)

Then I used pip to install the datetime module and the same error 
occurred! However, when I removed the leading 0's no syntax error was 
reported and the correct result was returned.


d0 = date(2018,2,1)

Why does the datetime.date  module (both built-in and site-package) not 
accept leading 0's?




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

Re: seeking deeper (language theory) reason behind Python design choice

[Marko Rauhamaa]

bartc :
> I wondered what it meant, so I typed in:
>
>print (...)
>
> and it displayed:
>
>Ellipsis
>
> which wasn't very enlightening.

It doesn't mean anything for Python. It's just a special singleton
sentinel object that is stored in the predefined variable "Ellipsis" and
has a literal "..." in the language.

Apparently, Python provides it as a courtesy to the Numpy module:

   https://docs.scipy.org/doc/numpy-1.13.0/reference/arrays.indexing.html


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

Re: seeking deeper (language theory) reason behind Python design choice

[bartc]

On 10/05/2018 09:09, Marko Rauhamaa wrote:

bartc :

On 09/05/2018 06:44, Steven D'Aprano wrote:

But by the time 1.4 came around, Guido had settled on a clean separation
between statements and expressions as part of Python's design.

That separation has gradually weakened over the years,


Presumably it's non-existent now, as it seems you can type any
expression as a statement in its own right:

   "stmt"
   a + b*c
   p == 0


When typing in code (in various languages), I have a habit of typing
"..." at places that need to be implemented. For example:

 if count:
 ...
 else:
 do_something_smart()
 break

the idea being that "..." will surely trigger a syntax error if I forget
to address it.

I was mildly amused when Python happily executed such code. "..." is a
valid expression and thus, a valid statement.


I wondered what it meant, so I typed in:

   print (...)

and it displayed:

   Ellipsis

which wasn't very enlightening.

--
bartc


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

Re: seeking deeper (language theory) reason behind Python design choice

[Rustom Mody]

Marko wrote:
> When typing in code (in various languages), I have a habit of typing 
> "..." at places that need to be implemented

Quite a research area actually
https://wiki.haskell.org/GHC/Typed_holes
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: seeking deeper (language theory) reason behind Python design choice

[Marko Rauhamaa]

bartc :
> On 09/05/2018 06:44, Steven D'Aprano wrote:
>> But by the time 1.4 came around, Guido had settled on a clean separation
>> between statements and expressions as part of Python's design.
>>
>> That separation has gradually weakened over the years,
>
> Presumably it's non-existent now, as it seems you can type any
> expression as a statement in its own right:
>
>   "stmt"
>   a + b*c
>   p == 0

When typing in code (in various languages), I have a habit of typing
"..." at places that need to be implemented. For example:

if count:
...
else:
do_something_smart()
break

the idea being that "..." will surely trigger a syntax error if I forget
to address it.

I was mildly amused when Python happily executed such code. "..." is a
valid expression and thus, a valid statement.


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