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

[issue33455] test.test_posix.TestPosixSpawn::test_specify_environment fails with custom LD_LIBRARY_PATH

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 7ec8f28656ea9d84048e9b5655375c6a74a59f53 by Serhiy Storchaka 
(Miro Hrončok) in branch 'master':
bpo-33455: Pass os.environ in test_posix::test_specify_environment. (GH-6753)
https://github.com/python/cpython/commit/7ec8f28656ea9d84048e9b5655375c6a74a59f53


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33455] test.test_posix.TestPosixSpawn::test_specify_environment fails with custom LD_LIBRARY_PATH

[miss-islington]

Change by miss-islington :


--
pull_requests: +6451

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue15443] datetime module has no support for nanoseconds

[Giampaolo Rodola']

Change by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33463] Can namedtuple._asdict return a regular dict instead of OrderedDict?

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33462] reversible dict

[Raymond Hettinger]

Change by Raymond Hettinger :


--
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33463] Can namedtuple._asdict return a regular dict instead of OrderedDict?

[Raymond Hettinger]

Change by Raymond Hettinger :


--
versions:  -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue33463] Can namedtuple._asdict return a regular dict instead of OrderedDict?

[Michael Selik]

New submission from Michael Selik :

Since the basic dict is now keeping insertion order, can we switch 
namedtuple._asdict to return a basic dict? Other than OrderedDict.move_to_end 
and the repr, I believe there is no compatibility issue.

--
messages: 316387
nosy: selik
priority: normal
severity: normal
status: open
title: Can namedtuple._asdict return a regular dict instead of OrderedDict?
type: enhancement
versions: Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33462] reversible dict

[Michael Selik]

New submission from Michael Selik :

Now that dicts are tracking insertion order, they can be made reversible via 
the built-in reversed, just like OrderedDict.

--
messages: 316386
nosy: selik
priority: normal
severity: normal
status: open
title: reversible dict
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue31817] Compilation Error with Python 3.6.1/3.6.3 with Tkinter

[dplusplus]

dplusplus  added the comment:

I am trying to build Python 3.6.5 from source, with Tcl 8.6.8 and Tk 8.6.8, and 
I get the same issue (Building on Ubuntu 18.04, tried with GCC 7.3 and 8.1 with 
same results). 
Run 'readelf -d` on 
'build/lib.linux-x86_64-3.6/_tkinter.cpython-36m-x86_64-linux-gnu_failed.so' 
and I get three NEEDED entries:


 0x0001 (NEEDED) Shared library: [libpython3.6m.so.1.0]
 0x0001 (NEEDED) Shared library: [libpthread.so.0]
 0x0001 (NEEDED) Shared library: [libc.so.6]


Tcl and Tk libraries are not listed as needed shared libraries, which explains 
why settings runpaths (which I tried by setting CFLAGS) does not seem to work.
I'm comparing this to the ELF entries in Ubuntu's Python 3.6.5 tkinter module 
'/usr/lib/python3.6/lib-dynload/_tkinter.cpython-36m-x86_64-linux-gnu.so', 
which does have NEEDED entries for tcl8.6.so and tk8.6.so.

--
nosy: +dplusplus -6598335

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue29204] Add code deprecations in ElementTree

[Matthias Bussonnier]

Change by Matthias Bussonnier :


--
pull_requests: +6450

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33461] json.loads(encoding=) does not emit deprecation warning.

[Matthias Bussonnier]

Change by Matthias Bussonnier :


--
keywords: +patch
pull_requests: +6449
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue33461] json.loads(encoding=) does not emit deprecation warning.

[Matthias Bussonnier]

New submission from Matthias Bussonnier :

The `encoding` keyword of json.loads is ignored and deprecated. AFAICT this is 
since Python 3.1. 

Passing a value for encoding does not emit a deprecation warning.

--
messages: 316384
nosy: mbussonn
priority: normal
severity: normal
status: open
title: json.loads(encoding=) does not emit deprecation warning.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue33351] Support compiling with clang-cl on Windows

[Ethan Smith]

Change by Ethan Smith :


--
keywords: +patch
pull_requests: +6448
stage: test needed -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue33459] Define "tuple display" in the docs

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Actually, 'tuple display' is in the index under 'display' and links to the last 
paragraph in 6.2.3.  However, except for the index name, that paragraph doesn't 
use the phrase 'tuple display'.  So it gives the definition without saying what 
it is defining.

> Note that tuples are not formed by the parentheses, but rather by use of the 
> comma operator. The exception is the empty tuple, for which parentheses are 
> required — allowing unparenthesized “nothing” in expressions would cause 
> ambiguities and allow common typos to pass uncaught.

--
nosy: +csabella

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33459] Define "tuple display" in the docs

[R. David Murray]

R. David Murray  added the comment:

Nope, a tuple display is not equal to a parenthesized list.  For example, in:

   x = 1, 2, 3

1, 2, 3 is a tuple display.  The parenthesis are optional in that case (in the 
general case it is the comma that makes the tuple, not the parens).

However, as far as I can see that's the only mention of "tuple display" in the 
docs, which makes the doc you reference less than useful to a reader that 
doesn't know what it means.

--
nosy: +r.david.murray
title: Fix "tuple display" mention in Expressions -> Define "tuple display" in 
the docs

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33460] ... used to indicate many different things in chapter 3, some are confusing

[Lew Kurtz]

New submission from Lew Kurtz :

https://docs.python.org/3/tutorial/introduction.html
uses ... to mean 5 or 6 different things. Since ... is continuation prompt, 
some of these other uses on that page are confusing - at least they were to 
this newbie. The most confusing are where it is used to hide output in the 
error messages.

If someone has the patience to send me pointers on how to fix this, I would 
love to fix this myself. -Lew

ps. the section headers in chapter 3 also need some work, 3.1.1 is the only 
section that is really about python being a calculator 3.1.2 and 3.1.3 don't 
seem very 'calculator-y' - Id like to fix this too.

--
assignee: docs@python
components: Documentation
messages: 316381
nosy: docs@python, lew18
priority: normal
severity: normal
status: open
title: ... used to indicate many different things in chapter 3, some are 
confusing
type: enhancement
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33459] Fix "tuple display" mention in Expressions

[Andrés Delfino]

Change by Andrés Delfino :


--
keywords: +patch
pull_requests: +6447
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33459] Fix "tuple display" mention in Expressions

[Andrés Delfino]

New submission from Andrés Delfino :

Expressions mentions "tuple displays" in 6.16 (Operator precedence).

AFAIK, there ano "tuple displays". Expressions mentions list, dict, and set 
displays, and then talks about generator expressions.

I guess "parenthesized expressions" should be the term that fits here?

--
assignee: docs@python
components: Documentation
messages: 316380
nosy: adelfino, docs@python
priority: normal
severity: normal
status: open
title: Fix "tuple display" mention in Expressions
type: enhancement
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue31670] Associate .wasm with application/wasm

[Brad Nelson]

Brad Nelson  added the comment:

We have a provisional registration for application/wasm now with IANA:
https://www.iana.org/assignments/provisional-standard-media-types/provisional-standard-media-types.xhtml

This is also shipping in Firefox and Chrome.

Would it be possible to merge this?

Thanks!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33449] Documentation for email.charset confusing about the location of constants

[R. David Murray]

R. David Murray  added the comment:

Ah, I see.  Yes, those strings are actually hardcoded in the documentation 
source instead of being references.  You are correct, they should be fixed.  
Note, however, that Charset is part of the legacy API and isn't actually used 
if you use the new API in python3.

--
stage:  -> needs patch
type: enhancement -> behavior
versions:  -Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue13044] pdb throws AttributeError at end of debugging session

[Xavier de Gaye]

Xavier de Gaye  added the comment:

See also issue 33458 that deals with the same problem when pdb is run as 
'python -m pdb some_main.py' instead of by inserting a breakpoint with 
'pdb.set_trace()'.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33458] pdb.run() does not trace destructors of __main__

[Xavier de Gaye]

Xavier de Gaye  added the comment:

The following patch fixes the problem when applied applied on top of PR 6730:

diff --git a/Lib/bdb.py b/Lib/bdb.py
index c6a10359ac..07231ec588 100644
--- a/Lib/bdb.py
+++ b/Lib/bdb.py
@@ -582,7 +582,7 @@ class Bdb:
 cmd = compile(cmd, "", "exec")
 sys.settrace(self.trace_dispatch)
 try:
-exec(cmd, globals, locals)
+exec(cmd, dict(globals), dict(locals))
 except BdbQuit:
 pass
 finally:

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33458] pdb.run() does not trace destructors of __main__

[Xavier de Gaye]

New submission from Xavier de Gaye :

This issue is a companion to issue 13044.

Running with Python 3.6.5 the following code fails with NameError:

1 class C:
2 def __del__(self):
3 print('deleted')
4
5 c = C()
6 x = 1

$  python -m pdb bar.py
> ./bar.py(1)()
-> class C:
(Pdb) break 6
Breakpoint 1 at ./bar.py:6
(Pdb) continue
> ./bar.py(6)()
-> x = 1
(Pdb) step
--Return--
> ./bar.py(6)()->None
-> x = 1
(Pdb) step
--Return--
> (1)()->None
(Pdb) step
> /usr/lib/python3.6/bdb.py(438)run()
-> self.quitting = True
(Pdb) step
The program finished and will be restarted
Exception ignored in: >
Traceback (most recent call last):
  File "./bar.py", line 3, in __del__
print('deleted')
NameError: name 'print' is not defined
> ./bar.py(1)()
-> class C:
(Pdb)

--
components: Library (Lib)
messages: 316375
nosy: xdegaye
priority: normal
severity: normal
status: open
title: pdb.run() does not trace destructors of __main__
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue33449] Documentation for email.charset confusing about the location of constants

[Francois Labelle]

Francois Labelle  added the comment:

Original poster here (OpenID just wouldn't work anymore).

For instance: https://docs.python.org/2/library/email.charset.html

Under "class email.charset.Charset"

Under "header_encoding"

"If the character set must be encoded before it can be used in an email header, 
this attribute will be set to Charset.QP (for quoted-printable), Charset.BASE64 
(for base64 encoding), or Charset.SHORTEST for the shortest of QP or BASE64 
encoding. Otherwise, it will be None."

--
nosy: +quantum.om...@gmail.com -Francois Labelle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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=2=0=2.11+BSD

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

https://www.freebsd.org/cgi/man.cgi?query=chmod=2=0=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

[issue13044] pdb throws AttributeError at end of debugging session

[Xavier de Gaye]

Xavier de Gaye  added the comment:

Actually the segfault can be avoided by running the garbage collection before 
_PyState_ClearModules() in PyImport_Cleanup() and one can trace the C 
destructor with the attached patch global_destructors.diff applied on top of PR 
6730.

_PyState_ClearModules() clears the state->modules_by_index list and causes the 
readline module to be non-functional. The same problem occurs in 
test_create_at_shutdown_without_encoding() in test_io.py when it is run with 
the io module: the C destructor fails before hitting the "LookupError: unknown 
encoding: ascii" error message because the garbage collection is made after 
_PyState_ClearModules() and the _io module is non-functional 
(PyState_FindModule() returns NULL).

So the destructors can be traced during finalization provided the tracer does 
not access any of the sys attributes that are set to None at the start of 
PyImport_Cleanup().  This is true for the globals of the modules that are only 
owned by sys.modules at the time 'weaklist' is about to be built in 
PyImport_Cleanup(). But it is not the case of '_ag' and that explains at last 
why the destructor was called and failed:
'_ag' is a global of the types module which is owned (imported) by the inspect 
module, which is owned (imported) by the bdb module which is owned by 
PyThreadState through its c_profileobj member. So the types module, and all 
modules imported directly or indirectly by pdb, can only be cleared at the end 
of PyImport_Cleanup() when 'weaklist' is browsed for the last modules to clear. 
At that point any module may be non-functional and tracing must not be allowed.

The global_destructors.diff patch ensures that no access is made by the pdb and 
bdb modules (but imported modules have not been checked) to the the sys 
attributes that are set to None at the start of PyImport_Cleanup():
* Pdb.lookupmodule() accesses sys.path and is used to set breakpoints so we 
forbid setting breakpoint when sys.path is None.
* All the values of sys.modules are set to None when 'weaklist' is built. This 
causes the lazy imports to fail and the patch removes them except the lazy 
import of pydoc in pdb.py because pydoc imports threading and when threading 
has been imported wait_for_thread_shutdown() in Py_FinalizeEx() runs the 
threading._shutdown() Python code which is traced (this happens in Python 3.6 
too whenever threading is imported). Since it is annoying to systematically 
trace this function and pydoc is a heavy module, pdb.help() is disabled on 
Python finalization.

--
Added file: https://bugs.python.org/file47581/global_destructors.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue28556] typing.py upgrades

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
pull_requests: +6446

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue28556] typing.py upgrades

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
pull_requests: +6445

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I think it safer to silence this kind of warnings in 3.7 and 3.6. PR 6757 does 
this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +6444

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33413] asyncio.gather should not use special Future

[Ned Deily]

Change by Ned Deily :


--
components: +asyncio
nosy: +asvetlov, yselivanov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue33413] asyncio.gather should not use special Future

[Martin Teichmann]

Martin Teichmann  added the comment:

I looked a bit into the details, and found that bpo-30048 created the described 
weird behavior. There they fixed the problem that a cancel is ignored if a 
coroutine manages to cancel its own task and return immediately. As shown in 
the discussion there, this is actually something happening in real code, and is 
a valid use case.

They fixed that by setting a CancelledError as an exception raised by the task, 
but did not cancel that task (they could have, I tested it, it would pass all 
tests).

But this is just a side show of the fact that we have now four different beasts 
that can be awaited, and behave differently: coroutines, Futures, Tasks, and 
_GatheringFutures. I think we should consolidate that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33448] Output_Typo_Error

[Mark Dickinson]

Mark Dickinson  added the comment:

Marking as pending; we can't take this forward without more input from the OP. 
As far as I can tell, the documentation is perfectly correct here: I suspect 
that there was a misunderstanding somewhere along the line.

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
resolution:  -> not a bug
status: open -> pending
type: resource usage -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue33419] Add functools.partialclass

[Nick Coghlan]

Nick Coghlan  added the comment:

Marking as closed/later to indicate that we're not going to pursue this in the 
near term, but it's not out of the question that we might accept a future 
proposal along these lines.

--
resolution:  -> later
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33457] python-config ldflags, PEP 513 and explicit linking to libpython in python extensions

[dimi]

New submission from dimi :

The python-config outputs ldflag for explicit linking to libpyhton, which is a 
good idea in many use cases. However, this is inconsistent with the PEP 513 
recommendation for building manylinux1 python extensions 
(https://www.python.org/dev/peps/pep-0513/) that requires avoiding explicit 
linking to libpythonX.Y.so.1.

--
components: Distutils
messages: 316368
nosy: dimi, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: python-config ldflags, PEP 513 and explicit linking to libpython in 
python extensions
type: behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33456] site.py: by default, a virtual environment is *not* isolated from the system-level site-packages directories

[Lukas Waymann]

Change by Lukas Waymann :


--
keywords: +patch
pull_requests: +6442
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32962] test_gdb fails in debug build with `-mcet -fcf-protection -O0`

[Marcel Plch]

Change by Marcel Plch :


--
keywords: +patch
pull_requests: +6441
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33455] test.test_posix.TestPosixSpawn::test_specify_environment fails with custom LD_LIBRARY_PATH

[Miro Hrončok]

Change by Miro Hrončok :


--
keywords: +patch
pull_requests: +6440
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33456] site.py: by default, a virtual environment is *not* isolated from the system-level site-packages directories

[Lukas Waymann]

New submission from Lukas Waymann :

PEP 405 says this:

> By default, a virtual environment is entirely isolated from the system-level 
> site-packages directories.
>
> If the pyvenv.cfg file also contains a key include-system-site-packages with 
> a value of true (not case sensitive), the site module will also add the 
> system site directories to sys.path after the virtual environment site 
> directories.

The documentation of the site module 
(https://docs.python.org/3/library/site.html) says (emphasis added):

> If pyvenv.cfg […] contains the key include-system-site-packages set to 
> anything other than false (case-insensitive), the system-level prefixes will 
> still also be searched for site-packages; *otherwise they won’t*.

However, what actually happens in site.py is different: see 
.  The system_site 
variable is initialized to "true" and doesn't change unless the key 
include-system-site-packages exists in pyvenv.cfg.

I think system_site should be initialized to "false" and the condition in line 
468 should be `if system_site.lower() != "false"`.

--
components: Library (Lib)
messages: 316367
nosy: meribold
priority: normal
severity: normal
status: open
title: site.py: by default, a virtual environment is *not* isolated from the 
system-level site-packages directories
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26701] Documentation for int constructor mentions __int__ but not __trunc__

[miss-islington]

miss-islington  added the comment:


New changeset 22df4187c3882c6ec67180902e1151e65b03aee0 by Miss Islington (bot) 
in branch '3.7':
bpo-26701: Tweak the documentation for special methods in int(). (GH-6741)
https://github.com/python/cpython/commit/22df4187c3882c6ec67180902e1151e65b03aee0


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26701] Documentation for int constructor mentions __int__ but not __trunc__

[miss-islington]

miss-islington  added the comment:


New changeset 7488c79b600cd173b0ccea13adb567d078e7b835 by Miss Islington (bot) 
in branch '3.6':
bpo-26701: Tweak the documentation for special methods in int(). (GH-6741)
https://github.com/python/cpython/commit/7488c79b600cd173b0ccea13adb567d078e7b835


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33449] Documentation for email.charset confusing about the location of constants

[R. David Murray]

R. David Murray  added the comment:

Can you provide an example of where this occurs in the docs?

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

[Rick Teachey]

Rick Teachey  added the comment:

> Is there any scenario where the following code would be useful...

Perhaps if someone, in search of a speedup, were sort of rolling their own 
lighter-weight equivalent to the typing module (in order to avoid importing the 
full typing module), but duck typed enough to fool the average type checker? Is 
that possible?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33455] test.test_posix.TestPosixSpawn::test_specify_environment fails with custom LD_LIBRARY_PATH

[Miro Hrončok]

New submission from Miro Hrončok :

When we build Python in Fedora, we set LD_LIBRARY_PATH environment variable so 
the testsuite is run against the currently built Python.

However a test added in ef347535f289baad22c0601e12a36b2dcd155c3a 
(test_specify_environment) spawns a process without passing the environment 
variables. This means that the new process fails with 

error while loading shared libraries: libpython3.7m.so.1.0: cannot open 
shared object file: No such file or directory

And the test fails with:

test_specify_environment (test.test_posix.TestPosixSpawn) ... 
/builddir/build/BUILD/Python-3.7.0b4/build/optimized/python: error while 
loading shared libraries: libpython3.7m.so.1.0: cannot open shared object file: 
No such file or directory
test test_posix failed
FAIL
==
FAIL: test_specify_environment (test.test_posix.TestPosixSpawn)
--
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.7.0b4/Lib/test/test_posix.py", line 
1467, in test_specify_environment
self.assertEqual(os.waitpid(pid, 0), (pid, 0))
AssertionError: Tuples differ: (11457, 32512) != (11457, 0)
First differing element 1:
32512
0
- (11457, 32512)
? ^
+ (11457, 0)
? ^
--
Ran 101 tests in 0.608s
FAILED (failures=1, skipped=9)
1 test failed again:
test_posix
Total duration: 23 min 22 sec
Tests result: FAILURE

I believe that a fix for this is to copy os.environ, update it with {'foo': 
'bar'} and pass that copy. I'll check and send PR if it works.

--
components: Tests
messages: 316363
nosy: hroncok, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test.test_posix.TestPosixSpawn::test_specify_environment fails with 
custom LD_LIBRARY_PATH
versions: Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26701] Documentation for int constructor mentions __int__ but not __trunc__

[miss-islington]

Change by miss-islington :


--
pull_requests: +6439

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26701] Documentation for int constructor mentions __int__ but not __trunc__

[miss-islington]

Change by miss-islington :


--
pull_requests: +6438

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26701] Documentation for int constructor mentions __int__ but not __trunc__

[Nick Coghlan]

Nick Coghlan  added the comment:


New changeset df00f048250b9a07195b0e3b1c5c0161fdcc9db8 by Nick Coghlan (Serhiy 
Storchaka) in branch 'master':
bpo-26701: Tweak the documentation for special methods in int(). (GH-6741)
https://github.com/python/cpython/commit/df00f048250b9a07195b0e3b1c5c0161fdcc9db8


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS

[pmpp]

Change by pmpp :


--
nosy: +pmpp

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com