Re: I seem to be creating a dict that I cannot access the keys of

[dieter]

Sayth Renshaw  writes:
>> The code below is obviously wrong - it is surprising that you get
>> anything other than an exception. See comments below inserted into
>> your code.
>> 
>> > def parseXML():
>> > ...
>> > result = etree.tostring(tree.getroot(), pretty_print=True)
>> 
>> "result" here is obviously a string.
>> 
>> > for sample in result:
>> 
>> This means that "sample" successively hold the characters composing
>> the string "result".
>> 
>> > noms = (dict(zip(atts, map(sample.attrib.get, atts
>> 
>> You should get "AttributeError: str object does not have attribute `attrib`".
>
> The attrib is an lxml function, when you have defined a root 
> http://lxml.de/tutorial.html

Correctly, this should read: "attrib" is an attribute of "ETree" nodes (!)
(providing a mapping like access to the nodes attributes).

It is *NOT* an attribute of string (!) objects.

You have converted the tree root into a string (using "etree.tostring")
and then iterated over the resulting string. On those characters
you access "attrib" - which will not work as you expect.

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

Re: Getting back into PyQt and not loving it.

[lorenzo . gatti]

PyGTK is obsolete and stopped at Python 2.7, while PyGObject for Windows is 
several versions behind (currently 3.18 vs 3.21) and it doesn't support Python 
3.5. Game over for GTK+.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Getting back into PyQt and not loving it.

[Mark Summerfield]

On Monday, June 27, 2016 at 3:12:34 AM UTC+1, MRAB wrote:
[snip]
> > 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?

My main complaints about Tkinter are:

- Not very Pythonic.

- The event handling works very differently from other toolkits so it can be 
quite tricky to learn and get right.

- The bindings are incomplete (e.g., http://bugs.python.org/issue3405)

And for me there are show-stopping weaknesses.

- Show stopper #1: there is no nice way to create custom widgets. Compare with 
PySide, PyQt (& wxPython I believe) where you can inherit some "widget" base 
class and paint it however you like and do any event handling you like to get 
custom appearance and behaviour. Sure, you can do this with canvas as the base, 
but it seems like you have do do far more work in Tkinter than the other 
toolkits.

- Show stopper #2: there doesn't seem to be any way to create one line and 
multiline styled text editors (e.g., supporting bold, italic, underline, 
superscript, subscript, colour, font). The text widget can display all these 
(and more) but I haven't found any way to get it to be able to provide 
_editing_ of all these. (You can get it to do bold, italic, underline, and 
colour, but I certainly can't get these plus super- and sub-script and font 
support from Python. Nor is there any useful load/save in HTML or any other 
format.)

Hopefully people will point me to docs or examples to prove me wrong about 
these weaknesses:-)

Or better still, maybe the seemingly moribund PyGUI project could be revived or 
maybe someone will create bindings for libui or for IUP so that Python could 
have a lightweight GUI-only cross-platform library that had decent support for 
creating custom widgets in Python but left all non-GUI functionality to the 
rest of the Python ecosystem.
-- 
https://mail.python.org/mailman/listinfo/python-list

Running yum/apt-get from a virtualenv

[Tiglath Suriol]

Let us say that I install PostgreSQL from an activated virtualenv using yum or 
apt-get, will PostgrSQL be local or global?  

I understand that virtualenv isolates the Python environment only, so I surmise 
that it will make no difference installing with yum/apt-get inside or outside 
the virtualenv.  

But that would not be the case with say Psycopg2 which would be isolated in the 
virtualenv, because it is a Python module.  Is that right?  

Thanks

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

Re: Empty List

[Pierre-Alain Dorange]

Elizabeth Weiss  wrote:

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

You often need to intialize a list, sometime with (empty)  = [].
Then after initializing you should do "something" that perhaps will fill
the list (word.append("hello").
Then after do your job, you perhaps need to print it.

But initializing and just print, will do nothing else than initialize
and print the result...

As state before this code more or less like :

a=0
print a

-- 
Pierre-Alain Dorange   Moof 

Ce message est sous licence Creative Commons "by-nc-sa-2.0"

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

Re: Operator Precedence: One Thing Python Got Right

[BartC]

On 27/06/2016 05:20, Lawrence D’Oliveiro wrote:

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


C has some 15 operator precedences (even if you consider only normal 
binary operators, there are 10; and that doesn't include "**").


It's not something you would choose to adopt in another language!

(On the subject of things wrong with C, here's a list I made of around 100:

https://github.com/bartg/langs/blob/master/C%20Problems.md

Although from the point of view of a more streamlined and modern 
low-level statically-typed language, not of one like Python.)



How did I discover this? Entirely by accident: I forgot the parentheses one day 
and *didn’t* hit a bug. :)


That's not wise. It could have worked by chance. And putting in the 
parentheses anyway means the fragment of code stays interchangeable with C.


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

Re: argparse and subparsers

[Steven D'Aprano]

On Monday 27 June 2016 15:34, Lawrence D’Oliveiro wrote:

> 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...


Not particularly, but what are you going to do? You need to support a minimum 
of three cases:

- a default setting;
- the case where the user passes --verbose;
- the case where the user passes -q;

(I'm not sure why --verbose take a long argument but no short argument -v; and 
likewise why there's a -q short argument but no --quiet long version. Oh well.)

A simple test-and-set for each argument is the simplest, most straight-forward 
way of handling this. It's not *pretty* or *elegant* code, but it is the 
easiest to read, write and comprehend, and in my opinion much better than 
alternatives involving ever more arcane method calls to ever more complicated 
classes.

I don't have experience with docutils and cannot judge whether or not Sachin's 
snippets are good or bad examples of use, but find myself going back to the 
good old fashioned GNU style command line parser whenever I need a few command 
line options. If you find yourself writing subparsers and "mandatory options" 
and needing entire help screens to describe single arguments (as in "foo --help 
arg") then really I think you should give up the pretence that you're dealing 
with command line options, and you should write a mini-language for your 
application.

(hg, git, memcoder, soc etc. I'm talking about you.)



-- 
Steve

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

Re: Operator Precedence: One Thing Python Got Right

[Steven D'Aprano]

On Mon, 27 Jun 2016 07:53 pm, BartC wrote:

> On 27/06/2016 05:20, Lawrence D’Oliveiro wrote:

>> How did I discover this? Entirely by accident: I forgot the parentheses
>> one day and *didn’t* hit a bug. :)
> 
> That's not wise. It could have worked by chance. And putting in the
> parentheses anyway means the fragment of code stays interchangeable with
> C.

Do you write much Python code that you expect to also be valid C code?


 

-- 
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

[Bob Gailer]

On Jun 26, 2016 5:29 PM, "Michael Torrie"  wrote:
>
> On 06/26/2016 12:47 PM, Christopher Reimer wrote:

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

In the mid 1970' s I helped maintain an installation of IBM' s APL
interpreter at Boeing Computer Services. APL uses its own special character
set, making code unambiguous and terse. It used a left-arrow for
assignment, which was treated as just another operator. I will always miss
"embedded assignment".

A year later I worked on a project that ran on a CDC 6600? where only
FORTRAN was available. The program's job was to apply user's commands to
manage a file system. FORTRAN was not the best language for that task, so I
designed my own language, and wrote an interpreter for it in FORTRAN. In
retrospect a very good decision. That program was in use for 10 years!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Assignment Versus Equality

[Rustom Mody]

On Monday, June 27, 2016 at 5:53:07 PM UTC+5:30, Bob Gailer wrote:
> On Jun 26, 2016 5:29 PM, "Michael Torrie"  wrote:
> >
> > On 06/26/2016 12:47 PM, Christopher Reimer wrote:
> 
> > Sounds like fun.  Every aspiring programmer should write an interpreter
> > for some language at least once in his life!
> 
> In the mid 1970' s I helped maintain an installation of IBM' s APL
> interpreter at Boeing Computer Services. APL uses its own special character
> set, making code unambiguous and terse. It used a left-arrow for
> assignment, which was treated as just another operator. I will always miss
> "embedded assignment".


In the past, APL's ← may not have been practicable (ie
- without committing to IBM... which meant
- $$$ 
- Also it was a hardware commitment (trackball?)
- etc

Today that '←' costs asymptotically close to '='
To type :: 3 chars CAPSLOCK '<' '-'
To setup :: [On Ubuntu Unity]
   System-Settings → Keyboard → Shortcuts-Tab → Typing → Make Compose CAPSLOCK
To see :: Its ONE CHAR, just like '=' and ½ of ':='

tl;dr Anyone opposing richer charsets is guaranteedly using arguments from 1970

PS Google Groups is wise enough to jump through hoops trying to encode my 
message
above as latin-1, then as Windows 1252 and only when that does not work as 
UTF-8
ie it garbles ← into <- etc
So some हिंदी (ie Hindi) to convince GG to behave
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can math.atan2 return INF?

[Rustom Mody]

On Monday, June 27, 2016 at 12:10:21 PM UTC+5:30, Marko Rauhamaa wrote:
> 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.

I am reminded of an argument I once had with a colleague about
infinite, lazy data-structures

I said that for the Haskell list [0..]

[0..] ++ [-1] == [0..]

++ is like python's list append +

This could equally apply to a Python generator like:

def nats():
  i=0
  while True:
 yield i
 i += 1

He said (in effect) yes that -1 would not be detectable but its still there!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Assignment Versus Equality

[Steven D'Aprano]

On Mon, 27 Jun 2016 10:48 pm, Rustom Mody wrote:

> PS Google Groups is wise enough to jump through hoops trying to encode my
> message above as latin-1, then as Windows 1252 and only when that does not
> work as UTF-8


There is nothing admirable about GG (or any other newsreader or email
client) defaulting to legacy encodings like Latin-1 and especially not
Windows 1252.

Certainly the user should be permitted to explicitly set the encoding, but
otherwise the program should default to UTF-8.



-- 
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: Which one is the best JSON parser?

[Nagy László Zsolt]

On 2016-06-23, MRAB  wrote:
>> On 2016-06-23 21:58, David Shi via Python-list wrote:
>>> Can any one tell me?
>>> Regards.
>>> David
>>>
>> There's one in the standard library.
> Which has always worked fine for me...
Which always reminds me:

>>> import json
>>> d = {0:1, False:2}
>>> d
{0: 2}
>>> json.dumps(d)
'{"0": 2}'
>>>

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

Re: Can math.atan2 return INF?

[Nagy László Zsolt]

> Thanks, I'm in the same position as you, except that I'm in the position
> where I need it use the result, and if it ever returns INF my function will
> blow up. But it doesn't look like that can happen.
>
Doesn't atan2 relies on the C lib math floating point library? At least
in CPython. I think (but not 100% sure) that it is implementation
dependent, and returns what is returned by clib floating point lib.
Since the meaning of atan2 is an angle, it should always be between
[-pi,pi]. The only exception maybe when there is a NaN in the arguments.
But I cannot think of any interpretation where atan2 would return Inf or
-Inf.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which one is the best JSON parser?

[Ned Batchelder]

On Monday, June 27, 2016 at 9:31:04 AM UTC-4, Nagy László Zsolt wrote:
> On 2016-06-23, MRAB  wrote:
> >> On 2016-06-23 21:58, David Shi via Python-list wrote:
> >>> Can any one tell me?
> >>> Regards.
> >>> David
> >>>
> >> There's one in the standard library.
> > Which has always worked fine for me...
> Which always reminds me:
> 
> >>> import json
> >>> d = {0:1, False:2}
> >>> d
> {0: 2}
> >>> json.dumps(d)
> '{"0": 2}'
> >>>
> 
> WAT :-)

Python's booleans being ints is a remnant of history. I agree it would be
better for True and False to be unrelated to 1 and 0.

The conversion of 0 to "0" is because JSON can only use strings for keys in
objects. It might be better for dumps to fail if a non-string key is
encountered, but I'm not sure.

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

Re: Can math.atan2 return INF?

[Marko Rauhamaa]

Rustom Mody :

> I am reminded of an argument I once had with a colleague about
> infinite, lazy data-structures
>
> I said that for the Haskell list [0..]
>
> [0..] ++ [-1] == [0..]

[...]

> He said (in effect) yes that -1 would not be detectable but its still
> there!

Georg Cantor would probably be with your colleague, but then, Georg
Cantor was not a scientist.


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

Re: Question on compiling on linux

[Random832]

On Mon, Jun 27, 2016, at 00:26, Zachary Ware wrote:
> 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?

Which is witty, but doesn't *actually* explain why it's bad.

1. The intent, as I understand it, with top-posting is that the reply
message stands on its own, and the quoted message is just "attached" in
case someone needs to refer back to it, rather than representing a
conversational flow as the Q/A format does.

2. Most email clients sort messages or threads by date with the most
recent (or most recently updated) at the top, so there's no generalized
principle at work against having later things appear above earlier
things.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Assignment Versus Equality

[Grant Edwards]

On 2016-06-26, BartC  wrote:

> (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".)

I've always been baffled by that.

Were there other languages that did something similar?

Why would a language designer think it a good idea?

Did the poor sod who wrote the compiler think it was a good idea?

-- 
Grant Edwards   grant.b.edwardsYow! I left my WALLET in
  at   the BATHROOM!!
  gmail.com

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

Re: Assignment Versus Equality

[Marko Rauhamaa]

Steven D'Aprano :

> On Mon, 27 Jun 2016 10:48 pm, Rustom Mody wrote:
>
>> PS Google Groups is wise enough to jump through hoops trying to
>> encode my message above as latin-1, then as Windows 1252 and only
>> when that does not work as UTF-8
>
> There is nothing admirable about GG (or any other newsreader or email
> client) defaulting to legacy encodings like Latin-1 and especially not
> Windows 1252.
>
> Certainly the user should be permitted to explicitly set the encoding,
> but otherwise the program should default to UTF-8.

The users should be completely oblivious to such technicalities as
character encodings.

As for those technicalities, a MIME-compliant client is free to use any
well-defined, widely-used character encoding as long as it is properly
declared.


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

Re: Operator Precedence: One Thing Python Got Right

[Grant Edwards]

On 2016-06-27, Steven D'Aprano  wrote:

> Do you write much Python code that you expect to also be valid C code?

Depends on what you mean by "much", but yes, it's certainly something
I do.  I often develop and test algorithms in Python and then
cut/paste much of the Python code into C programs.  The more validated
code I can use verbatim, the less likely I'll bork something up by
having to translate it from Python to C.

-- 
Grant Edwards   grant.b.edwardsYow! ... I see TOILET
  at   SEATS ...
  gmail.com

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

Re: Can math.atan2 return INF?

[Rustom Mody]

On Monday, June 27, 2016 at 7:16:03 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
> 
> > I am reminded of an argument I once had with a colleague about
> > infinite, lazy data-structures
> >
> > I said that for the Haskell list [0..]
> >
> > [0..] ++ [-1] == [0..]
> 
> [...]
> 
> > He said (in effect) yes that -1 would not be detectable but its still
> > there!
> 
> Georg Cantor would probably be with your colleague, but then, Georg
> Cantor was not a scientist.

I'm mystified

Earlier (I thought) you were on the Platonist = {Cantor, Hilbert...} side
Now you sound like you are on the constructivist = {Kronecker, Brouwer } side
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Assignment Versus Equality

[Marko Rauhamaa]

Grant Edwards :

> On 2016-06-26, BartC  wrote:
>
>> (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".)
>
> I've always been baffled by that.
>
> Were there other languages that did something similar?

In XML, whitespace between tags is significant unless the document type
says otherwise. On the other hand, leading and trailing space in
attribute values is insignificant unless the document type says
otherwise.

> Why would a language designer think it a good idea?
>
> Did the poor sod who wrote the compiler think it was a good idea?

Fortran is probably not too hard to parse. XML, on the other hand, is
impossible to parse without the document type at hand. The document type
not only defines the whitespace semantics but also the availability and
meaning of the "entities" (e.g., © for ©). Add namespaces to that,
and the mess is complete.


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

Re: Can math.atan2 return INF?

[Marko Rauhamaa]

Rustom Mody :

> On Monday, June 27, 2016 at 7:16:03 PM UTC+5:30, Marko Rauhamaa wrote:
>> Georg Cantor would probably be with your colleague, but then, Georg
>> Cantor was not a scientist.
>
> I'm mystified
>
> Earlier (I thought) you were on the Platonist = {Cantor, Hilbert...}
> side
> Now you sound like you are on the constructivist = {Kronecker, Brouwer
> } side

I'm a formalist.


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

Re: Assignment Versus Equality

[Rustom Mody]

On Monday, June 27, 2016 at 7:30:05 PM UTC+5:30, Grant Edwards wrote:
> On 2016-06-26, BartC 
> > (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".)
> 
> I've always been baffled by that.
> 
> Were there other languages that did something similar?
> 
> Why would a language designer think it a good idea?
> 
> Did the poor sod who wrote the compiler think it was a good idea?

I think modern ideas like lexical analysis preceding parsing
and so on came some decade after Fortran.
My guess is that Fortran was first implemented -- 'somehow or other'
Then these properties emerged -- more or less bugs that had got so entrenched
that they had to be dignified as 'features'

Analogy: Python's bool as 1½-class because bool came into python a good decade
after python and breaking old code is a bigger issue than fixing control 
constructs to be bool-strict
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator Precedence: One Thing Python Got Right

[BartC]

On 27/06/2016 15:04, Grant Edwards wrote:

On 2016-06-27, Steven D'Aprano  wrote:


Do you write much Python code that you expect to also be valid C code?


Depends on what you mean by "much", but yes, it's certainly something
I do.  I often develop and test algorithms in Python and then
cut/paste much of the Python code into C programs.  The more validated
code I can use verbatim, the less likely I'll bork something up by
having to translate it from Python to C.



I bet your code isn't very 'Pythonic' then!

I have frequently had to convert foreign algorithms (into my own 
languages), and when there is a choice, such as on the Computer Language 
Shootout site, then I might typically choose Pascal or Lua as being the 
simplest and clearest to understand.


Languages such as Python tend to be too fond of using their unique 
features (which I also think can be a bit of a cheat when trying to 
compare benchmarks, but that's another matter). Unique features, which 
can include just using a built-in library call to do the work, don't 
translate so easily!


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

Re: Assignment Versus Equality

[Rustom Mody]

On Monday, June 27, 2016 at 6:58:26 PM UTC+5:30, Steven D'Aprano wrote:
> On Mon, 27 Jun 2016 10:48 pm, Rustom Mody wrote:
> 
> > PS Google Groups is wise enough to jump through hoops trying to encode my
> > message above as latin-1, then as Windows 1252 and only when that does not
> > work as UTF-8
> 
> 
> There is nothing admirable about GG (or any other newsreader or email
> client) defaulting to legacy encodings like Latin-1 and especially not
> Windows 1252.
> 
> Certainly the user should be permitted to explicitly set the encoding, but
> otherwise the program should default to UTF-8.

Its called sarcasm...

Also how is GG deliberately downgrading clear unicode content to be kind to 
obsolete clients at recipient end different from python 2 → 3 making breaking 
changes but not going beyond ASCII lexemes?

Just think: Some poor mono-lingual ASCII-user may suffer an aneurism...
Completely atrocious!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can math.atan2 return INF?

[Rustom Mody]

On Monday, June 27, 2016 at 7:42:26 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
> 
> > On Monday, June 27, 2016 at 7:16:03 PM UTC+5:30, Marko Rauhamaa wrote:
> >> Georg Cantor would probably be with your colleague, but then, Georg
> >> Cantor was not a scientist.
> >
> > I'm mystified
> >
> > Earlier (I thought) you were on the Platonist = {Cantor, Hilbert...}
> > side
> > Now you sound like you are on the constructivist = {Kronecker, Brouwer
> > } side
> 
> I'm a formalist.

Well then formalism is semantics-free: What matters it if an argument is
theological or scientific as long as it is (internally) consistent?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator Precedence: One Thing Python Got Right

[Grant Edwards]

On 2016-06-27, BartC  wrote:
> On 27/06/2016 15:04, Grant Edwards wrote:
>> On 2016-06-27, Steven D'Aprano  wrote:
>>
>>> Do you write much Python code that you expect to also be valid C code?
>>
>> Depends on what you mean by "much", but yes, it's certainly
>> something I do.  I often develop and test algorithms in Python and
>> then cut/paste much of the Python code into C programs.  The more
>> validated code I can use verbatim, the less likely I'll bork
>> something up by having to translate it from Python to C.
>
> I bet your code isn't very 'Pythonic' then!

No, not when the end goal is to move it into C.  Numerical stuff works
pretty well.  Handling byte streams (e.g. creating/decoding file and
protocol headers) isn't too bad.  For text processing, it doesn't work
very well.

-- 
Grant Edwards   grant.b.edwardsYow! There's enough money
  at   here to buy 5000 cans of
  gmail.comNoodle-Roni!

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

Re: Assignment Versus Equality

[Alain Ketterlin]

Grant Edwards  writes:

> On 2016-06-26, BartC  wrote:
>
>> (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".)
>
> I've always been baffled by that.
> Were there other languages that did something similar?

Probably a lot at that time.

> Why would a language designer think it a good idea?

Because when you punch characters one by one on a card, you quickly get
bored with less-than-useful spaces.

> Did the poor sod who wrote the compiler think it was a good idea?

I don't know, but he has a good excuse: he was one of the first to ever
write a compiler (see https://en.wikipedia.org/wiki/Compiler, the
section on History).

You just called John Backus a "poor sod". Think again.

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

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

[Michael Selik]

On Mon, Jun 27, 2016 at 12:53 AM Victor Savu 
wrote:

> capture the [StopIteration] value in the `else` statement of the `for` loop
>

I'm having trouble thinking of a case when this new feature is necessary.
Can you show a more realistic example?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Getting back into PyQt and not loving it.

[Michael Torrie]

On 06/27/2016 12:44 AM, Lawrence D’Oliveiro wrote:
> 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...

But that's not a solution for John's target audience.  Nor for most
users, honestly.  The Linux layer is targeted towards Azure developers
mainly, and not intended to be an application support layer.

GTK+ is working natively on Windows, and the Python bindings work on
Windows. However GTK+ does not have nearly as good integration with the
Windows desktop in terms of look and feel as other solutions like Qt and
wxWidgets.  Running the Linux version of GTK+ inside of Windows' Linux
layer would not solve that problem!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Assignment Versus Equality

[MRAB]

On 2016-06-27 14:59, Grant Edwards wrote:

On 2016-06-26, BartC  wrote:


(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".)


I've always been baffled by that.

Were there other languages that did something similar?


Algol 60 and Algog 68.


Why would a language designer think it a good idea?

It let you have identifiers like "grand total"; there was no need for 
camel case or underscores to separate the parts of the name.



Did the poor sod who wrote the compiler think it was a good idea?



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

Re: Assignment Versus Equality

[Grant Edwards]

On 2016-06-27, MRAB  wrote:
> On 2016-06-27 14:59, Grant Edwards wrote:
>> On 2016-06-26, BartC  wrote:
>>
>>> (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".)
>>
>> I've always been baffled by that.
>>
>> Were there other languages that did something similar?
>
> Algol 60 and Algog 68.

Ah, I never knew that Algol ignored spaces also.  I had a vague
recollection that they keyword namespace and variable namespaces were
speparate, which allowed some rather odd looking (by modern standards)
code.

> It let you have identifiers like "grand total"; there was no need for 
> camel case or underscores to separate the parts of the name.

It's interesting how completely that concept has dissappeared from
modern languages.

-- 
Grant Edwards   grant.b.edwardsYow! Send your questions to
  at   ``ASK ZIPPY'', Box 40474,
  gmail.comSan Francisco, CA 94140,
   USA

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

Re: Assignment Versus Equality

[Gene Heskett]

On Monday 27 June 2016 09:28:00 Steven D'Aprano wrote:

> On Mon, 27 Jun 2016 10:48 pm, Rustom Mody wrote:
> > PS Google Groups is wise enough to jump through hoops trying to
> > encode my message above as latin-1, then as Windows 1252 and only
> > when that does not work as UTF-8
>
> There is nothing admirable about GG (or any other newsreader or email
> client) defaulting to legacy encodings like Latin-1 and especially not
> Windows 1252.
>
> Certainly the user should be permitted to explicitly set the encoding,
> but otherwise the program should default to UTF-8.
>
Both of you mentioned 2 bad words, now go and warsh yer fungers with some 
of grandma's lye soap. 
>
> --
> Steven
> “Cheer up,” they said, “things could be worse.” So I cheered up, and
> sure enough, things got worse.


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: [Python-Dev] [RELEASED] Python 3.4.5 and Python 3.5.2 are now available

[Steve Dower]

On 26Jun2016 1932, Larry Hastings wrote:

https://www.python.org/downloads/release/python-352/
...
/p.s. There appears to be a small oops with the Windows installers for
3.5.2--uploaded to the wrong directory or something.  They'll be
available soon, honest!


That oops is now fixed, but I wanted to mention one other thing.

Microsoft Security Essentials, now a very common antivirus/antimalware 
scanner on Windows, is incorrectly detecting 
Lib/distutils/command/wininst-14.0.exe as malware (originally reported 
at http://bugs.python.org/issue27383).


My assumption is that someone distributed malware using a bdist_exe 
package, and our stub executable got picked up in the signature. I 
rebuilt the executable on my own machine from early source code and it 
still triggered the scan, so there does not appear to have been any 
change to the behaviour of the executable.


I've already submitted a false positive report, so I expect an update to 
correct it at some point in the future, but please do not be alarmed to 
see this warning when installing Python 3.5.2, or when scanning any 
earlier version of 3.5.


Feel free to contact me off-list or steve.dower at microsoft.com if you 
have concerns.


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

Live installation of Pandas for Windows 64

[David Shi via Python-list]

Is there a live installation of Pandas for Windows 64?
Regards.
David
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can math.atan2 return INF?

[Marko Rauhamaa]

Rustom Mody :

> On Monday, June 27, 2016 at 7:42:26 PM UTC+5:30, Marko Rauhamaa wrote:
>> I'm a formalist.
>
> Well then formalism is semantics-free: What matters it if an argument
> is theological or scientific as long as it is (internally) consistent?

That's what I'm saying: black holes can't exist according to the very
theory that predicts their existence.

They might exist in reality, though...


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

Re: argparse and subparsers

[Sachin Garg]

On Monday 27 June 2016 06:28 AM, Steven D'Aprano wrote:
> On Monday 27 June 2016 15:34, Lawrence D’Oliveiro wrote:
> 
>> 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...
> 
> 
> Not particularly, but what are you going to do? You need to support a minimum 
> of three cases:
> 
> - a default setting;
> - the case where the user passes --verbose;
> - the case where the user passes -q;
> 
> (I'm not sure why --verbose take a long argument but no short argument -v; 
> and 
> likewise why there's a -q short argument but no --quiet long version. Oh 
> well.)

It is there. The way docopt works (https://github.com/docopt/docopt) is
that it uses a "usage pattern" formatted using doctring conventions. In
my case (snippet below), this pattern was:

"""Process Files: De-identify, encrypt and transmit data.

Usage:
processFiles.py [-hvq] [--config=FILE] [--encryptkey=key]
[--signkey=key] [--no-normalize] [--no-encrypt] [--no-sign]

Options:
-h --help   show this help message and exit
-v --verboseverbose mode
-q  quiet mode (default)

--config=FILE   read configuration FILE (default: config.json)

--encryptkey=KEYset GPG encryption key to KEY(default: from
config file)
--signkey=KEY   set GPG signing key to KEY (default: from config
file)
--no-normalize  do not normalize CCD/CSV (default: normalize)
--no-encryptdo not encrypt output (default: encrypt)
--no-sign   do not sign output (default: sign)
--no-transfer   do not transfer output (default: transfer)
"""

So, the short "-v" option is taken care  of.

> A simple test-and-set for each argument is the simplest, most 
> straight-forward 
> way of handling this. It's not *pretty* or *elegant* code, but it is the 
> easiest to read, write and comprehend, and in my opinion much better than 
> alternatives involving ever more arcane method calls to ever more complicated 
> classes.

The code above does seem amateurish. However, I think that it is easier
to "waste" a few variables and allow for the ability to do printf()
debugging, then write code using esoteric data structures.

> I don't have experience with docutils and cannot judge whether or not 
> Sachin's 
> snippets are good or bad examples of use, but find myself going back to the 
> good old fashioned GNU style command line parser whenever I need a few 
> command 
> line options. If you find yourself writing subparsers and "mandatory options" 
> and needing entire help screens to describe single arguments (as in "foo 
> --help 
> arg") then really I think you should give up the pretence that you're dealing 
> with command line options, and you should write a mini-language for your 
> application.
> 
> (hg, git, memcoder, soc etc. I'm talking about you.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Getting back into PyQt and not loving it.

[llanitedave]

On Sunday, June 26, 2016 at 11:16:01 PM UTC-7, John Ladasky wrote:
> 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.

I produced a couple of applications using wxPython 2.8 and Python 2.7, and I 
was happy with how they turned out, but since I moved to Python 3 I got tired 
of waiting for a Phoenix release that I felt comfortable with, so I've been 
learning PyQT lately. I do find that PyQt is more straightforward in many 
respects than wxPython, but the difference for me has always been how well 
organized and understandable the documentation is.  The PyQt examples seem very 
comprehensive, but the code is poorly commented and there are some quirks that 
are confusing me.   The original wxPython book was quite well put together and 
extremely helpful, and I miss having something like that for Qt.  I'm going 
through the eBook on PyQt4, but I'm not yet sure how well it will translate to 
PyQt5, which I'm trying to develop with.  I do think I'll stick with it, 
though.  Once I learn it I think it will serve me well.
-- 
https://mail.python.org/mailman/listinfo/python-list

Where do i find the 32 bit libraries on my 64 bit ubuntu system

[Steven Truppe]

Hi all,

i want to write an application that works for both 32 bit and 64bit on 
my 64bit ubuntu system, my problem i only find 64bit libraries under 
/usr/lib, there is also a path callled /x86_64-linux-gnu/ <- are these 
the libraries i should use for 32 bit and 64 bit programming ??

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

Re: Where do i find the 32 bit libraries on my 64 bit ubuntu system

[Rustom Mody]

On Monday, June 27, 2016 at 11:07:29 PM UTC+5:30, Steven Truppe wrote:
> Hi all,
> 
> i want to write an application that works for both 32 bit and 64bit on 
> my 64bit ubuntu system, my problem i only find 64bit libraries under 
> /usr/lib, there is also a path callled /x86_64-linux-gnu/ <- are these 
> the libraries i should use for 32 bit and 64 bit programming ??

You probably need to study about multiarch:
https://help.ubuntu.com/community/MultiArch
https://wiki.debian.org/Multiarch/

[Dont know much more myself]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Where do i find the 32 bit libraries on my 64 bit ubuntu system

[Grant Edwards]

On 2016-06-27, Steven Truppe  wrote:

> i want to write an application that works for both 32 bit and 64bit on 
> my 64bit ubuntu system, my problem i only find 64bit libraries under 
> /usr/lib, there is also a path callled /x86_64-linux-gnu/ <- are these 
> the libraries i should use for 32 bit and 64 bit programming ??

In my experience all you have to do is pass "-m32" to gcc.  It should
know where the 32-bit libraries are.

-- 
Grant Edwards   grant.b.edwardsYow! UH-OH!!  I put on
  at   "GREAT HEAD-ON TRAIN
  gmail.comCOLLISIONS of the 50's"
   by mistake!!!

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

Re: Getting back into PyQt and not loving it.

[codewizard]

On Sunday, June 26, 2016 at 5:45:18 PM UTC-4, Michael Torrie wrote:
> 
> 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.

Enaml feels pretty Pythonic to me:

https://github.com/nucleic/enaml
-- 
https://mail.python.org/mailman/listinfo/python-list

__all__ attribute: bug and proposal

[Pavel S]

Hi,
I today uncovered subtle bug and would like to share it with you.

By a mistake, I forgot to put comma into '__all__' tuple of some module. Notice 
missing comma after 'B'.

# module foo.py
__all__ = (
'A',
'B'
'C',
)

class A: pass
class B: pass
class C: pass

If you try to import * from the module, it will raise an error, because 'B' and 
'C' will be concatenated into 'BC'.

>>> from foo import *
AttributeError: 'module' object has no attribute 'BC'

The bug won't be found until someone imports *.
In order to identify problems as soon as possible, here's the proposal.

Porposal: allow putting objects into __all__ directly, so possible problems 
will be found earlier:

# module foo.py
class A: pass
class B: pass
class C: pass

__all__ = (A, B, C)

Note: this currently don't work.

>>> from foo import *
TypeError: attribute name must be string, not 'type'
-- 
https://mail.python.org/mailman/listinfo/python-list

Transcrypt - Games for Kids

[Salvatore DI DIO]

Hello,

I am using Transcrypt  (Python to Javascript translator) to create
games for kids, and introduce them to  programming.
You can give an eye here :

https://github.com/artyprog/GFK

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

Re: __all__ attribute: bug and proposal

[Chris Angelico]

On Tue, Jun 28, 2016 at 6:56 AM, Pavel S  wrote:
> Porposal: allow putting objects into __all__ directly, so possible problems 
> will be found earlier:
>
> # module foo.py
> class A: pass
> class B: pass
> class C: pass
>
> __all__ = (A, B, C)
>
> Note: this currently don't work.
>
 from foo import *
> TypeError: attribute name must be string, not 'type'

How would it know what names to import them under? It's all very well
with classes and functions (you could mandate that it uses the
canonical name), but what about integers or strings?

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

Re: Assignment Versus Equality

[Lawrence D’Oliveiro]

On Tuesday, June 28, 2016 at 3:27:40 AM UTC+12, MRAB wrote:
>
> On 2016-06-27 14:59, Grant Edwards wrote:
>>
>> Were there other languages that did something similar?
>>
> Algol 60 and Algog 68.

Algol 68 was actually slightly different. There were two separate alphabets: 
one used for names of constants, variables, routines and labels, where spaces 
were ignored, and a different one used for type names (called “modes”) and 
reserved words, where spaces were significant.

The convention was to use lowercase for the former and uppercase for the latter.

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

Re: __all__ attribute: bug and proposal

[Pavel S]

> but what about integers or strings?

Can you provide example?

---
No matter if __all__ uses names or objects, I think it should be validated not 
only when importing '*', but always.

Frankly, do you always unit-test if __all__ works?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: __all__ attribute: bug and proposal

[Chris Angelico]

On Tue, Jun 28, 2016 at 8:29 AM, Pavel S  wrote:
>> but what about integers or strings?
>
> Can you provide example?

Sure. I'll spare you the wall of text that is os.__all__, but here's the types:

>>> import os
>>> {type(getattr(os, x)).__name__ for x in os.__all__}
{'bool', 'module', 'function', 'str', '_Environ', 'NoneType', 'type',
'int', 'dict', 'builtin_function_or_method'}
>>> collections.Counter(hasattr(getattr(os, x), "__name__") for x in os.__all__)
Counter({True: 184, False: 122})

So, roughly 60% of them even have canonical names. And you don't
always want the canonical name, anyway:

>>> os.path.__name__
'posixpath'

(Your results may vary. Specifically. os.path.__name__ will be
'ntpath' if you're on Windows.)

> No matter if __all__ uses names or objects, I think it should be validated 
> not only when importing '*', but always.
>
> Frankly, do you always unit-test if __all__ works?

Frankly, I don't unit test enough. But if you have __all__, it
shouldn't be too hard, nor too unobvious, to test it.

>>> def test_all():
...   exec("from os import *")
...
>>> test_all()
>>> os.__all__.append("asdf")
>>> test_all()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in test_all
  File "", line 1, in 
AttributeError: module 'os' has no attribute 'asdf'

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

Re: Assignment Versus Equality

[Lawrence D’Oliveiro]

On Tuesday, June 28, 2016 at 3:27:40 AM UTC+12, MRAB wrote:
> On 2016-06-27 14:59, Grant Edwards wrote:
>> Why would a language designer think it a good idea?
>>
> It let you have identifiers like "grand total"; there was no need for 
> camel case or underscores to separate the parts of the name.

Another nifty thing (well, I thought so at the time) was that FORTRAN had no 
reserved words.

Though I wondered, in statements like

FORMAT(...complex expression with lots of nested parentheses...) = ...

how much work the parser would have to do before deciding that it was an array 
assignment, not a FORMAT statement?

Then some FORTRAN dialects allowed constant definitions using syntax like

PARAMETER N = 3

which broke the no-reserved-words convention. Luckily, this was standardized as 
the much less headache-inducing (for the compiler writer)

PARAMETER(N = 3)

PL/I (which was almost named “FORTRAN VI” at one stage) added significant 
whitespace, but managed to keep the no-reserved-words convention--almost. There 
was just one peculiar set of exceptions...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator Precedence: One Thing Python Got Right

[Lawrence D’Oliveiro]

On Tuesday, June 28, 2016 at 2:32:48 AM UTC+12, Grant Edwards wrote:
>
> On 2016-06-27, BartC wrote:
>
>> I bet your code isn't very 'Pythonic' then!
> 
> No, not when the end goal is to move it into C.

I wonder: how much real-world C code would be broken if the operator 
precedences in C were changed to match that in Python?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Getting back into PyQt and not loving it.

[Ethan Furman]

On 06/26/2016 07:12 PM, MRAB wrote:


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?


I would say it's the wrapper.

I appreciate all the work being done on tkinter lately, but it's still 
jarring trying to use the not-very-pythonic-at-all interface.


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

Re: Assignment Versus Equality

[BartC]

On 27/06/2016 23:45, Lawrence D’Oliveiro wrote:

On Tuesday, June 28, 2016 at 3:27:40 AM UTC+12, MRAB wrote:

On 2016-06-27 14:59, Grant Edwards wrote:

Why would a language designer think it a good idea?


It let you have identifiers like "grand total"; there was no need for
camel case or underscores to separate the parts of the name.


Another nifty thing (well, I thought so at the time) was that FORTRAN had no 
reserved words.

Though I wondered, in statements like

FORMAT(...complex expression with lots of nested parentheses...) = ...

how much work the parser would have to do before deciding that it was an array 
assignment, not a FORMAT statement?


You just design the compiler to do the same processing in each case, ie. 
parse a  followed (), then mark the result AST 
fragment as either an Array term, or Format statement, depending on what 
follows, and whether the name is "format".


I suppose the compiler could decide to backtrack and re-parse based on 
the knowledge that is one or the other, but that's a messy way of doing it.


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

Re: __all__ attribute: bug and proposal

[Random832]

On Mon, Jun 27, 2016, at 16:56, Pavel S wrote:
> Porposal: allow putting objects into __all__ directly, so possible
> problems will be found earlier:

Question: What happens if the object in __all__ isn't the same object
that's in the module?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Getting back into PyQt and not loving it.

[Michael Torrie]

On 06/27/2016 02:14 PM, codewiz...@gmail.com wrote:
> On Sunday, June 26, 2016 at 5:45:18 PM UTC-4, Michael Torrie wrote:
>>
>> 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.
> 
> Enaml feels pretty Pythonic to me:
> 
> https://github.com/nucleic/enaml

Cool. I'll check it out.

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

Re: __all__ attribute: bug and proposal

[Chris Angelico]

On Tue, Jun 28, 2016 at 6:56 AM, Pavel S  wrote:
> By a mistake, I forgot to put comma into '__all__' tuple of some module. 
> Notice missing comma after 'B'.
>
> # module foo.py
> __all__ = (
> 'A',
> 'B'
> 'C',
> )
>
> class A: pass
> class B: pass
> class C: pass
>
> If you try to import * from the module, it will raise an error, because 'B' 
> and 'C' will be concatenated into 'BC'.
>
 from foo import *
> AttributeError: 'module' object has no attribute 'BC'
>
> The bug won't be found until someone imports *.

If you're primarily worried about classes and functions, here's a neat
trick you can use:

__all__ = []
def all(thing):
__all__.append(thing.__name__)
return thing

@all
class A: pass
@all
class B: pass
@all
class C: pass
@all
def d(): pass

del all # clean up the namespace (optional)


The decorator doesn't change anything (it returns its argument as-is),
but it captures the canonical name into __all__. Obviously you can't
use this if you want a non-canonical name, and you can't use it for
anything other than classes and functions (you can't decorate "pi =
3.14159"), but it might help with your actual problem.

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

Re: Assignment Versus Equality

[sohcahtoa82]

On Monday, June 27, 2016 at 7:09:35 AM UTC-7, Marko Rauhamaa wrote:
> Grant Edwards :
> 
> > On 2016-06-26, BartC  wrote:
> >
> >> (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".)
> >
> > I've always been baffled by that.
> >
> > Were there other languages that did something similar?
> 
> In XML, whitespace between tags is significant unless the document type
> says otherwise. On the other hand, leading and trailing space in
> attribute values is insignificant unless the document type says
> otherwise.
> 
> > Why would a language designer think it a good idea?
> >
> > Did the poor sod who wrote the compiler think it was a good idea?
> 
> Fortran is probably not too hard to parse. XML, on the other hand, is
> impossible to parse without the document type at hand. The document type
> not only defines the whitespace semantics but also the availability and
> meaning of the "entities" (e.g., © for ©). Add namespaces to that,
> and the mess is complete.
> 
> 
> Marko

XML isn't a programming language.  I don't think it's relevant to the 
conversation.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Assignment Versus Equality

[Steven D'Aprano]

On Tue, 28 Jun 2016 12:23 am, Rustom Mody wrote:

> On Monday, June 27, 2016 at 6:58:26 PM UTC+5:30, Steven D'Aprano wrote:
>> On Mon, 27 Jun 2016 10:48 pm, Rustom Mody wrote:
>> 
>> > PS Google Groups is wise enough to jump through hoops trying to encode
>> > my message above as latin-1, then as Windows 1252 and only when that
>> > does not work as UTF-8
>> 
>> 
>> There is nothing admirable about GG (or any other newsreader or email
>> client) defaulting to legacy encodings like Latin-1 and especially not
>> Windows 1252.
>> 
>> Certainly the user should be permitted to explicitly set the encoding,
>> but otherwise the program should default to UTF-8.
> 
> Its called sarcasm...


Ah, sorry about that, I didn't realise.

Some human languages have native support for flagging sarcasm, e.g. there's
a sarcasm marker called temherte slaqî used by some Ethiopic languages to
indicate sarcasm and other unreal statements. It apparently looks somewhat
like an upside down exclamation mark (¡).

Another common solution is to use "scare quotes" around the sarcastic key
words. Or you could tag the sentence with   tags. Most
people I see using this last one just show the close tag, often
abbreviating it to just /s on its own.


> Also how is GG deliberately downgrading clear unicode content to be kind
> to obsolete clients at recipient end different from python 2 → 3 making
> breaking changes but not going beyond ASCII lexemes?

Oh yes, I completely agree, obviously GvR is literally worse than Hitler
because he hasn't added a bunch of Unicode characters with poor support for
input and worse support for output as essential syntactic elements to
Python.

/s




-- 
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

[Lawrence D’Oliveiro]

On Tuesday, June 28, 2016 at 2:23:16 AM UTC+12, Rustom Mody wrote:
> python 2 → 3 making breaking changes but not going beyond ASCII lexemes?

You do know Python 3 allows Unicode letters in identifiers, right?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Where do i find the 32 bit libraries on my 64 bit ubuntu system

[Lawrence D’Oliveiro]

On Tuesday, June 28, 2016 at 5:37:29 AM UTC+12, Steven Truppe wrote:
> i want to write an application that works for both 32 bit and 64bit on 
> my 64bit ubuntu system, my problem i only find 64bit libraries under 
> /usr/lib, there is also a path callled /x86_64-linux-gnu/ <- are these 
> the libraries i should use for 32 bit and 64 bit programming ??

You can install 32-bit compatibility libraries on x86-64. Find the libraries 
with

apt-cache search 32 | grep '^lib.*32.*bit'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Assignment Versus Equality

[Steven D'Aprano]

On Tue, 28 Jun 2016 01:27 am, MRAB wrote:

> On 2016-06-27 14:59, Grant Edwards wrote:
>> On 2016-06-26, BartC  wrote:
>>
>>> (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".)
>>
>> I've always been baffled by that.
>>
>> Were there other languages that did something similar?
>>
> Algol 60 and Algog 68.

Are you sure about that? I'd like to see a citation, as everything I've seen
suggests that Algol treats spaces like modern languages.

http://www.masswerk.at/algol60/algol60-syntaxversions.htm

Space is listed as a separator, and *not* in indentifiers.





-- 
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

[Steven D'Aprano]

On Mon, 27 Jun 2016 11:59 pm, Grant Edwards wrote:

> On 2016-06-26, BartC  wrote:
> 
>> (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".)
> 
> I've always been baffled by that.
> 
> Were there other languages that did something similar?
> 
> Why would a language designer think it a good idea?
> 
> Did the poor sod who wrote the compiler think it was a good idea?

I don't know if it was a deliberate design decision or not, but I don't
believe that it survived very many releases of the Fortran standard.

Remember that Fortran was THE first high-level language. Its creator, John
Backus, was breaking new ground and doing things that had never been done
before[1], so the things that we take for granted about high-level
programming languages were still being invented. If early Fortran got a few
things wrong, we shouldn't be surprised.

Also the earliest Fortran code was not expected to be typed into a computer.
It was expected to be entered via punched cards, which eliminates the need
for spaces.



[1] Almost. He has previously created a high-level assembly language,
Speedcoding, for IBM, which can be considered the predecessor of Fortran.

-- 
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: __all__ attribute: bug and proposal

[MRAB]

On 2016-06-28 01:32, Chris Angelico wrote:
[snip]


If you're primarily worried about classes and functions, here's a neat
trick you can use:

__all__ = []
def all(thing):
__all__.append(thing.__name__)
return thing


Err... won't that hide the 'all' builtin?

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

Re: __all__ attribute: bug and proposal

[Steven D'Aprano]

On Tue, 28 Jun 2016 06:56 am, Pavel S wrote:

> Hi,
> I today uncovered subtle bug and would like to share it with you.
> 
> By a mistake, I forgot to put comma into '__all__' tuple of some module.
> Notice missing comma after 'B'.
> 
> # module foo.py
> __all__ = (
> 'A',
> 'B'
> 'C',
> )

Right. That's a language feature: implicit concatenation of string literals.
If you have two string literals separated by nothing but whitespace, the
compiler will concatenate them:

s = 'He said, "Hello, did you see where' " they're" ' going?"'

is equivalent to:

s = 'He said, "Hello, did you see where they\'re going?"'


> If you try to import * from the module, it will raise an error, because
> 'B' and 'C' will be concatenated into 'BC'.

Correct. Exactly the same as if you had written:

__all__ = ['A', 'BC', 'D']


> The bug won't be found until someone imports *.

I always write a unit-test to check that everything in __all__ exists.


> In order to identify problems as soon as possible, here's the proposal.
> 
> Porposal: allow putting objects into __all__ directly, so possible
> problems will be found earlier:
> 
> # module foo.py
> class A: pass
> class B: pass
> class C: pass
> 
> __all__ = (A, B, C)

There are two problems with this idea.

Suppose you have this:


prefs_file = "filename"
__all__ = (prefs_file, A, B, C)  # suppose A, B and C are all defined


Obviously, the intention is that the caller can say:

from themodule import *
print(prefs_file)

and "filename" will be printed. But there's two problems:

(1) the __all__ tuple doesn't know anything about the name "prefs_file". It
only knows about "filename", the object (value) of prefs_file. So there is
no way for the import system to know what name to use for that value:

? = "filename"


(2) For backwards-compatibility, we still need to support the old way of
writing __all__, using names given as strings:

__all__ = ('prefs_file', 'A', 'B', 'C')

But now you have an ambiguity. If __all__ looks like this:

__all__ = (prefs_file, A, B, C)

does the first entry mean "import the value 'filename'" (new behaviour), or
does it mean "import the value with the name 'filename'" (old behaviour)?




-- 
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: __all__ attribute: bug and proposal

[Chris Angelico]

On Tue, Jun 28, 2016 at 11:55 AM, MRAB  wrote:
> On 2016-06-28 01:32, Chris Angelico wrote:
> [snip]
>
>> If you're primarily worried about classes and functions, here's a neat
>> trick you can use:
>>
>> __all__ = []
>> def all(thing):
>> __all__.append(thing.__name__)
>> return thing
>>
> Err... won't that hide the 'all' builtin?
>

Yep. So? If you're not using it *at top level*, it's not a problem. I
clean up the namespace at the end, so if you use it inside a function,
it'll still be available. And most of my scripts don't use 'all'
anyway... it's no worse than using 'id' for a database ID.

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

RE: argparse and subparsers

[Joseph L. Casale]

> 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.

Yea I have had my eye on docopt for a while, it doesn't support multiple
subparsers, as I am passing duplicate parameters from its perspective.

Imagine:

foo.py --host 172.18.0.4 --port 766 foo --warning 42 --critical 77 bar 
--warning 4.2 --critical 7.7

etc...

The shortcoming to argparse has been debated to death and the bug tracker
was just left hanging. To be honest, I am not clear on the opposition to it...

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

Re: __all__ attribute: bug and proposal

[Random832]

On Mon, Jun 27, 2016, at 20:32, Chris Angelico wrote:
> If you're primarily worried about classes and functions, here's a neat
> trick you can use:

How about just

__all__ = [list of stuff including classes and functions]
__all__ = [x if isinstance(x, str) else x.__name__ for x in __all__]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question on compiling on linux

[Steven D'Aprano]

On Tue, 28 Jun 2016 10:01 am, Dennis Lee Bieber wrote:

> The Outlook style works well in a business environment where the
> recipient is likely the original sender of the quoted text, and doesn't
> need the context -- the quoted copy is just a courtesy copy in this case.


No it doesn't work well. It is shit in business environments too. It only
works well in one tiny subset of cases:

(1) Fred sends an email to George.

(2) George responds with a short response that stands alone, or can be
interpreted based only on the subject line.



~ Subject: Drinks on Friday
~ From: Fred
~
~ Hey all, we're going to the Fox and Wheelbarrow for drinks on 
~ Friday at 6pm. Join us!


~ Subject: Re: Drinks on Friday
~ From George
~
~ See you there!
~ 
~ === Message from Fred ===
~ > Hey all, we're going to the Fox and Wheelbarrow for drinks on 
~ > Friday at 6pm. Join us! 


That's about the level of conversation where top posting works well.

But as soon as you get into actual meaningful dialog which requires more
than a one or two sentence reply, ESPECIALLY if you ask more than one
question, top posting is *shit*.


~ Subject: Project X
~ From: Fred
~
~ Hey George, we have a few issues to go over regarding Project X. 
~ For starters, if we are to have any hope of meeting the deadline,
~ the team is going to need to put in some overtime. Do you think
~ Jane will authorise overtime payments, or should we get time off
~ in lieu?
~ Also, there's a problem with Alex, the web designer. You know 
~ that he's a subcontractor, right? Well apparently Accounts hasn't
~ been paying his invoices, and he's threatening to put us on stop
~ and go legal. What should we do?


~ Subject: Re: Project X
~ From: George
~
~ Yeah, sure, I agree.
~
~ === Message from Fred ===
~ > Hey George, we have a few issues to go over regarding Project X. 
~ > For starters, if we are to have any hope of meeting the deadline,
~ > the team is going to need to put in some overtime. Do you think
~ > Jane will authorise overtime payments, or should we get time off
~ > in lieu?
~ > Also, there's a problem with Alex, the web designer. You know 
~ > that he's a subcontractor, right? Well apparently Accounts hasn't
~ > been paying his invoices, and he's threatening to put us on stop
~ > and go legal. What should we do?


Even if George isn't an absolute pillock and actually intends to give a
useful answer, he has to work harder by explicitly referencing the
questions being replied to:


~ Subject: Re: Project X
~ From: George
~
~ Regarding the overtime question, I'll discuss it with Bob and get 
~ him to talk to Jane. He's the project manager, let him earn his
~ salary.
~ Regarding Alex, he's a tit and I'm pretty sure he's overcharging
~ us, so this will be a good opportunity to get rid of him. Tell him
~ there's nothing you can do. Once he puts us on stop, we can steal
~ an in-house web developer from Sarah's team. I still owe her for
~ poaching Manjinder.


It might only be an extra few words each time there's a change of topic, but
it adds up. And because it does require those extra few words, and most
people are lazy, most people don't bother:


~ Subject: Re: Project X
~ From: George
~
~ I'll discuss it with Bob.
~
~ He's a tit and I'm pretty sure he's overcharging us. Tell him 
~ nothing.





-- 
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: __all__ attribute: bug and proposal

[Terry Reedy]

On 6/27/2016 6:29 PM, Pavel S wrote:


Frankly, do you always unit-test if __all__ works?


One should.  CPython's test suite includes test___all__.  I believe it 
imports every stdlib module, looks for __all__, and if present, tests 
that it works.  It probably executes 'from module import *'.  A side 
effect is testing that everything imports.  I am pretty sure that 
test___all__ has caught bugs.


--
Terry Jan Reedy

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

Re: Question on compiling on linux

[Steven D'Aprano]

Oh, and while I'm ranting about top-posting, there's another reason why it's
shit. Speaking from experience, it makes searching email archives awful.

I've been in the position of having to go through email archives looking for
relevant email discussions related to a legal dispute. Trying to search for
key words is far less effective with top-posting and no trimming, as the
volume of text you need to deal with increases as (roughly) the square of
the number of emails:

A emails B:
~ Hey!

B replies:
~ Hey yourself!
~ > Hey!

A responds:
~ Wazzup dude?
~ > Hey yourself!
~ >> Hey!

And B responds:
~ Just chillin. And you?
~ > Wazzup dude?
~ >> Hey yourself!
~ >>> Hey!

And the reply:
~ Working hard man. Or hardly working LOL LOL LOL
~ > Just chillin. And you?
~ >> Wazzup dude?
~ >>> Hey yourself!
~  Hey!

One last response from B:
~ OK catch u later.
~ > Working hard man. Or hardly working LOL LOL LOL
~ >> Just chillin. And you?
~ >>> Wazzup dude?
~  Hey yourself!
~ > Hey!

Total lines: 1 + 2 + 3 + 4 + 5 + 6 = 21

which is given by n*(n-1)/2 or O(n**2).


Now imagine that each email contains at least one paragraph of text, plus
(oh joy) an email disclaimer, plus (say) a ten line signature, *all* of
which is typically commented because gods forbid that people use a
signature marker "-- "[1] or that email clients trim anything below it when
present.

Me, bitter? Whatever gave you that impression?




[1] Yes the trailing space is significant.

-- 
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: __all__ attribute: bug and proposal

[Steven D'Aprano]

On Tue, 28 Jun 2016 12:46 pm, Terry Reedy wrote:

> On 6/27/2016 6:29 PM, Pavel S wrote:
> 
>> Frankly, do you always unit-test if __all__ works?
> 
> One should.  CPython's test suite includes test___all__.  I believe it
> imports every stdlib module, looks for __all__, and if present, tests
> that it works.  It probably executes 'from module import *'.  A side
> effect is testing that everything imports.  I am pretty sure that
> test___all__ has caught bugs.

I write my own unit tests for __all__, which has certainly caught bugs.



-- 
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

[Michael Torrie]

On 06/27/2016 08:28 PM, Steven D'Aprano wrote:
> On Tue, 28 Jun 2016 10:01 am, Dennis Lee Bieber wrote:
> 
>> The Outlook style works well in a business environment where the
>> recipient is likely the original sender of the quoted text, and doesn't
>> need the context -- the quoted copy is just a courtesy copy in this case.
> 
> 
> No it doesn't work well. It is shit in business environments too. It only
> works well in one tiny subset of cases:

Indeed. Sometimes it took three emails to get the other person to
actually read what I wrote and answer my questions.  I would email with
a few details and question, and he'd immediately top-post back to me
with a one-sentence answer that had very little to do with my question
and very apparent that he never read anything I wrote.  If he had
middle-posted, while he was trimming my reply he would have read or
re-read what I wrote and responded appropriately.

It's just unbelievable how horrid email communication is in a business
environment when top-posting is prevalent.  I tried on occasion to urge
people to not top-post for these reasons, but by and large people just
thumbed up their nose and went on not reading emails and top-posting.  I
guess it's a special management talent.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Assignment Versus Equality

[Marko Rauhamaa]

sohcahto...@gmail.com:

> On Monday, June 27, 2016 at 7:09:35 AM UTC-7, Marko Rauhamaa wrote:
>> Grant Edwards :
>> > Were there other languages that did something similar?
>> 
>> In XML, whitespace between tags is significant unless the document type
>> says otherwise. On the other hand, leading and trailing space in
>> attribute values is insignificant unless the document type says
>> otherwise.
>> 
>> > Why would a language designer think it a good idea?
>> >
>> > Did the poor sod who wrote the compiler think it was a good idea?
>> 
>> Fortran is probably not too hard to parse. XML, on the other hand, is
>> impossible to parse without the document type at hand. The document type
>> not only defines the whitespace semantics but also the availability and
>> meaning of the "entities" (e.g., © for ©). Add namespaces to that,
>> and the mess is complete.
>
> XML isn't a programming language. I don't think it's relevant to the
> conversation.

The question was about (formal) languages, not only programming
languages.

However, there are programming languages with XML syntax:

   https://en.wikipedia.org/wiki/XSLT>
   http://www.o-xml.org/spec/langspec.html>
   http://xplusplus.sourceforge.net/>


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

Re: __all__ attribute: bug and proposal

[Zachary Ware]

On Mon, Jun 27, 2016 at 7:32 PM, Chris Angelico  wrote:
> If you're primarily worried about classes and functions, here's a neat
> trick you can use:
>
> __all__ = []
> def all(thing):
> __all__.append(thing.__name__)
> return thing

Barry Warsaw has written a nice decorator called 'public' that can be
installed from PyPI as 'atpublic'[0].  It was proposed for inclusion
as a builtin in 3.6 [1], but a less-than-enthusiastic response at the
2016 Language Summit has put that off indefinitely.  I, for one, would
like to see it happen anyway [2], and public support may make it
possible.

The '@public' decorator works like so:

"""
# spam.py

@public
def spam():
return ' '.join(['spam']*10)

@public
def eggs():
return 'bacon'

public(HAM=4)
assert HAM == 4

assert sorted(__all__) == sorted(['spam', 'eggs', 'HAM'])
"""

This strikes me as being a cleaner approach than what the OP
suggested, easier to use than Chris' simple decorator, and a nice way
to bring an end to outdated __all__ lists (which is a problem
currently plaguing the standard library, and probably many other
libraries).

[0] https://pypi.python.org/pypi/atpublic
[1] https://bugs.python.org/issue26632
[2] https://bugs.python.org/issue26632#msg267305

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

Re: Assignment Versus Equality

[Rustom Mody]

On Tuesday, June 28, 2016 at 6:36:06 AM UTC+5:30, Steven D'Aprano wrote:
> On Tue, 28 Jun 2016 12:23 am, Rustom Mody wrote:
> > Also how is GG deliberately downgrading clear unicode content to be kind
> > to obsolete clients at recipient end different from python 2 → 3 making
> > breaking changes but not going beyond ASCII lexemes?
> 
> Oh yes, I completely agree, obviously GvR is literally worse than Hitler
> because he hasn't added a bunch of Unicode characters with poor support for
> input and worse support for output as essential syntactic elements to
> Python.
> 
> /s

Gratuitous Godwin acceleration produceth poor sarcasm -- try again
And while you are at it try and answer the parallel:
Unicode has a major pro and con
Pro: Its a superset and enormously richer than ASCII
Con: It is costly and implementations are spotty

GG downgrades posts containing unicode if it can, thereby increasing reach to
recipients with unicode-broken clients

Likewise this:

> a bunch of Unicode characters with poor support for
> input and worse support for output as essential syntactic elements to
> Python.

sounds like the same logic applied to python

JFTR I am not quarrelling with Guido's choices; just pointing out your 
inconsistencies
-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASE] Python 2.7.12

[Benjamin Peterson]

It is my privilege to present you with another release in the Python 2.7
series, Python 2.7.12.

Since the release candidate, there were two changes:
- The Windows binaries have been changed to use OpenSSL 1.0.2h. 
- The "about" dialog in IDLE was fixed.

Downloads, as always, are on python.org:
https://www.python.org/downloads/release/python-2712/

The complete 2.7.12 changelog is available at
https://hg.python.org/cpython/raw-file/v2.7.12/Misc/NEWS

Yet another Python 2.7.x release is anticipated near the end of the
year. Numerologists may wish to upgrade to Python 3 before we hit the
unlucky 2.7.13.

Servus,
Benjamin
2.7 release manager
-- 
https://mail.python.org/mailman/listinfo/python-list

Meta decorator with parameters, defined in explicit functions

[Ben Finney]

Howdy all,

I want an explicit replacement for a common decorator idiom.

There is a clever one-line decorator that has been copy-pasted without
explanation in many code bases for many years::

decorator_with_args = lambda decorator: lambda *args, **kwargs: lambda 
func: decorator(func, *args, **kwargs)

My problem with this is precisely that it is clever: it explains nothing
about what it does, has many moving parts that are not named, it is
non-obvious and lacks expressiveness.

Even the widely-cited ActiveState recipe by Peter Hunt from 2005
http://code.activestate.com/recipes/465427-simple-decorator-with-arguments/>
gives no clue as to what this is doing internally nor what the names of
its parts should be.

I would like to see a more Pythonic, more explicit and expressive
replacement with its component parts easily understood.

-- 
 \ “[H]ow deep can a truth be — indeed, how true can it be — if it |
  `\ is not built from facts?” —Kathryn Schulz, 2015-10-19 |
_o__)  |
Ben Finney

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

Re: Assignment Versus Equality

[Rustom Mody]

On Monday, June 27, 2016 at 8:19:05 PM UTC+5:30, Alain Ketterlin wrote:
> Grant Edwards writes:
> > Did the poor sod who wrote the compiler think it was a good idea?
> 
> I don't know, but he has a good excuse: he was one of the first to ever
> write a compiler (see https://en.wikipedia.org/wiki/Compiler, the
> section on History).
> 
> You just called John Backus a "poor sod". Think again.

The irony is bigger than you are conveying
1957: Backus made Fortran
20 years later: [1977] He won the Turing award, citation explicitly mentioning
his creation of Fortran.
His Turing award lecture 
makes a demand for an alternative functional language (first usage of FP that 
I know) and lambasts traditional imperative programming language.
http://worrydream.com/refs/Backus-CanProgrammingBeLiberated.pdf

However in addition to lambasting current languages in general he owns up to 
his own contribution to the imperative-programming-goofup:

| I refer to conventional languages as "von Neumann languages" to take note of 
| their origin and style, I do not, of course, blame the great mathematician for
| their complexity. In fact, some might say that I bear some responsibility for 
| that problem.

I conjecture that it was Backus' clarion call to think more broadly about
paradigms and not merely about syntax details that prompted the next Turing
talk: Floyd's title (1978) *is* Paradigms of Programming though he did not use 
the word quite as we do today

Likewise Backus' call to dump the imperative 'word-at-a-time' model and look
to APL to inspiration probably made it possible for an outlier like Iverson to
win the Turing award in 79

All these taken together have inched CS slowly away from the imperative 
paradigm:
This and other titbits of history: 
http://blog.languager.org/2015/04/cs-history-1.html

In short for someone in 2016 to laugh at Backus for 1957 mistakes that he had
already realized and crossed over in 1977, and yet continue to use the 
imperative paradigm ie the 57-mistake... well the joke is in the opposite 
direction
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Meta decorator with parameters, defined in explicit functions

[Zachary Ware]

On Tue, Jun 28, 2016 at 12:02 AM, Ben Finney  wrote:
> Howdy all,
>
> I want an explicit replacement for a common decorator idiom.
>
> There is a clever one-line decorator that has been copy-pasted without
> explanation in many code bases for many years::
>
> decorator_with_args = lambda decorator: lambda *args, **kwargs: lambda 
> func: decorator(func, *args, **kwargs)
>
> My problem with this is precisely that it is clever: it explains nothing
> about what it does, has many moving parts that are not named, it is
> non-obvious and lacks expressiveness.
>
> Even the widely-cited ActiveState recipe by Peter Hunt from 2005
> http://code.activestate.com/recipes/465427-simple-decorator-with-arguments/>
> gives no clue as to what this is doing internally nor what the names of
> its parts should be.
>
> I would like to see a more Pythonic, more explicit and expressive
> replacement with its component parts easily understood.

Try this on for size:

'''
import functools

def decorator_with_args(decorator):
"""
Meta-decorator for decorators that take arguments.

Usage:

   @decorator_with_args
   def some_decorator(func, foo, bar=None)
   if foo:
   func.bar = bar
   return func

   @some_decorator(True, bar='quux')
   def some_decorated_function(some_arg)
   return some_arg

   assert some_decorated_function.bar == 'quux'

Returns a function that takes arguments which are to be
passed to the decorator along with the function to be
decorated.

This allows you to just write your decorator as taking
the arguments you want, without having to write a decorator
factory that creates and returns a decorator.
"""

@functools.wraps(decorator)
def factory(*args, **kwargs):
"""Generic decorator factory.

Returns a decorator that calls the original decorator
with the function to be decorated and all arguments
passed to this factory.
"""

def decorator_wrapper(func):
"""Thin wrapper around the real decorator."""
return decorator(func, *args, **kwargs)
return decorator_wrapper
return factory
'''

I make no guarantees about this; this is completely untested and is
based solely upon how the original translated in my mind.  If I
misunderstood how the original works, this is worse than useless :).
Also, I'm not sure how close I got on the "easily understood" part.
It's certainly more explanatory than the original, but it's not the
simplest of concepts anyway: a function that takes a function and
returns a function that takes arbitrary arguments and returns a
function that takes a function and returns the result of calling the
originally passed function with arguments consisting of the passed
function and the aforementioned arbitrary arguments has too many
layers of indirection to keep in mind at once!

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

Re: Assignment Versus Equality

[Steven D'Aprano]

On Tuesday 28 June 2016 14:31, Rustom Mody wrote:

> On Tuesday, June 28, 2016 at 6:36:06 AM UTC+5:30, Steven D'Aprano wrote:
>> On Tue, 28 Jun 2016 12:23 am, Rustom Mody wrote:
>> > Also how is GG deliberately downgrading clear unicode content to be kind
>> > to obsolete clients at recipient end different from python 2 → 3 making
>> > breaking changes but not going beyond ASCII lexemes?
>> 
>> Oh yes, I completely agree, obviously GvR is literally worse than Hitler
>> because he hasn't added a bunch of Unicode characters with poor support for
>> input and worse support for output as essential syntactic elements to
>> Python.
>> 
>> /s
> 
> Gratuitous Godwin acceleration produceth poor sarcasm -- try again
> And while you are at it try and answer the parallel:
> Unicode has a major pro and con
> Pro: Its a superset and enormously richer than ASCII

Correct.

> Con: It is costly and implementations are spotty

That's a matter of opinion. What do you mean by "spotty"?

It seems to me that implementations are mostly pretty good, at least as good as 
Python 2 narrow builds. Support for astral characters is not as good, but 
(apart from some Han users, and a few specialist niches) not as import either.

The big problem is poor tooling: fonts still have many missing characters, and 
editors don't make it easy to enter anything not visible on the keyboard.


> GG downgrades posts containing unicode if it can, thereby increasing reach to
> recipients with unicode-broken clients

And how does that encourage clients to support Unicode? It just enables 
developers to tell themselves "It's just a few weirdos and foreigners who use 
Unicode, ASCII [by which they mean Latin 1] is good enough for everyone."

Its 2016, and it is *way* past time that application developers stop pandering 
to legacy encodings by making them the default. If developers saw that 99% of 
emails were UTF-8, they would be less likely to think they could avoid learning 
about Unicode.

 
> Likewise this:
> 
>> a bunch of Unicode characters with poor support for
>> input and worse support for output as essential syntactic elements to
>> Python.
> 
> sounds like the same logic applied to python
> 
> JFTR I am not quarrelling with Guido's choices; just pointing out your
> inconsistencies

Oh, it's inconsistencies plural is it? So I have more than one? :-)

In Python 3, source files are treated as UTF-8 by default. That means, if you 
want to use Unicode characters in your source code (for variable names, 
comments, or in strings) you can, and you don't have to declare a special 
encoding. Just save the file in an editor that defaults to UTF-8, and Python is 
satisfied. If, for some reason, you need some legacy encoding, you can still 
explicitly set it with a coding cookie at the top of the file.

That behaviour is exactly analogous to my position that mail and news clients 
should default to UTF-8. But in neither case would people be *required* to 
include Unicode characters in their text.


-- 
Steve

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

Re: Assignment Versus Equality

[Chris Angelico]

On Tue, Jun 28, 2016 at 3:42 PM, Steven D'Aprano
 wrote:
> And how does that encourage clients to support Unicode? It just enables
> developers to tell themselves "It's just a few weirdos and foreigners who use
> Unicode, ASCII [by which they mean Latin 1] is good enough for everyone."
>

Or Windows-1252, but declared as Latin-1. (Bane of my life.)

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

Re: Meta decorator with parameters, defined in explicit functions

[Paul Rubin]

Ben Finney  writes:
> decorator_with_args = lambda decorator: lambda *args, **kwargs:
> lambda func: decorator(func, *args, **kwargs)
> I would like to see a more Pythonic, more explicit and expressive
> replacement with its component parts easily understood.

How's this:

from functools import partial
def dwa(decorator):
def wrap(*args,**kwargs):
return partial(decorator, *args, **kwargs)
return wrap
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can math.atan2 return INF?

[Gregory Ewing]

Rustom Mody wrote:

I said that for the Haskell list [0..]

[0..] ++ [-1] == [0..]

He said (in effect) yes that -1 would not be detectable but its still there!


The code to generate it is there, but it will never
be executed, so the compiler is entitled to optimise
it away. :-)

He may have a point though. There are avenues of
mathematics where people think about objects such
as "all the natural numbers, followed by -42", and
consider that to be something different from just
"all the natural numbers".

So, a mathematician would probably say they're not
equal. A scientist would say they may or may not be
equal, but the difference is not testable.

An engineer would say "Lessee, 0, 1, 2, 3, 4, 5,
6, 7... yep, they're equal to within measurement
error."

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

Re: Can math.atan2 return INF?

[Gregory Ewing]

Marko Rauhamaa wrote:

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.


Only in some frames of reference.

By your reasoning, Zeno's paradox proves that a runner
can never reach the finish line in a race. But it really
only proves that if you measure time in such a way that
the finishing time is infinitely far in your future, you
will never see him finish.

That's obviously a screwy way to measure time in a
race, but something similar is happening with the black
hole. If you draw coordinate lines in a particular
way (corresponding to the inertial frame of an outside
observer stationary with respect to the hole) then
the time axis bends in such a way that it never
crosses the horizon.

But there's no reason you have to draw the coordinates
that way; there are plenty of others in which the time
axis does cross the horizon.

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

Re: Assignment Versus Equality

[Marko Rauhamaa]

Chris Angelico :

> Or Windows-1252, but declared as Latin-1. (Bane of my life.)

J


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

Re: Assignment Versus Equality

[Gregory Ewing]

BartC wrote:

You mean the rationale was based on saving keystrokes?


Maybe disk space as well -- bytes were expensive
in those days!

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

Re: Assignment Versus Equality

[Rustom Mody]

On Tuesday, June 28, 2016 at 11:12:59 AM UTC+5:30, Steven D'Aprano wrote:
> On Tuesday 28 June 2016 14:31, Rustom Mody wrote:
> 
> > On Tuesday, June 28, 2016 at 6:36:06 AM UTC+5:30, Steven D'Aprano wrote:
> >> On Tue, 28 Jun 2016 12:23 am, Rustom Mody wrote:
> >> > Also how is GG deliberately downgrading clear unicode content to be kind
> >> > to obsolete clients at recipient end different from python 2 → 3 making
> >> > breaking changes but not going beyond ASCII lexemes?
> >> 
> >> Oh yes, I completely agree, obviously GvR is literally worse than Hitler
> >> because he hasn't added a bunch of Unicode characters with poor support for
> >> input and worse support for output as essential syntactic elements to
> >> Python.
> >> 
> >> /s
> > 
> > Gratuitous Godwin acceleration produceth poor sarcasm -- try again
> > And while you are at it try and answer the parallel:
> > Unicode has a major pro and con
> > Pro: Its a superset and enormously richer than ASCII
> 
> Correct.
> 
> > Con: It is costly and implementations are spotty
> 
> That's a matter of opinion. What do you mean by "spotty"?

We've had this conversation before.
Ive listed these spottinesses
See http://blog.languager.org/2015/03/whimsical-unicode.html
Specifically the section on ½-assed unicode support

> 
> It seems to me that implementations are mostly pretty good, at least as good 
> as 
> Python 2 narrow builds. Support for astral characters is not as good, but 
> (apart from some Han users, and a few specialist niches) not as import either.
> 
> The big problem is poor tooling: fonts still have many missing characters, 
> and 
> editors don't make it easy to enter anything not visible on the keyboard.
> 
> 
> > GG downgrades posts containing unicode if it can, thereby increasing reach 
> > to
> > recipients with unicode-broken clients
> 
> And how does that encourage clients to support Unicode? It just enables 
> developers to tell themselves "It's just a few weirdos and foreigners who use 
> Unicode, ASCII [by which they mean Latin 1] is good enough for everyone."
> 
> Its 2016, and it is *way* past time that application developers stop 
> pandering 
> to legacy encodings by making them the default. If developers saw that 99% of 
> emails were UTF-8, they would be less likely to think they could avoid 
> learning 
> about Unicode.
> 
>  
> > Likewise this:
> > 
> >> a bunch of Unicode characters with poor support for
> >> input and worse support for output as essential syntactic elements to
> >> Python.
> > 
> > sounds like the same logic applied to python
> > 
> > JFTR I am not quarrelling with Guido's choices; just pointing out your
> > inconsistencies
> 
> Oh, it's inconsistencies plural is it? So I have more than one? :-)

Here's one (below)
> 
> In Python 3, source files are treated as UTF-8 by default. That means, if you 
> want to use Unicode characters in your source code (for variable names, 
> comments, or in strings) you can, and you don't have to declare a special 
> encoding. Just save the file in an editor that defaults to UTF-8, and Python 
> is 
> satisfied. If, for some reason, you need some legacy encoding, you can still 
> explicitly set it with a coding cookie at the top of the file.
> 
> That behaviour is exactly analogous to my position that mail and news clients 
> should default to UTF-8. But in neither case would people be *required* to 
> include Unicode characters in their text.

Python2 had strings and unicode strings u"..."
Python3 has char-strings and byte-strings b"..." with the char-strings 
uniformly spanning all of unicode.

Not just a significant change in implementation but in mindset

Yet the way you use Unicode in the sentence above implies that while you
*say* 'Unicode' you mean the set Unicode - ASCII which is exactly
Python2 mindset.

So which mindset do you subscribe to?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can math.atan2 return INF?

[Marko Rauhamaa]

Gregory Ewing :

> Marko Rauhamaa wrote:
>> 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.
>
> Only in some frames of reference.
>
> By your reasoning, Zeno's paradox proves that a runner can never reach
> the finish line in a race.

In Zeno's case, the limit is finite. Zeno's error is not realizing that
you can pack an infinite number of jiffies in finite time. In the black
hole case, the limit is infinite.

> But it really only proves that if you measure time in such a way that
> the finishing time is infinitely far in your future, you will never
> see him finish.

An external observer never experiences any effect whatsoever (direct or
indirect) from an event horizon or a black hole.

> But there's no reason you have to draw the coordinates that way; there
> are plenty of others in which the time axis does cross the horizon.

Not where I'm standing.


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

Re: Assignment Versus Equality

[Gregory Ewing]

Dennis Lee Bieber wrote:

Or my favorite example of a parser headache: which is the loop
instruction and which is the assignment

DO10I=3,14
DO 10 I = 3.14


And if the programmer and/or compiler gets it wrong,
your spacecraft crashes into the planet.

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

Re: Can math.atan2 return INF?

[Rustom Mody]

On Tuesday, June 28, 2016 at 11:42:29 AM UTC+5:30, Gregory Ewing wrote:
> Rustom Mody wrote:
> > I said that for the Haskell list [0..]
> > 
> > [0..] ++ [-1] == [0..]
> > 
> > He said (in effect) yes that -1 would not be detectable but its still there!
> 
> The code to generate it is there, but it will never
> be executed, so the compiler is entitled to optimise
> it away. :-)
> 
> He may have a point though. There are avenues of
> mathematics where people think about objects such
> as "all the natural numbers, followed by -42", and
> consider that to be something different from just
> "all the natural numbers".
> 
> So, a mathematician would probably say they're not
> equal. A scientist would say they may or may not be
> equal, but the difference is not testable.
> 
> An engineer would say "Lessee, 0, 1, 2, 3, 4, 5,
> 6, 7... yep, they're equal to within measurement
> error."

Yes there is a sloppiness in my statement above:

[0..] ++ [-1] == [0..]

What kind of '==' is that?
If its the Haskell (or generally, programming language implementation) version
that expression just hangs trying to find the end of the infinite lists.

If its not then a devil's advocate could well say:
"So its metaphysical, theological and can know the unknowable,
viz. that that -1 which is computationally undetectable is nevertheless present.

ie the '++' can be a lazy Haskell *implemented* function
The '==' OTOH is something at least quasi mystical

Mathematicians are more likely to say 'mathematical' than 'mystical'
Such mathematicians -- the majority -- are usually called 'Platonists'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can math.atan2 return INF?

[Steven D'Aprano]

On Tuesday 28 June 2016 16:12, Gregory Ewing wrote:

> Rustom Mody wrote:
>> I said that for the Haskell list [0..]
>> 
>> [0..] ++ [-1] == [0..]
>> 
>> He said (in effect) yes that -1 would not be detectable but its still there!
> 
> The code to generate it is there, but it will never
> be executed, so the compiler is entitled to optimise
> it away. :-)
> 
> He may have a point though. There are avenues of
> mathematics where people think about objects such
> as "all the natural numbers, followed by -42", and
> consider that to be something different from just
> "all the natural numbers".
> 
> So, a mathematician would probably say they're not
> equal. A scientist would say they may or may not be
> equal, but the difference is not testable.
> 
> An engineer would say "Lessee, 0, 1, 2, 3, 4, 5,
> 6, 7... yep, they're equal to within measurement
> error."

And a programmer would write a script to compare the two, and then go to 
Stackoverflow asking for help to optimize it because it takes too long to 
complete.

Relevant:

https://blogs.msdn.microsoft.com/oldnewthing/20131029-00/?p=2803




-- 
Steve

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

Re: Assignment Versus Equality

[Rustom Mody]

On Tuesday, June 28, 2016 at 9:55:39 AM UTC+5:30, Marko Rauhamaa wrote:
> sohcahtoa82:
> 
> > On Monday, June 27, 2016 at 7:09:35 AM UTC-7, Marko Rauhamaa wrote:
> >> Grant Edwards :
> >> > Were there other languages that did something similar?
> >> 
> >> In XML, whitespace between tags is significant unless the document type
> >> says otherwise. On the other hand, leading and trailing space in
> >> attribute values is insignificant unless the document type says
> >> otherwise.
> >> 
> >> > Why would a language designer think it a good idea?
> >> >
> >> > Did the poor sod who wrote the compiler think it was a good idea?
> >> 
> >> Fortran is probably not too hard to parse. XML, on the other hand, is
> >> impossible to parse without the document type at hand. The document type
> >> not only defines the whitespace semantics but also the availability and
> >> meaning of the "entities" (e.g., © for ©). Add namespaces to that,
> >> and the mess is complete.
> >
> > XML isn't a programming language. I don't think it's relevant to the
> > conversation.
> 
> The question was about (formal) languages, not only programming
> languages.
> 
> However, there are programming languages with XML syntax:
> 
>https://en.wikipedia.org/wiki/XSLT>
>http://www.o-xml.org/spec/langspec.html>
>http://xplusplus.sourceforge.net/>

Seriously?!
You need to justify talking XML on a python list?

Which kind of 'python' this list is about?

https://www.facebook.com/nixcraft/photos/a.431194973560553.114666.126000117413375/1338469152833126/?type=3
-- 
https://mail.python.org/mailman/listinfo/python-list