Re: Can math.atan2 return INF?

[Marko Rauhamaa]

Gregory Ewing :

> Marko Rauhamaa wrote:
>> Which phenomenon prevents a black hole from ever forming. Yet
>> astronomers keep telling us they are all over the place.
> Astronomers have observed objects whose behaviour is entirely
> consistent with the existence of black holes as predicted by general
> relativity.

As far as I understand, all we can ever observe is black holes in the
making since the making can never (seem to) finish. IOW, the event
horizon never forms.

These almost-black-holes are virtually indistinguishable from black
holes proper. However, we don't have to speculate about the physics of
the insides of the black hole.

> The singularity being talked about there is an artifact of a
> particular coordinate system; the theory predicts that there is no
> *physical* singularity at the event horizon.

That theory can't be tested even in principle, can it? Therefore, it is
not scientific.

> It's true that we outside can't be absolutely sure that things are as
> predicted at the horizon itself, because any observer we sent in to
> check would be unable to report back. But in principle we can observe
> arbitrarily close to it. The observations we've made so far all fit
> the theory, and the theory doesn't present any obstacles to
> extrapolating those results to the horizon and beyond, so we accept
> the theory as valid.

Religious theories about the afterlife face similar difficulties -- and
present similar extrapolations.

> There *is* a difficulty at the very center of the hole, where there is
> a true singularity in the theory, so something else must happen there.
> But for other reasons we don't expect those effects to become
> important until you get very close to the singularity -- something on
> the order of the Planck length.

That's my point: such speculation must remaing mere speculation. The
universe doesn't owe us an answer to a question that we can never face.


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

Re: How to reset IPython notebook file association

[Lawrence D’Oliveiro]

On Saturday, June 25, 2016 at 11:03:17 PM UTC+12, David Shi wrote:
> I use IPython Notebook to do Python programming.
> I used "Open with" and set it with Google Chrome.

Why did you do that? You open notebooks from within your web browser, not your 
system’s file browser.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Break and Continue: While Loops

[Lawrence D’Oliveiro]

On Thursday, June 23, 2016 at 11:58:01 PM UTC+12, Jon Ribbens wrote:
> I seem to recall that Java originally insisted that only booleans
> (excluding even Booleans, which are a different thing because of
> course they are) could be checked for truth and it was one of
> Java's significant warts.

Java’s wart was it didn’t implement Booleans the way they were done in Pascal. 
That wouldn’t have been a wart.

Python’s Boolean handling is a wart in the other direction.
-- 
https://mail.python.org/mailman/listinfo/python-list

Assignment Versus Equality

[Lawrence D’Oliveiro]

One of Python’s few mistakes was that it copied the C convention of using “=” 
for assignment and “==” for equality comparison.

It should have copied the old convention from Algol-like languages (including 
Pascal), where “:=” was assignment, so “=” could keep a meaning closer to its 
mathematical usage.

For consider, the C usage isn’t even consistent. What is the “not equal” 
operator? Is it the “not” operator concatenated with the “equal” operator? No 
it’s not! It is “!” followed by “=” (assignment), of all things! This fits in 
more with the following pattern:

A += B <=> A = A + B
A *= B <=> A = A * B

in other words

A != B

should be equivalent to

A = A ! B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Assignment Versus Equality

[BartC]

On 26/06/2016 08:36, Lawrence D’Oliveiro wrote:

One of Python’s few mistakes was that it copied the C convention of using “=” 
for assignment and “==” for equality comparison.


One of C's many mistakes. Unfortunately C has been very influential.

However, why couldn't Python have used "=" both for assignment, and for 
equality? Since I understand assignment ops can't appear in expressions.



It should have copied the old convention from Algol-like languages (including 
Pascal), where “:=” was assignment, so “=” could keep a meaning closer to its 
mathematical usage.


(I think Fortran and PL/I also used "=" for assignment. Both were more 
commercially successful than Algol or Pascal.)



For consider, the C usage isn’t even consistent. What is the “not equal”
> operator? Is it the “not” operator concatenated with the “equal” 
operator?

> No it’s not! It is “!” followed by “=” (assignment), of all things!

I thought "!" /was/ the logical not operator (with "~" being bitwise not).

> This fits in more with the following pattern:


A += B <=> A = A + B
A *= B <=> A = A * B

in other words

A != B

should be equivalent to

A = A ! B


Yes, that's an another inconsistency in C. Sometimes "<>" was used for 
"not equals", or "≠" except there was limited keyboard support for that. 
("/=" would have the same problem as "!=")


But again, that doesn't apply in Python as the "!=" in "A != B" can't 
appear in expressions.


--
Bartc

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

Re: Break and Continue: While Loops

[Steven D'Aprano]

On Sun, 26 Jun 2016 05:32 pm, Lawrence D’Oliveiro wrote:

> On Thursday, June 23, 2016 at 11:58:01 PM UTC+12, Jon Ribbens wrote:
>> I seem to recall that Java originally insisted that only booleans
>> (excluding even Booleans, which are a different thing because of
>> course they are) could be checked for truth and it was one of
>> Java's significant warts.
> 
> Java’s wart was it didn’t implement Booleans the way they were done in
> Pascal. That wouldn’t have been a wart.

Oh? How are Java booleans different from Pascal booleans?

Are you referring to "boxed" booleans, i.e. native bools in an object
wrapper?





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

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

Re: how to python to use virtual memory?

[Joonas Liik]

On 26 June 2016 at 04:47, Ho Yeung Lee  wrote:
> what is the command or code to write to use virtual memory if i use extra
> 20 GB from hard disk as memory, means from 70GB memory to 90GB memory
> and left 10GB for file?
>
> Michael Torrie於 2016年6月25日星期六 UTC+8上午11時00分36秒寫道：
>> On 06/24/2016 08:44 PM, Dennis Lee Bieber wrote:
>> > I don't know how Linux handles swap disk -- Windows normally sets the
>> > swap space to ~2X physical memory (for small RAM -- my 12GB system has a
>> > 12GB swap and suggests 18GB).
>>
>> Linux typically uses a user-set swap partition.  The old rule of thumb
>> was to make the swap partition 2x the size of RAM. Now, though, for most
>> installations with lots of RAM, 1:1 is often used.
>>
>> However, if the OP's program really requires 70 to 100 GB of space,
>> relying on the virtual memory system to do this (64-bit only of course)
>> is a mistake.  The system will simply thrash itself to death on any OS
>> at that level of over-commit.  If he has that much data, he needs to
>> employ techniques for working with the data directly on disk himself.  I
>> highly doubt these big data sets that large companies work rely simply
>> on the OS to manage it!
>
> --
> https://mail.python.org/mailman/listinfo/python-list

You really should avoid relying on the OS trick of pretending you have
more ram than you actually do. this can easily cause several
magnitudes worth of slowdown. if you succeed i bet the next post to
this list will be titled "why is my program taking forever to run". in
stead try to partition the work in to chunks and only keep the truly
necessary working set loaded at a time.

For example if you load data from an xml or json file it will likely
include more data than you need to do your calculations. perhaps it is
possible to throw some of it away or at least remove it for the time
of the memory intensive step.

there are ways to allow your program to use more memory ofc. but this
may run in to OS limits (like the aforementioned 32 bit windows issue)
and will likely incur heavy performance penalties. you should avoid it
if at all possible.
even if you do you will likely benefit from adapting your algorithm.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Assignment Versus Equality

[Steven D'Aprano]

On Sun, 26 Jun 2016 08:48 pm, BartC wrote:

> On 26/06/2016 08:36, Lawrence D’Oliveiro wrote:
>> One of Python’s few mistakes was that it copied the C convention of using
>> “=” for assignment and “==” for equality comparison.
> 
> One of C's many mistakes. Unfortunately C has been very influential.
> 
> However, why couldn't Python have used "=" both for assignment, and for
> equality? Since I understand assignment ops can't appear in expressions.

Personally, I think that even if there is no *syntactical* ambiguity between
assignment and equality, programming languages should still use different
operators for them. I must admit that my first love is still Pascal's :=
for assignment and = for equality, but C's = for assignment and == for
equality it *almost* as good.

(It loses a mark because absolute beginners confuse the assignment = for the
= in mathematics, which is just different enough to cause confusion.)

But the BASIC style = for both assignment and equality is just begging for
confusion. Even though = is not ambiguous given BASIC's rules, it can still
be ambiguous to beginners who haven't yet digested those rules and made
them second nature.

And even experts don't always work with complete statements. Here is a
snippet of BASIC code:

X = Y

Is it an assignment or an equality comparison? Without seeing the context,
it is impossible to tell:

10 X = Y + 1
20 IF X = Y GOTO 50


Now obviously BASIC was a very popular and successful language, for many
years, despite that flaw. But I wouldn't repeat it in a new language.


>> It should have copied the old convention from Algol-like languages
>> (including Pascal), where “:=” was assignment, so “=” could keep a
>> meaning closer to its mathematical usage.
> 
> (I think Fortran and PL/I also used "=" for assignment. Both were more
> commercially successful than Algol or Pascal.)

Fortran 77 used .EQ. for equality. I'm not sure about PL/I.

I'm also not sure I'd agree about the commercial success. Fortran certainly
has been extremely popular, albeit almost entirely in numerical computing.
But PL/I has virtually disappeared from the face of the earth, while Pascal
still has a small but dedicated community based on FreePascal, GNU Pascal,
and Delphi.

(Of the three, FreePascal and Delphi appear to still be getting regular
releases.)




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

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

Re: Assignment Versus Equality

[Rustom Mody]

On Sunday, June 26, 2016 at 6:51:58 PM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 26 Jun 2016 08:48 pm, BartC wrote:
> 
> > On 26/06/2016 08:36, Lawrence D’Oliveiro wrote:
> >> One of Python’s few mistakes was that it copied the C convention of using
> >> “=” for assignment and “==” for equality comparison.
> > 
> > One of C's many mistakes. Unfortunately C has been very influential.
> > 
> > However, why couldn't Python have used "=" both for assignment, and for
> > equality? Since I understand assignment ops can't appear in expressions.
> 
> Personally, I think that even if there is no *syntactical* ambiguity between
> assignment and equality, programming languages should still use different
> operators for them. I must admit that my first love is still Pascal's :=
> for assignment and = for equality, but C's = for assignment and == for
> equality it *almost* as good.
> 
> (It loses a mark because absolute beginners confuse the assignment = for the
> = in mathematics, which is just different enough to cause confusion.)
> 
> But the BASIC style = for both assignment and equality is just begging for
> confusion. Even though = is not ambiguous given BASIC's rules, it can still
> be ambiguous to beginners who haven't yet digested those rules and made
> them second nature.
> 
> And even experts don't always work with complete statements. Here is a
> snippet of BASIC code:
> 
> X = Y
> 
> Is it an assignment or an equality comparison? Without seeing the context,
> it is impossible to tell:
> 
> 10 X = Y + 1
> 20 IF X = Y GOTO 50
> 
> 
> Now obviously BASIC was a very popular and successful language, for many
> years, despite that flaw. But I wouldn't repeat it in a new language.

This is a tad bit unfair (I think)
Initially Basic (BASIC as things were spelt then) used
LET X = Y
for the assignment

The general success of the succinct and confusing approach starting Fortran and
exploding with C I guess prompted the shortening

[My impression: Dont know the history exactly]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposal: named return values through dict initialization and unpacking

[Ari Freund via Python-list]

Thanks everybody.  There seems to be a lot of resistance to dict unpacking, in 
addition to the problem with my proposed shorthand dict() initialization syntax 
pointed out by Steven D'Aprano, so I won't be pursuing this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Assignment Versus Equality

[MRAB]

On 2016-06-26 11:48, BartC wrote:

On 26/06/2016 08:36, Lawrence D’Oliveiro wrote:

One of Python’s few mistakes was that it copied the C convention of using “=” 
for assignment and “==” for equality comparison.


One of C's many mistakes. Unfortunately C has been very influential.

However, why couldn't Python have used "=" both for assignment, and for
equality? Since I understand assignment ops can't appear in expressions.


[snip]

Python supports chained assignments. For example, "a = b = 0" assigns 0 
to both a and b.


I'm not sure how common it is, though. I virtually never use it myself.

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

Re: Assignment Versus Equality

[Cousin Stanley]

Dennis Lee Bieber wrote:

> 
> but I'm sure we'd have a revolt 
> if Python comparison operators looked like:
> 
> a .eq. b
> a .ne. b
> a .gt. b .or. c .lt. d
> a .le. b .and. c .ge. d
> 

  As someone who learned fortran in the mid 1960s
  and pounded a  lot  of fortran  code in the 1970s,
  the code above seems very readable 


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

Re: Proposal: named return values through dict initialization and unpacking

[Joonas Liik]

On 26 June 2016 at 18:28, Ari Freund via Python-list
 wrote:
> Thanks everybody.  There seems to be a lot of resistance to dict unpacking, 
> in addition to the problem with my proposed shorthand dict() initialization 
> syntax pointed out by Steven D'Aprano, so I won't be pursuing this.
> --
> https://mail.python.org/mailman/listinfo/python-list

something like:

a, b, c = my_magic_reordering_func(mydict, ["alpha", "beta", "charlie"])

..is not too far off, altho it is a little repetitive is is trivial to
write in current python and reaches the goal of insulating you from
some degree of change in the return value. can also be extended to
work with namedtuple for example (which you probably should already be
using if you want to return so many arguments that this is a problem,
returning several arguments is already returning a tuple under the
hood afterall)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Assignment Versus Equality

[BartC]

On 26/06/2016 16:47, Cousin Stanley wrote:

Dennis Lee Bieber wrote:



but I'm sure we'd have a revolt
if Python comparison operators looked like:

a .eq. b
a .ne. b
a .gt. b .or. c .lt. d
a .le. b .and. c .ge. d



  As someone who learned fortran in the mid 1960s
  and pounded a  lot  of fortran  code in the 1970s,
  the code above seems very readable 


I did a year of it in the 1970s. Looks funny in lower case though.

(Note, for those who don't know (old) Fortran, that spaces and tabs are 
not significant. So those dots are needed, otherwise "a eq b" would be 
parsed as "aeqb".)


--
Bartc



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

Re: Assignment Versus Equality

[BartC]

On 26/06/2016 16:41, MRAB wrote:

On 2016-06-26 11:48, BartC wrote:



However, why couldn't Python have used "=" both for assignment, and for
equality? Since I understand assignment ops can't appear in expressions.


[snip]

Python supports chained assignments. For example, "a = b = 0" assigns 0
to both a and b.

I'm not sure how common it is, though. I virtually never use it myself.


Well, if it's allowed, then it doesn't matter how common it is.

So "=" couldn't be used with a different meaning inside expressions as 
it would make this ambiguous.


It also raises the possibility of a bug when someone intends to write 
"a=b==0" but writes "a=b=c" instead.


In that case I would have supported the use of ":=" for assignment.

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

Re: Assignment Versus Equality

[Marko Rauhamaa]

Dennis Lee Bieber :

>   It did... but I'm sure we'd have a revolt if Python comparison
> operators looked like:
>
>   a .eq. b
>   a .ne. b
>   a .gt. b .or. c .lt. d
>   a .le. b .and. c .ge. d

Yuck, who'd ever want to look at an eyesore like that. In Python, we
will always stick to the pleasant elegance of

   __eq__
   __ne__
   __gt__
   __ge__
   __lt__
   __le__


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

Re: How to reset IPython notebook file association

[eryk sun]

On Sat, Jun 25, 2016 at 11:00 AM, David Shi via Python-list
 wrote:
> I use IPython Notebook to do Python programming.
> I used "Open with" and set it with Google Chrome.  Then, my IPython notebook 
> does not load properly.
> How can I reset IPython notebook file association, so that I can use it again?

nbopen opens a notebook in an existing notebook server or otherwise
starts a new server:

https://github.com/takluyver/nbopen

Use the package's win-install.py script, which sets up the file
association for you. Optionally, if PyWin32 is installed, the script
calls SHChangeNotify to update Explorer. Example installation:

> git clone https://github.com/takluyver/nbopen.git
> cd nbopen
> python win-install.py

I wouldn't have written the installation like this. I'd use setuptools
entry points and have a cross-platform registration script or
command-line option that honors Windows per-user and per-machine
installations, to be compatible with pip/wheel installation, instead
of requiring this awkward (per-user only) win-install script. Using an
entry-point EXE also works better with the "Open With" dialog, since
Windows otherwise takes the name/description from "python.exe". For
some reason, win-install also neglects to assign a DefaultIcon for the
file type. You can manually edit the file type in the registry to set
the icon.
-- 
https://mail.python.org/mailman/listinfo/python-list

Python Access logging of another program ran in subprocess

[p . infante413]

Hello, I'm currently running another Python program (prog2.py) in my program 
via subprocess. 

input_args = ['python', '/path/to/prog2.py'] + self.chosen_args
file = open("logfile.txt",'w')
self.process = Popen((input_args), stdout=file)

However, the logs that prog2.py contains still show at the terminal since logs 
are not covered in the stdout module and printed in the terminal, also, the 
logfile.txt is empty. Is there a way I can access those logs while in prog1.py? 
I can't modify prog2.py since it is not mine. I'm stuck here for days now, any 
tips or help will do.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Access logging of another program ran in subprocess

[MRAB]

On 2016-06-26 17:38, p.infante...@gmail.com wrote:

Hello, I'm currently running another Python program (prog2.py) in my program 
via subprocess.

input_args = ['python', '/path/to/prog2.py'] + self.chosen_args
file = open("logfile.txt",'w')
self.process = Popen((input_args), stdout=file)

However, the logs that prog2.py contains still show at the terminal since logs 
are not covered in the stdout module and printed in the terminal, also, the 
logfile.txt is empty. Is there a way I can access those logs while in prog1.py? 
I can't modify prog2.py since it is not mine. I'm stuck here for days now, any 
tips or help will do.


The output you're seeing might be going to stderr, not stdout.

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

Re: Python Access logging of another program ran in subprocess

[p . infante413]

On Monday, June 27, 2016 at 1:36:24 AM UTC+8, MRAB wrote:
> >
> The output you're seeing might be going to stderr, not stdout.

Wow, huhuhu. Thank you. I did not know that. Thanks man! 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposal: named return values through dict initialization and unpacking

[Michael Selik]

On Tue, Jun 21, 2016 at 9:41 PM Steven D'Aprano  wrote:

> On Tue, 21 Jun 2016 05:34 pm, Ari Freund wrote:
> >  var3, var1, var2 = **d
>
> But I don't want to use the key names your function uses. I want to
> use names which makes sense for my application
>

Note that my dict unpacking syntax proposal would solve this quite nicely.

{'var1': width, 'var2': counter, 'var3': aardvark} = d

But the current syntax ain't so bad either. Maybe it's even better, more
readable despite being less concise.

expected = {'var1', 'var2', 'var3'}
excess = d.keys() - expected
if excess:
raise ValueError('unexpected keys {!r}'.format(excess))
width = d['var1']
counter = d['var2']
aardvark = d['var3']
-- 
https://mail.python.org/mailman/listinfo/python-list

argparse and subparsers

[Joseph L. Casale]

I have some code where sys.argv is sliced up and manually fed to discrete 
argparse
instances each with a single subparser. The reason the discrete parsers all 
having a
single subparser was to make handling the input simpler, the first arg in the 
slice
could be left in.

This has become unmaintainable as the manual slicing is always subject to a new 
case
by where a parser has a positional, switch or optional parameter for example. 
Also, since
argv is grouped by subparser specifiers, if a parameter has input that matches 
a keyword
it all goes pear shaped.

The underlying root of this mess is a long unaddressed limitation in argparse 
to support
multiple subparser specifications on the same invocation:

prog.py -x -y 42 -foo bar subParserA -a 1 -b 2 subParserB -a 1 -b 2 subParserB 
-a 1 -b 2

The base arguments (-x -y 42 -foo bar).
An invocation of "subParserA" and its arguments (-a 1 -b 2).
Two invocations of "subParserB" and their arguments.

etc...

I have seen some creative ways to overcome this on stacktrace, however I 
thought I'd
see what people here have done. The code is pinned at 2.7 and while several 
people
have created alternate implementations which address many of argparses 
failures, its
desired to stick to base lib but that can easily be changed given a compelling 
reason
if an alternate implementation exists that works well.

Thanks for any thoughts,
jlc
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Break and Continue: While Loops

[Elizabeth Weiss]

On Thursday, June 23, 2016 at 12:49:30 AM UTC-4, Lawrence D’Oliveiro wrote:
> On Thursday, June 23, 2016 at 4:17:23 PM UTC+12, Elizabeth Weiss wrote:
> > 
> > i=0
> > while 1==1:
> >print(i)
> >i=i+1
> >if i>=5:
> >  print("Breaking")
> >  break
> > 
> > Why is Breaking going to be printed if i only goes up to 4? It does say if
> > i>=5?
> 
> Because you incremented i after printing its value, and before checking it.

Got it, Lawrence. Thanks so much for your help!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Break and Continue: While Loops

[Elizabeth Weiss]

On Thursday, June 23, 2016 at 1:06:09 AM UTC-4, Rustom Mody wrote:
> On Thursday, June 23, 2016 at 9:47:23 AM UTC+5:30, Elizabeth Weiss wrote:
> > CODE #1:
> > 
> > i=0
> > while 1==1:
> >print(i)
> >i=i+1
> >if i>=5:
> >  print("Breaking")
> >  break
> > 
> > --
> > I understand that i=0 and i will only be printed if 1=1
> > The results of this is
> > 0
> > 1
> > 2
> > 3
> > 4
> > Breaking
> > 
> > Why is Breaking going to be printed if i only goes up to 4? It does say if 
> > i>=5? Shouldn't this mean that the results should be:
> > 0
> > 1
> > 2
> > 3
> > 4
> > 5
> > 
> > CODE #2:
> > 
> > i=0
> > while True:
> >i=i+1
> >   if i==2:
> >  print("Skipping 2")
> >  continue
> >   if i==5:
> >  print("Breaking")
> >  break
> >print(i)
> > 
> > --
> > 
> > Questions:
> > 1. what does the word True have to do with anything here? 
> > 2. i=i+1- I never understand this. Why isn't it i=i+2?
> > 3. Do the results not include 2 of 5 because we wrote if i==2 and if i==5?
> > 4. How is i equal to 2 or 5 if i=0?
> > 
> > Thanks for all of your help!
> 
> I suggested in your other post (Subject While Loops)
> that the predecessor of python ABC's syntax for assignment would help 
> unconfuse you
> 
> ie the ASSIGNMENT x=y we write as PUT y IN x
> 
> Using that rewrite your CODE 1 as
> 
> PUT 0 in i
> while 1==1:
>print(i)
>PUT i+1 IN i
>if i>=5:
>  print("Breaking")
>  break 
> 
> Now try and rethink what that does
> Then repeat for your other examples that confuse

Got it! Thank you!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Break and Continue: While Loops

[Elizabeth Weiss]

On Thursday, June 23, 2016 at 1:20:37 AM UTC-4, DFS wrote:
> On 6/23/2016 12:17 AM, Elizabeth Weiss wrote:
> 
> > CODE #1:
> >
> > i=0
> > while 1==1:
> >print(i)
> >i=i+1
> >if i>=5:
> >  print("Breaking")
> >  break
> >
> > --
> > I understand that i=0 and i will only be printed if 1=1
> > The results of this is
> > 0
> > 1
> > 2
> > 3
> > 4
> > Breaking
>   >
> > Why is Breaking going to be printed if i only goes up to 4? It does say if 
> > i>=5? Shouldn't this mean that the results should be:
> 
> i is incremented up to 5, but you're printing i before incrementing and 
> evaluating it.
> 
> Move i=i+1 to the end and try it again.
> 
> 
> 
> 
> 
> > CODE #2:
> >
> > i=0
> > while True:
> >i=i+1
> >   if i==2:
> >  print("Skipping 2")
> >  continue
> >   if i==5:
> >  print("Breaking")
> >  break
> >print(i)
> >
> > --
> >
> > Questions:
> > 1. what does the word True have to do with anything here?
> 
> 'True' is the expression that's evaluated on each iteration of the While 
> loop.
> 
> while True:
> print('True')
> 
> while 1:
> print('True')
> 
> while 1==1:
> print('True')
> 
> are all equivalent, and will run indefinitely, because the statements 
> after the while expression do nothing to stop the loop.
> 
> 
> 
> 
> > 2. i=i+1- I never understand this. Why isn't it i=i+2?
> 
> i=i+1 adds 1 to the current value of i, then assigns that value to i.
> 
> You can increment i by whatever you want:
> i=i+1
> i=i+2
> i=i+35
> etc.
> 
> 
> 
> 
> > 3. Do the results not include 2 of 5 because we wrote if i==2 and if i==5?
> 
> The print results don't include 2 or 5 because you said 'continue' if 2 
> and 'break' if 5.  So you skipped over 2, and exited at 5.
> 
> 
> 
> 
> > 4. How is i equal to 2 or 5 if i=0?
> 
> i=0 before you entered the While loop.  Then you increment it by one 
> (i=i+1) on each iteration of the loop.
> 
> 
> 
> > Thanks for all of your help!
> 
> 
> Also, there's a million python resources on the web.
> 
> http://www.pythonschool.net/basics/while-loops/

Got it! Thank you!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Break and Continue: While Loops

[Elizabeth Weiss]

On Thursday, June 23, 2016 at 12:17:23 AM UTC-4, Elizabeth Weiss wrote:
> CODE #1:
> 
> i=0
> while 1==1:
>print(i)
>i=i+1
>if i>=5:
>  print("Breaking")
>  break
> 
> --
> I understand that i=0 and i will only be printed if 1=1
> The results of this is
> 0
> 1
> 2
> 3
> 4
> Breaking
> 
> Why is Breaking going to be printed if i only goes up to 4? It does say if 
> i>=5? Shouldn't this mean that the results should be:
> 0
> 1
> 2
> 3
> 4
> 5
> 
> CODE #2:
> 
> i=0
> while True:
>i=i+1
>   if i==2:
>  print("Skipping 2")
>  continue
>   if i==5:
>  print("Breaking")
>  break
>print(i)
> 
> --
> 
> Questions:
> 1. what does the word True have to do with anything here? 
> 2. i=i+1- I never understand this. Why isn't it i=i+2?
> 3. Do the results not include 2 of 5 because we wrote if i==2 and if i==5?
> 4. How is i equal to 2 or 5 if i=0?
> 
> Thanks for all of your help!

Thank you, everyone!!! It all makes sense now!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Assignment Versus Equality

[Christopher Reimer]

On 6/26/2016 6:21 AM, Steven D'Aprano wrote:


On Sun, 26 Jun 2016 08:48 pm, BartC wrote:


On 26/06/2016 08:36, Lawrence D’Oliveiro wrote:

One of Python’s few mistakes was that it copied the C convention of using
“=” for assignment and “==” for equality comparison.

One of C's many mistakes. Unfortunately C has been very influential.

However, why couldn't Python have used "=" both for assignment, and for
equality? Since I understand assignment ops can't appear in expressions.

Personally, I think that even if there is no *syntactical* ambiguity between
assignment and equality, programming languages should still use different
operators for them. I must admit that my first love is still Pascal's :=
for assignment and = for equality, but C's = for assignment and == for
equality it *almost* as good.

(It loses a mark because absolute beginners confuse the assignment = for the
= in mathematics, which is just different enough to cause confusion.)

But the BASIC style = for both assignment and equality is just begging for
confusion. Even though = is not ambiguous given BASIC's rules, it can still
be ambiguous to beginners who haven't yet digested those rules and made
them second nature.

And even experts don't always work with complete statements. Here is a
snippet of BASIC code:

X = Y

Is it an assignment or an equality comparison? Without seeing the context,
it is impossible to tell:

10 X = Y + 1
20 IF X = Y GOTO 50


Now obviously BASIC was a very popular and successful language, for many
years, despite that flaw. But I wouldn't repeat it in a new language.



It should have copied the old convention from Algol-like languages
(including Pascal), where “:=” was assignment, so “=” could keep a
meaning closer to its mathematical usage.

(I think Fortran and PL/I also used "=" for assignment. Both were more
commercially successful than Algol or Pascal.)

Fortran 77 used .EQ. for equality. I'm not sure about PL/I.

I'm also not sure I'd agree about the commercial success. Fortran certainly
has been extremely popular, albeit almost entirely in numerical computing.
But PL/I has virtually disappeared from the face of the earth, while Pascal
still has a small but dedicated community based on FreePascal, GNU Pascal,
and Delphi.

(Of the three, FreePascal and Delphi appear to still be getting regular
releases.)


I started writing a BASIC interpreter in Python. The rudimentary version 
for 10 PRINT "HELLO, WORLD!" and 20 GOTO 10 ran well. The next version 
to read each line into a tree structure left me feeling over my head. So 
I got "Writing Compilers & Interpreters: An Applied Approach" by Ronald 
Mak (1991 edition) from Amazon, which uses C for coding and Pascal as 
the target language.  I know a little bit of C and nothing of Pascal. 
Translating an old dialect of C into modern C, learning Pascal and 
figuring out the vagaries of BASIC should make for an interesting 
learning experience.


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

Re: Assignment Versus Equality

[Christopher Reimer]

On 6/26/2016 8:41 AM, MRAB wrote:


On 2016-06-26 11:48, BartC wrote:

On 26/06/2016 08:36, Lawrence D’Oliveiro wrote:
One of Python’s few mistakes was that it copied the C convention of 
using “=” for assignment and “==” for equality comparison.


One of C's many mistakes. Unfortunately C has been very influential.

However, why couldn't Python have used "=" both for assignment, and for
equality? Since I understand assignment ops can't appear in expressions.


[snip]

Python supports chained assignments. For example, "a = b = 0" assigns 
0 to both a and b.


I'm not sure how common it is, though. I virtually never use it myself.


How can you not use chained assignments? I thought Python was the art of 
the clever one-liners. :)


Chris R.

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

Re: Assignment Versus Equality

[Michael Torrie]

On 06/26/2016 12:47 PM, Christopher Reimer wrote:
> I started writing a BASIC interpreter in Python. The rudimentary version 
> for 10 PRINT "HELLO, WORLD!" and 20 GOTO 10 ran well. The next version 
> to read each line into a tree structure left me feeling over my head. So 
> I got "Writing Compilers & Interpreters: An Applied Approach" by Ronald 
> Mak (1991 edition) from Amazon, which uses C for coding and Pascal as 
> the target language.  I know a little bit of C and nothing of Pascal. 
> Translating an old dialect of C into modern C, learning Pascal and 
> figuring out the vagaries of BASIC should make for an interesting 
> learning experience.

Sounds like fun.  Every aspiring programmer should write an interpreter
for some language at least once in his life!

I imagine that any modern dialect of BASIC has a very complex grammar.
The syntax is full of ambiguities, of which the "=" operator is the
least of them.  In many dialects there several versions of END to
contend with, for example.  And then there are a lot of legacy
constructs with special syntax such as LINE (0,0)-(100,100),3,BF.

I have a soft spot in my heart for BASIC, since that's what I grew up
on. I still follow FreeBASIC development. It's a very mature language
and compiler now, though it struggles to find a reason to exist I think.
 It can't decide if it's C with a different syntax, or C++ with a
different syntax (object-oriented and everything) or maybe something in
between or completely different.

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

Getting back into PyQt and not loving it.

[Michael Torrie]

I'm starting to question the advice I gave not long ago to for new users
to consider the Qt toolkit with Python.

I just did a little project porting a simple graphical user interface
from GTK+ to Qt (PyQt4 for now as that's what I have installed).  For
the most part it worked out pretty well.  It's been a while since I used
PyQt or PySide, and I had forgotten what a horrid Python experience Qt
really is, at least in PyQt4.  Maybe the bindings for Qt5 are better...
I'll be working with them next as I convert my working code.

Qt's a fantastic toolkit, and the most mature of any of them, and the
most portable, but man the bindings are not Pythonic at all. PyQt does
not seem to hide the C++-isms at all from the programmer.  I am
constantly wrapping things up in Qt classes like QRect, QPoint, QSize,
etc, when really a python Tuple would have sufficed.  All the data
structures are wrapped in Qt C++ classes, so you end up writing what is
really idiomatic C++ code using Python syntax. Not the best way to code
Python!  Implementing signals in a class, too, reminds you strongly that
you're working with C++ as you have to construct their method signatures
using types that map back into C++.

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

Re: Can math.atan2 return INF?

[Gregory Ewing]

Marko Rauhamaa wrote:

The singularity being talked about there is an artifact of a
particular coordinate system; the theory predicts that there is no
*physical* singularity at the event horizon.


That theory can't be tested even in principle, can it? Therefore, it is
not scientific.


It can in principle be tested by a scientist falling into
the hole. The only problem is that he won't be able to
tell anyone outside what he finds out, but that's a
practical difficulty, not a philosophical one.

A lot of what the early Greeks found out got lost in
various library burnings, etc. Does that mean they
weren't being scientific?


Religious theories about the afterlife face similar difficulties -- and
present similar extrapolations.


I don't think they're similar at all. Show me the equations
for one of these religious theories and I might change
my mind...

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

Re: Assignment Versus Equality

[Gregory Ewing]

BartC wrote:

On 26/06/2016 08:36, Lawrence D’Oliveiro wrote:

One of Python’s few mistakes was that it copied the C convention of 
using “=” for assignment and “==” for equality comparison.


One of C's many mistakes. Unfortunately C has been very influential.


I'm not sure it's fair to call it a mistake. C was
designed for expert users, and a tradeoff was likely
made based on the observation that assignment is
used much more often than equality testing.

However, why couldn't Python have used "=" both for assignment, and for 
equality?


Because an expression on its own is a valid statement,
so

   a = b

would be ambiguous as to whether it meant assigning b
to a or evaluating a == b and discarding the result.

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

Re: Assignment Versus Equality

[Gregory Ewing]

BartC wrote:

I did a year of it in the 1970s. Looks funny in lower case though.


It's interesting how our perceptions of such things change.
Up until my second year of university, my only experiences
of computing had all been in upper case. Then we got a
lecturer who wrote all his Pascal on the blackboard in
lower case, and it looked extremely weird. Until then the
idea of writing code in anything other than upper case
hadn't even occurred to me.

I quickly got used to it though, and nowadays, code written
in upper case looks very quaint and old-fashioned!

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

Re: Assignment Versus Equality

[BartC]

On 27/06/2016 00:22, Gregory Ewing wrote:

BartC wrote:

On 26/06/2016 08:36, Lawrence D’Oliveiro wrote:


One of Python’s few mistakes was that it copied the C convention of
using “=” for assignment and “==” for equality comparison.


One of C's many mistakes. Unfortunately C has been very influential.


I'm not sure it's fair to call it a mistake. C was
designed for expert users, and a tradeoff was likely
made based on the observation that assignment is
used much more often than equality testing.


You mean the rationale was based on saving keystrokes?

A shame they didn't consider that when requiring parentheses around 
conditionals, semicolons, /*...*/ around comments, %d format codes and 
elaborate for-statements then!


But you might be right in that it was probably based on existing usage 
of Fortran, PL/I and maybe even Basic. (Its predecessor 'B' used "=", 
but B came through BCPL which I believe used ":="; perhaps the mistake 
was in discarding that.)



However, why couldn't Python have used "=" both for assignment, and
for equality?


Because an expression on its own is a valid statement,
so

   a = b

would be ambiguous as to whether it meant assigning b
to a or evaluating a == b and discarding the result.


And that would be another reason why == is needed for equality.

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

Re: Assignment Versus Equality

[Gregory Ewing]

Christopher Reimer wrote:
How can you not use chained assignments? I thought Python was the art of 
the clever one-liners. :)


No, Python is the art of writing clever one-liners
using more than one line.

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

Re: Getting back into PyQt and not loving it.

[llanitedave]

On Sunday, June 26, 2016 at 2:45:18 PM UTC-7, Michael Torrie wrote:
> I'm starting to question the advice I gave not long ago to for new users
> to consider the Qt toolkit with Python.
> 
> I just did a little project porting a simple graphical user interface
> from GTK+ to Qt (PyQt4 for now as that's what I have installed).  For
> the most part it worked out pretty well.  It's been a while since I used
> PyQt or PySide, and I had forgotten what a horrid Python experience Qt
> really is, at least in PyQt4.  Maybe the bindings for Qt5 are better...
> I'll be working with them next as I convert my working code.
> 
> Qt's a fantastic toolkit, and the most mature of any of them, and the
> most portable, but man the bindings are not Pythonic at all. PyQt does
> not seem to hide the C++-isms at all from the programmer.  I am
> constantly wrapping things up in Qt classes like QRect, QPoint, QSize,
> etc, when really a python Tuple would have sufficed.  All the data
> structures are wrapped in Qt C++ classes, so you end up writing what is
> really idiomatic C++ code using Python syntax. Not the best way to code
> Python!  Implementing signals in a class, too, reminds you strongly that
> you're working with C++ as you have to construct their method signatures
> using types that map back into C++.

Not sure that wxPython is really any different in that respect, and Tkinter 
doesn't feel Pythonic to me, either -- considering how it's Tk at heart.  So 
what's the alternative?  There really is no good Python-based GUI tool, and 
that's a shame.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Getting back into PyQt and not loving it.

[Rustom Mody]

On Monday, June 27, 2016 at 6:35:31 AM UTC+5:30, llanitedave wrote:
> So what's the alternative?  There really is no good Python-based GUI tool, 
> and that's a shame.

The last time Ranting Rick made a big rant about this (saying wxpython should 
replace tkinter in core CPython) everyone took note of the rant
And missed the fact of the sux-state of GUI-in-python

Yes this is one big bus that python missed
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Getting back into PyQt and not loving it.

[MRAB]

On 2016-06-27 02:05, llanitedave wrote:

On Sunday, June 26, 2016 at 2:45:18 PM UTC-7, Michael Torrie wrote:

I'm starting to question the advice I gave not long ago to for new users
to consider the Qt toolkit with Python.

I just did a little project porting a simple graphical user interface
from GTK+ to Qt (PyQt4 for now as that's what I have installed).  For
the most part it worked out pretty well.  It's been a while since I used
PyQt or PySide, and I had forgotten what a horrid Python experience Qt
really is, at least in PyQt4.  Maybe the bindings for Qt5 are better...
I'll be working with them next as I convert my working code.

Qt's a fantastic toolkit, and the most mature of any of them, and the
most portable, but man the bindings are not Pythonic at all. PyQt does
not seem to hide the C++-isms at all from the programmer.  I am
constantly wrapping things up in Qt classes like QRect, QPoint, QSize,
etc, when really a python Tuple would have sufficed.  All the data
structures are wrapped in Qt C++ classes, so you end up writing what is
really idiomatic C++ code using Python syntax. Not the best way to code
Python!  Implementing signals in a class, too, reminds you strongly that
you're working with C++ as you have to construct their method signatures
using types that map back into C++.


Not sure that wxPython is really any different in that respect, and Tkinter 
doesn't feel Pythonic to me, either -- considering how it's Tk at heart.  So 
what's the alternative?  There really is no good Python-based GUI tool, and 
that's a shame.

Is it a problem with Tk itself or with the Python wrapper? Would it be 
better if we made a more Pythonic version of Tkinter, e.g. making 
Frame.title a property?


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

Re: Getting back into PyQt and not loving it.

[Michael Torrie]

On 06/26/2016 07:05 PM, llanitedave wrote:
> Not sure that wxPython is really any different in that respect, and
> Tkinter doesn't feel Pythonic to me, either -- considering how it's
> Tk at heart.  So what's the alternative?  There really is no good
> Python-based GUI tool, and that's a shame.

Guess I kind of ended my email early.

Actually GTK+ is pretty nice to work with in Python.  The bindings feel
quite good and it's hard to tell where stuff is written in python and
where it's written in C.  The integration between Python data types and
the glib backend stuff is pretty seamless. I can't recall ever wrapping
up stuff in a GObject structure, and Python idioms work rather well
including iteration.  Try it out; it's pretty slick.

GTK+'s downsides are that though it's available on Windows and Mac,
those versions don't get as much love and without some real work don't
integrate very well.  Also GTK+ development seems to focus more on Gnome
than on general application development.

If GTK+ had first-class support on Windows and Mac, including native
themes and seamless UI integration (file and print dialogs), I'd say
GTK+ would be the only game in town for Python programmers.
Unfortunately, unless you're only concerned with Linux, GTK+ is probably
not going to be your choice.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can math.atan2 return INF?

[Steven D'Aprano]

On Mon, 27 Jun 2016 09:08 am, Gregory Ewing wrote:

> Marko Rauhamaa wrote:
>>>The singularity being talked about there is an artifact of a
>>>particular coordinate system; the theory predicts that there is no
>>>*physical* singularity at the event horizon.
>> 
>> That theory can't be tested even in principle, can it? Therefore, it is
>> not scientific.
> 
> It can in principle be tested by a scientist falling into
> the hole. The only problem is that he won't be able to
> tell anyone outside what he finds out, but that's a
> practical difficulty, not a philosophical one.

Marko's complaint about black holes seems to be based on a very naive
definition of "scientific", specifically Karl Popper's naive empirical
falsification theory of science. Unfortunately, falsification is not even
close to a good description of what scientists do in their day-to-day work.

Naive empirical falsification can, at best, be considered as a best-practice
rule: if you have no way of falsifying something even in principle, then
it's not scientific. But it doesn't really give you much in the way of
practical guidance. What counts as falsification? How do you falsify
historical events like "the Earth formed from a cloud of gas"? We weren't
there to observe it, we can't repeat the experiment, and the entire process
from start to finish takes too long for anyone to watch a cloud of gas
coalesce into a solid planet.

So, black holes... 

We have no way of seeing what goes on past the black hole's event horizon,
since light cannot escape. But we can still see *some* properties of black
holes, even through their event horizon: their mass, any electric charge
they may hold, their angular momentum. We can test the proposition that a
black hole that forms from hydrogen is no different from one which forms
from uranium. We can look for variations in randomness in the Hawking
radiation emitted, we can test that the event horizon is where we expect,
etc. An electrically neutral black hole with a magnetic field would likely
falsify a lot of theories about what goes on inside the event horizon. 

And it may be that some future advance in quantum gravity theory will
suggest a way of testing the prediction of a singularity. There are
theories of black holes that predict "ring shaped" singularities, and
suggest that in principle one might "miss the singularity" and fall out of
a worm hole at the other end, although its doubtful that this would apply
to anything bigger than an atom.

I don't think many physicists actually believe that the singularity is a
real thing, rather than just a failure of our current gravitational
theories to correctly model matter under extreme conditions. After all,
we've been here before, with the prediction that a black-body should
radiate an infinite amount of energy at a finite temperature:

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

[...]
>> Religious theories about the afterlife face similar difficulties -- and
>> present similar extrapolations.
> 
> I don't think they're similar at all. Show me the equations
> for one of these religious theories and I might change
> my mind...

I don't think that the essential difference between a scientific theory and
a non-scientific one is the presence or absence of *equations*.

There's a lot of grey area between science and non-science, but I think a
good start is to ask, "how do you know?".

If the answer comes down to one of the following:


- divine revelation, including from gurus, angels and spirits;
- visions and inspiration;
- "it just stands to reason";
- "because otherwise, what would be the point?"

then its not scientific. The last means its wishful thinking. Maybe there is
no point. Perhaps things just are, and meaning is what we decide on, not an
inherent part of the universe. The third is just a cop-out. If you can't
explain the reason, there probably isn't one. And the first two are
necessarily subjective and forms of argument by authority:

All swans are white[1] because The Master said so, and who are you to
question The Master?

Whereas, I think that for a first degree approximation, we can say that
science must be *objective*. Often that does mean it involved equations,
after all the laws of mathematics are the same for all of us. But objective
fact does not necessarily require maths. Even in the ancient days of
humanity, we can be pretty sure that two Neandertals stepping out of their
cave to watch the sun rise in the east would agree on where the light was
coming from. If one faced into the sun and shaded her eyes, while the other
turned his back on the sun and shaded his eyes, we can be confident that
the second was mucking about :-)

And that's where all forms of religious revelation fail. Ultimately,
revelation divides the world into two:

- those who personally know the truth;
- and those who just have to take their word for it.


"God wants you to give me your money, honest. Oh, and he also doesn't want
you to eat carrots. Don't question

Empty List

[Elizabeth Weiss]

Hi There, 

What is the point of this code?:

word=[]
print(word)

The result is []

When would I need to use something like this? 

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

Re: argparse and subparsers

[Lawrence D’Oliveiro]

On Monday, June 27, 2016 at 6:56:41 AM UTC+12, Joseph L. Casale wrote:
> This has become unmaintainable as the manual slicing is always subject
> to a new case by where a parser has a positional, switch or optional
> parameter for example. Also, since argv is grouped by subparser
> specifiers, if a parameter has input that matches a keyword
> it all goes pear shaped.

Write your own parser. It’s not hard--the common Unix/Linux command line 
conventions are quite simple, and it’s already pre-split into words for you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Empty List

[Steven D'Aprano]

On Mon, 27 Jun 2016 01:13 pm, Elizabeth Weiss wrote:

> Hi There,
> 
> What is the point of this code?:
> 
> word=[]
> print(word)
> 
> The result is []
> 
> When would I need to use something like this?

As given, never. Nor would you need:

num = 0
print(num)


It's pretty boring, trivial code that does nothing interesting. And you
could simplify it, make it even more trivial:

print([])


Why would you do that? You probably wouldn't bother.

But each line is very useful, if taken as part of a bigger, more useful
program! Look at the first line:

word = []

This creates a variable, "word", and assigns an empty list to it.

But once you have an empty list, you can start putting things into it. Once
you have a list with items in it, there are all sorts of things you can
usefully do:

- append items to the end;
- insert items at the start or the middle;
- sort the list;
- reverse the list;
- pull items out of the list;
- count how many items are in the list;
- search for matching items

and many more. The sky is the limit, and that's what programming is about.
Just because the list *starts* as empty doesn't mean it must remain empty
forever.



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

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

Re: Empty List

[Christopher Reimer]

On 6/26/2016 8:13 PM, Elizabeth Weiss wrote:


Hi There,

What is the point of this code?:

word=[]
print(word)

The result is []

When would I need to use something like this?

Thank you!


Sometimes you need to assign an empty list to a variable prior to using 
it in a looping structure.


Here's the load function from the BASIC interpreter/compiler I'm working 
on in Python.


def load(filename):
tokens = []
with open(filename) as source:
for line in source:
tokens.append(tokenizer(line))
return tokens

Here's the BASIC file I'm loading:

10 PRINT "HELLO WORLD!"
20 GOTO 10

This function assigns an empty list to tokens, reads a line of text from 
a file, and appends a tokenized list to tokens, and return tokens as a 
list of lists.


[['10', 'PRINT', '"HELLO WORLD!"'], ['20', 'GOTO', '10']]

Chris R.



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

Operator Precedence: One Thing Python Got Right

[Lawrence D’Oliveiro]

There is one thing Python did not slavishly copy from C. While it has (mostly) 
the same operators, and exclusively adopted the iso646 names for the Boolean 
operators (which you can also use in C and C++, by the way, but not Java), it 
made a slight tweak to the operator precedence rules 
. 
Namely, whereas in C, C++ or Java you have to write

(bitval & bitmask) == needbits

in Python you can dispense with the parentheses

bitval & bitmask == needbits

How did I discover this? Entirely by accident: I forgot the parentheses one day 
and *didn’t* hit a bug. :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator Precedence: One Thing Python Got Right

[Steven D'Aprano]

On Mon, 27 Jun 2016 02:20 pm, Lawrence D’Oliveiro wrote:

> There is one thing Python did not slavishly copy from C.

Only one?




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

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

Re: Question on compiling on linux

[Zachary Ware]

On Saturday, June 25, 2016, Steven Truppe  wrote:
>
> i hope this email works like you expected!

Not quite, but closer.  You've quoted me properly, but you added your
reply above the quote, so-called "top-posting".

A: Because you have to read things in reverse order.
Q: Why?
A: Top-posting.
Q: What's one of the most annoying common email practices?

But that's all rather beside the point :)

> I found the libpython3.so, i don't know why i was not able to see it,

Note that libpython3.so is very different from libpython3.5m.so:
libpython3.so is the interface to the PEP 384 stable ABI.  It does not
include the full interpreter, and is in fact just a shim that
redirects to libpython3.5m.so.  It's only really useful for building
extension modules and using the resulting binary with multiple
versions of Python.

> thank you very much to everyone wo helped me!

I'm glad we've been able to clear things up a bit!

> No my last question(s) is how can i create debug/release builds ?

Pass '--with-pydebug' to ./configure to get a debug build.  On Linux,
the difference between a debug and release build is just the
definition of debug-related macros (Py_DEBUG, _DEBUG, NDEBUG) and the
optimization level.  On Windows, another big difference in a debug
build is that it is linked against the debug CRT.  There is no such
thing on Linux, so you likely won't need a debug version of Python
just to debug your embedding app the way you would on Windows.

Hope this helps,
--
Zach
-- 
https://mail.python.org/mailman/listinfo/python-list

Language improvement: Get more from the `for .. else` clause

[Victor Savu]

tl;dr: 1. Add `StopAsyncIteration.value`, with the same semantic as
   `StopIteration.value` (documented in PEP 380).
   2. Capture `StopIteration.value` and StopAsyncIteration.value in the
   `else` clauses of the `for` and `async for` statements respectively.
Note: I already have a proof-of-concept implementation:
repository:   https://github.com/Victor-Savu/cpython
branch: feat/else_capture


Dear members of the Python list,

I am writing to discuss and get the community's opinion on the following two
ideas:

 1. Capture the `StopIteration.value` in the `else` clause of the `for ..
else`
statement:

Generators raise StopIteration on the return statement. The exception
captures the return value. The `for` statement catches the
`StopIteration`
exception to know when to jump to the optional `else` statement, but
discards the enclosed return value.

I want to propose an addition to the Python syntax which gives the
option
to capture the return value in the `else` statement of the `for` loop:

```
def holy_grenade():
yield 'One ...'
yield 'Two ...'
yield 'Five!'
return ('Galahad', 'Three')

for count_ in holy_grenade():
print("King Arthur: {count_}")
else knight, correction:  # << new capture syntax here
print(f"{knight}: {correction}, Sir!")
print(f"King Arthur: {correction}!")
```

prints:
```
King Arthur: One ...
King Arthur: Two ...
King Arthur: Five!
Galahad: Three, Sir!
King Arthur: Three!
```

Of course, the capture expression is optional, and omitting it preserves
the current behavior, making this proposed change backwards compatible.
Should the iterator end without raising the StopIteration exception,
the value `None` will be implicitly passed to the capture expression. In
the example above, this will result in:
```
TypeError: 'NoneType' object is not iterable
```
because of the attempt to de-structure the result into `knight` and
`correction`.

 2. Add a `StopAsyncIteration.value` member which can be used to transfer
information about the end of the asynchronous iteration, in the same way
the `StopIteration.value` member is used (as documented in PEP 380).
Capture this value in the in the else clause of the `async for`
statement
in the same way as proposed for the `StopIteration.value` in the
previous
point.

You can find a working proof-of-concept implementation of the two proposed
changes in my fork of the semi-official cpython repository on GitHub:
repository: https://github.com/Victor-Savu/cpython
branch: feat/else_capture

Disclaimer: My Internet searching skills have failed me and I could not find
any previous discussion on any of the two topics. If you are aware of such
discussion, I would be grateful if you could point it out.

I look forward to your feedback, ideas, and (hopefully constructive)
criticism!


Best regards,
Victor
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: argparse and subparsers

[Sachin Garg]

On Sunday 26 June 2016 02:51 PM, Joseph L. Casale wrote:
> I have some code where sys.argv is sliced up and manually fed to discrete 
> argparse
> instances each with a single subparser. The reason the discrete parsers all 
> having a
> single subparser was to make handling the input simpler, the first arg in the 
> slice
> could be left in.
> 
> This has become unmaintainable as the manual slicing is always subject to a 
> new case
> by where a parser has a positional, switch or optional parameter for example. 
> Also, since
> argv is grouped by subparser specifiers, if a parameter has input that 
> matches a keyword
> it all goes pear shaped.
> 
> The underlying root of this mess is a long unaddressed limitation in argparse 
> to support
> multiple subparser specifications on the same invocation:
> 
> prog.py -x -y 42 -foo bar subParserA -a 1 -b 2 subParserB -a 1 -b 2 
> subParserB -a 1 -b 2
> 
> The base arguments (-x -y 42 -foo bar).
> An invocation of "subParserA" and its arguments (-a 1 -b 2).
> Two invocations of "subParserB" and their arguments.
> 
> etc...
> 
> I have seen some creative ways to overcome this on stacktrace, however I 
> thought I'd
> see what people here have done. The code is pinned at 2.7 and while several 
> people
> have created alternate implementations which address many of argparses 
> failures, its
> desired to stick to base lib but that can easily be changed given a 
> compelling reason
> if an alternate implementation exists that works well.


Not sure if this fits the bill, or makes sense here, but I came cross
"docopt" which touts itself as a "Command-line interface description
language". I used it in a project and it seems to be pretty easy to use
as well as elegant. It stores the arguments & values as a dictionary,
keyed by the argument.

from docopt import docopt

arguments = docopt(__doc__, version='0.2')

# Set verbose flag
verbose = False
if arguments['--verbose']:
verbose = True
elif arguments['-q']:
verbose = False

# If --noencrypt, --nosign or --notransfer is specified, put that in config
if arguments['--no-encrypt']:
config['noencrypt'] = True
else:
config['noencrypt'] = False

if arguments['--no-sign']:
config['nosign'] = True
else:
config['nosign'] = False

if arguments['--no-transfer']:
config['notransfer'] = True
else:
config['notransfer'] = False

and so on ...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: argparse and subparsers

[Lawrence D’Oliveiro]

On Monday, June 27, 2016 at 4:56:10 PM UTC+12, Sachin Garg wrote:

> # Set verbose flag
> verbose = False
> if arguments['--verbose']:
> verbose = True
> elif arguments['-q']:
> verbose = False

Don’t you just love code (and commenting) like this...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Getting back into PyQt and not loving it.

[John Ladasky]

On Sunday, June 26, 2016 at 7:41:17 PM UTC-7, Michael Torrie wrote:
> If GTK+ had first-class support on Windows and Mac, including native
> themes and seamless UI integration (file and print dialogs), I'd say
> GTK+ would be the only game in town for Python programmers.
> Unfortunately, unless you're only concerned with Linux, GTK+ is probably
> not going to be your choice.

Although I work almost exclusively in Linux, I've been teaching Python for 
several years as a sideline, and my students usually do not use Linux.  I 
insist on teaching my students Python 3.  Unless they're professionals who must 
work with legacy code (and, so far, none of them have been), I think I would be 
doing them a disservice to teach them Python 2.

I started with WxPython, but WxPython/Phoenix has been very slow to migrate to 
Python 3.  

Between the Py3 requirement and the need to work with all major OS's, I decided 
to learn PyQt and not GTK+.  

In my current day job, I'm developing an application on a Linux box, but I'll 
be handing it off to Windows users.  My choice of PyQt turned out to be the 
right one in that situation as well.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can math.atan2 return INF?

[Marko Rauhamaa]

Steven D'Aprano :

> Naive empirical falsification can, at best, be considered as a
> best-practice rule: if you have no way of falsifying something even in
> principle, then it's not scientific. But it doesn't really give you
> much in the way of practical guidance. What counts as falsification?

We cannot get any information on black holes proper because black holes
cannot come into existence according to the very theory that predicts
black holes. It will take infinitely long for an event horizon to form.
Speculating on what happens to an astronaut falling in is not much
different from speculating what happens after the end of the world.

> We have no way of seeing what goes on past the black hole's event
> horizon, since light cannot escape. But we can still see *some*
> properties of black holes, even through their event horizon: their
> mass, any electric charge they may hold, their angular momentum.

If an event horizon cannot come into existence, you can only see
properties of almost-black-holes. Even though there probably is
virtually no difference between the two astronomically, it relieves
physicists from answering some awkward questions on the goings-on inside
an event horizon.

> We can test the proposition that a black hole that forms from hydrogen
> is no different from one which forms from uranium. We can look for
> variations in randomness in the Hawking radiation emitted, we can test
> that the event horizon is where we expect, etc. An electrically
> neutral black hole with a magnetic field would likely falsify a lot of
> theories about what goes on inside the event horizon.

If an event horizon cannot ever form, you can't really test any of that
stuff.


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

Re: Getting back into PyQt and not loving it.

[Lawrence D’Oliveiro]

On Monday, June 27, 2016 at 6:16:01 PM UTC+12, John Ladasky wrote:

> Between the Py3 requirement and the need to work with all major OS's, I
> decided to learn PyQt and not GTK+.  

GTK+ is available for Python 3.

No doubt it will work on Windows as well, once Microsoft gets its Linux 
compatibility layer debugged...
-- 
https://mail.python.org/mailman/listinfo/python-list