Re: finding the diff

[Peter Otten]

Noah wrote:

> I am researching a nice slick way to provide the difference between
> generated python multi-line configuration output and specific
> configuration lines gathered from an output file.  I could put things in
> a list?   I could put both forms output into IOString() and run a diff
> command to it?

There's difflib in Python's standard library:

>>> import difflib
>>> print("".join(difflib.unified_diff(
... ["foo\n", "bar\n", "baz\n"],
... ["foo\n", "baz\n", "bang\n"])))
--- 
+++ 
@@ -1,3 +1,3 @@
 foo
-bar
 baz
+bang


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

Re: From logging to files to a better solution: syslog, Sentry, Logstash, ....

[Thomas Güttler]

Am Donnerstag, 10. September 2015 08:42:47 UTC+2 schrieb dieter:
> Thomas Güttler writes:
> > ...
> > Why we are unhappy with logging to files:
> >
> >  - filtering: We don't want to get INFO messages over the VPN.
> 
> You can quite easily control at what level messages are logged with
> the standard Python logging framework. Each handler has a level
> and will ignore messages at a lower level.


I want INFO to be logged and stored on the remote host.
Therefore I must not filter INFO messages.

I don't want to pull INFO messages over the VPN.

Ergo, the filtering at Python level does not help in my use case.
Or I am missing something.

And now I have an ugly soup. 

The ugly soup is a text file with not well defined syntax. It looks line
based. But sometimes there are log messages which span multiple lines 

Remember: "Life is too short to (re)write parsers"

Yes, there are tools to parse that soup. But why create this soup in 
the first place?

That's why I want to move from file based logging to a different solution.

Unfortunately there too many choices (graylog, logstash, sentry, ...) :-(



> >  - Rotating: Rotating files is possible, but somehow cumbersome.
> 
> There are standard tools to rotate logfiles.
> 
> >  - Support structured logging of values (json) in the future.
> 
> Again, the Python logging framework is quite flexible with
> respect to the format of logged messages.
> 
> > ...
> > Which solution could fit for our environment?
> 
> I work for a customer with a similar environment (he uses "Zope" instead
> of "Django") - and he uses logfiles. The logfiles are automatically
> rotated and there are in the order of half a dozen to a dozen logfiles
> per day.
> 
> When I have to analyse a problem with the help of the logfiles,
> I do not copy them via VPN but do the filtering remotely and only
> copy the filtered portion, if necessary.

Good to know that I am not the only one running servers in remote intranets.

Regards,
  Thomas Güttler
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Antoon Pardon]

Op 10-09-15 om 16:21 schreef Michael Torrie:
> On 09/10/2015 01:27 AM, Antoon Pardon wrote:
>> Op 09-09-15 om 19:55 schreef Steven D'Aprano:
>>> In fairness to the C creators, I'm sure that nobody back in the early
>>> seventies imagined that malware and security vulnerabilities would be as
>>> widespread as they have become. But still, the fundamental decisions made
>>> by C are lousy. Assignment is an expression?
>> What is wrong with that?
> Makes for a common error of putting an assignment in a conditional
> expression like:
>
> if (a=4) this_is_always_true();

No it doesn't. You confuse a semantic characteristic with the
specifix syntax that was chosen to express it in C.

Should C have chosen '<-' as token for assignment, that error
would have been far less common.

The error is also facilitated because C doesn't have booleans
and so everything can be used as one. If C would have had
proper booleans and only allowed those as conditions in if
and while statements, most of those errors would have been
caught too, because the expression a=4 wouldn't produce a
boolean.

> GCC will give you a warning over that these days.  But many C
> programmers still adopt a notation of
>
> if (4 == a) do_something();
>
> to protect them if they accidentally leave out one =.  If assignment was
> not an expression, then the compiler would properly error out every time
> you used a solitary = in the conditional of an if statement.

A language can provide this kind of protection and still allow
assignment as an expression. A lousy syntactical choice, doesn't
invalidate a particular choice in semantics.

> Python strikes a good compromise.  You can chain = in an assignment
> statement, but you can't use them in a conditional expression.

Python could have chosen other options, like a different assignment
token, like providing a proper boolean type and expection such a type
in a condition context. It could reverse the assignment so that you
would have to write: expression = var, so that if someone accidently
writes if var = expression instead of if var == expression, that would
have been caught. It could combine some of these options.

Now you possibly don't like these possibilities, but they show there
are multiple syntactical possibilities that all allow for assignment
as expressions, and that are less vulnerable than C for a specific
kind of error.

-- 
Antoon Pardon

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

Re: Python handles globals badly.

[Rustom Mody]

On Friday, September 11, 2015 at 10:04:25 AM UTC+5:30, Marko Rauhamaa wrote:
> Ian Kelly :
> 
> > You can use tabs *or* spaces. If you want to mix the two, then there
> > would need to be some official decision made about how many spaces
> > compose a tab, and then everybody who wants to use tabs would have to
> > configure their editors to conform to that decision, or risk breaking
> > their code. Some people like to indent two spaces. Some people like to
> > indent four spaces. On the other hand, the de facto standard for
> > terminal tab width is eight spaces. However, virtually nobody prefers
> > eight spaces of indentation. So the question is which standard are you
> > going to adopt, and which groups are you going to upset?
> 
> Indentation preferences and the interpretation of TABs are two separate
> things.

Required reading
http://www.jwz.org/doc/tabs-vs-spaces.html

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

Re: From logging to files to a better solution: syslog, Sentry, Logstash, ....

[marco . nawijn]

On Friday, September 11, 2015 at 9:22:42 AM UTC+2, Thomas Güttler wrote:
> Am Donnerstag, 10. September 2015 08:42:47 UTC+2 schrieb dieter:
> > Thomas Güttler writes:
> > > ...
> > > Why we are unhappy with logging to files:
> > >
> > >  - filtering: We don't want to get INFO messages over the VPN.
> > 
> > You can quite easily control at what level messages are logged with
> > the standard Python logging framework. Each handler has a level
> > and will ignore messages at a lower level.
> 
> 
> I want INFO to be logged and stored on the remote host.
> Therefore I must not filter INFO messages.
> 
> I don't want to pull INFO messages over the VPN.
> 
> Ergo, the filtering at Python level does not help in my use case.
> Or I am missing something.
> 
> And now I have an ugly soup. 
> 
> The ugly soup is a text file with not well defined syntax. It looks line
> based. But sometimes there are log messages which span multiple lines 
> 
> Remember: "Life is too short to (re)write parsers"
> 
> Yes, there are tools to parse that soup. But why create this soup in 
> the first place?
> 
> That's why I want to move from file based logging to a different solution.
> 
> Unfortunately there too many choices (graylog, logstash, sentry, ...) :-(
> 
> 
> 
> > >  - Rotating: Rotating files is possible, but somehow cumbersome.
> > 
> > There are standard tools to rotate logfiles.
> > 
> > >  - Support structured logging of values (json) in the future.
> > 
> > Again, the Python logging framework is quite flexible with
> > respect to the format of logged messages.
> > 
> > > ...
> > > Which solution could fit for our environment?
> > 
> > I work for a customer with a similar environment (he uses "Zope" instead
> > of "Django") - and he uses logfiles. The logfiles are automatically
> > rotated and there are in the order of half a dozen to a dozen logfiles
> > per day.
> > 
> > When I have to analyse a problem with the help of the logfiles,
> > I do not copy them via VPN but do the filtering remotely and only
> > copy the filtered portion, if necessary.
> 
> Good to know that I am not the only one running servers in remote intranets.
> 
> Regards,
>   Thomas Güttler

So, if logging to json is on the horizon anyway, why don't you create
something like a MongoDb handler in the standard Python logging framework 
and run a MongoDb server in the client intranet? You could then connect
over VPN to MongoDb, filter the warning/error messages there on the server
side and fetch them to your local systems for analysis.

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

Re: Python handles globals badly.

[Skybuck Flying]

"Random832"  wrote in message 
news:mailman.242.1441758354.8327.python-l...@python.org...


MRAB  writes:

If you're allowed to specify both bounds, why would you be forbidden
from negative ones?


"
It makes it non-obvious what value should be returned from e.g. search
methods that return a negative number on failure. .NET's IndexOf
function returns -1, but MaxValue if the array has a negative
bound. BinarySearch returns the complement of the nearest index to the
value you were searching for, which requires some gymnastics if you want
to make use of it for an array that has negative and positive bounds.
"

Yes pascal/Delphi allows negative bounds if I recall correctly, example:

var
   vIntegerArray : array[-10..10] of integer;

You have just given a very good reason why to not use negative values for 
return values/indications of success or failure.


In pascal I pretty much always try and use booleans to return success.

This is a smart thing to do... especially in pascal/Delphi, since one never 
knows when one is dealing with negative numbers having processing needs.


-1 could then cause problems/troubles/errors.

There is a drawback of using booleans which I suspect is the real reason why 
C programmers for example like to use -1 to indicate failure.


It's "speed/performance". Using a seperate boolean doubles memory 
requirement and might or might not require extra processing time from the 
CPU.


Delphi usually optimizes these booleans to be returned in EAX register... so 
it's a register based thing... if enough registers or so are available 
otherwise perhaps
some pushes/pops needed... not sure about that last thing. Whatever the case 
may be... I will assume for now... that nowadays the performance impact of 
using booleans
as return values is not that great ? Also I am not sure... but perhaps 
booleans allow safer/better procesing of boolean operations.


Not sure how -1 or if -1 could lead to problems with or/and statements... 
mixing C function results will also become problematic... sometimes C 
functions return 0 to indicate failure.


Sometimes 0 can even mean success.

So C is pretty inconsistent when it comes to return values.

Hence I believe Pascal/Delphi to be better/safer at this.

Bye,
 Skybuck. 


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

Re: Python handles globals badly.

[Steven D'Aprano]

On Fri, 11 Sep 2015 10:35 am, Ian Kelly wrote:

> On Thu, Sep 10, 2015 at 4:25 PM,   wrote:
[...]
>> So the compiler knows the distiction between global and local already.
> 
> As we've said before, it doesn't. The compiler's current rules are
> fairly simple:
> 
> 1) If it's in the function's argument list, it's an argument (and
> therefore local).
> 2) If it's explicitly declared global, then it's global.
> 3) If it's never assigned within the function, then it's global.

Almost. If it's never assigned within the function, then it is looked up
according to the non-local scoping rules:

- closures and enclosing functions (if any);
- globals;
- builtins;

in that order.


> 4) Otherwise, it's local.

"Otherwise" meaning "if it is assigned to", except that "del" counts as an
assignment. That is:

def spam():
del x

makes x a local variable inside the function spam.


There's also a bunch of specialised and complicated rules for what happens
if you make a star import ("from module import *") inside a function, or
call eval or exec without specifying a namespace. Both of these things are
now illegal in Python 3.

And lastly, in Python 3 only, there is also a nonlocal declaration which
works like global except it applies only to closures and enclosing
functions.


>> Another proof about identation:
>> The parser can recognise identation with tabs and spaces.
> 
> You can use tabs *or* spaces. 

In Python 3.

In Python 2, you can mix tabs *and* spaces, and Python will try to guess
what you mean. This causes more trouble than it is worth, and is removed in
Python 3.


[...]
> I really doubt that you're going to gain any traction with this one,
> because the decision that was made with Python 3 was to make the
> compiler *more* rigid about not mixing tabs and spaces, not less.

Correct.

[...]
>> Who is responding or has responded?
>> Extreme Programmers, Python-Hardliner, Python-Evangelists, ... .
>> Presumably no core Python Programmers (wrting compiler and standard
>> library stuff)
> 
> Ad hominem.

For the record, I am the author of the statistics module in Python 3.4, and
Terry Reedy is the very active maintainer of IDLE. If I have missed anyone,
my apologies. So, yes, there are core developers here.

(Although not any of the senior core devs, as far as I know.)



-- 
Steven

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

Re: From logging to files to a better solution: syslog, Sentry, Logstash, ....

[jmp]

On 09/11/2015 09:22 AM, Thomas Güttler wrote:


I want INFO to be logged and stored on the remote host.
Therefore I must not filter INFO messages.

I don't want to pull INFO messages over the VPN.

Ergo, the filtering at Python level does not help in my use case.
Or I am missing something.


Probably,

Your logger should have

  * a remote host handler
  * and a VPN handler.

You can set filters and log levels separately for each handler.
More info here
https://docs.python.org/2/library/logging.html#handler-objects
https://docs.python.org/2/howto/logging-cookbook.html#logging-to-multiple-destinations

Something like (python 2.7)

import logging

logCfg = {
'remote':(
logging.StreamHandler(),
logging.Formatter('Remote - %(levelname)s - %(message)s'),
logging.INFO,
),
'vpn':(
logging.StreamHandler(),
logging.Formatter('VPN - %(levelname)s - %(message)s'),
logging.ERROR,
),
}

log = logging.getLogger()
log.setLevel(logging.DEBUG)

for handler, formatter, level in logCfg.itervalues():
handler.setFormatter(formatter)
handler.setLevel(level)
log.addHandler(handler)

log.info('This is an info')
log.error('This is error')


and the result:

Remote - INFO - This is an info
VPN - ERROR - This is error
Remote - ERROR - This is error


JM


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

Re: Python handles globals badly.

[Chris Angelico]

On Fri, Sep 11, 2015 at 6:42 PM, Steven D'Aprano  wrote:
>>> Who is responding or has responded?
>>> Extreme Programmers, Python-Hardliner, Python-Evangelists, ... .
>>> Presumably no core Python Programmers (wrting compiler and standard
>>> library stuff)
>>
>> Ad hominem.
>
> For the record, I am the author of the statistics module in Python 3.4, and
> Terry Reedy is the very active maintainer of IDLE. If I have missed anyone,
> my apologies. So, yes, there are core developers here.
>
> (Although not any of the senior core devs, as far as I know.)

I don't know what the definition of "senior core dev" would be.
Checking the Experts List [1] shows you and Terry both, as does the
list of committers [2] (and it has me as well, although that's because
I wear a PEP Editor hat, so I don't count as even a non-senior core
dev). Is there an "inner circle" of people Guido trusts more than
"just ordinary core devs"? I rather suspect not, but maybe I'm wrong.

Hacking on CPython without core dev status is actually pretty easy.
I've done it. (Added a "while ... as name:" syntax, just to see how
hard it would be. Conclusion: It's not hard at all.) If anything,
that's a _lower_ bar to clear than "idiomatic Python programmer",
because anyone can hack on C code without understanding the goals and
beauties of the Python language. So I'm really not sure what the
original complaint was about, nor how to answer it.

ChrisA

[1] https://docs.python.org/devguide/experts.html#experts
[2] https://hg.python.org/committers.txt
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Antoon Pardon]

Op 10-09-15 om 18:48 schreef Chris Angelico:
> I'm not sure what the point would be of having an expression that
> doesn't return a value. The point of assignment-as-an-expression is
> that you can do other things with the result:
>
> while ((ch=getchar()) != EOF)
>
> In Python, we have a couple of cases where that's done with the 'as' keyword:
>
> with open(fn) as in_file:
>
> except KeyError as e:
>
> and there've been proposals now and then to have the same thing added
> to if and while, which actually isn't hard:
>
> while getchar() as ch:

I just don't get why people want to introduce special cases in python.
Why allow such a construct only in while and if? Why not just allow
it generally as an assignment expression?

Why not allow:

  while (f(x) as fx) > 5:
proces(fx)

or

  if check(nextvalue() as new):
treat(new)

One of the things I don't like about python is the limitation of the
slice syntax. I have been in situations where the natural thing to
do was write a method that takes a slice as a parameter and
have it called like: for key, value in Tree.items(lowkey:highkey).

But that doesn't work because slice notation is only allowed in
a subscription context.

It is kind of frustrating when you see something in the language
you think useful, to then notice the language doesn't allow you
to use in the context you need/want it.

At this moment I feel that introducing the "as v" possibily only
in while and if statements would mainly enlargen my frustration.

-- 
Antoon Pardon

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

Re: Python handles globals badly.

[Marko Rauhamaa]

Antoon Pardon :

> I just don't get why people want to introduce special cases in python.
> Why allow such a construct only in while and if? Why not just allow
> it generally as an assignment expression?
>
> Why not allow:
>
>   while (f(x) as fx) > 5:
> proces(fx)
>
> or
>
>   if check(nextvalue() as new):
> treat(new)

Hey, I know, I know!... Let's allow:

   while (fx = f(x)) > 5:
   process(fx)

   if check(new = nextvalue()):
   treat(new)

Seriously, though, I share your distaste of special cases, Antoon. Only
I don't like too much syntax (just look at Perl). There's nothing wrong
in:

   while True:
   fx = f(x)
   if fx <= 5:
   break
   process(fx)

   new = nextvalue()
   if check(new):
   treat(new)


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

Re: Python handles globals badly.

[random832]

On Fri, Sep 11, 2015, at 03:28, Antoon Pardon wrote:
> The error is also facilitated because C doesn't have booleans
> and so everything can be used as one.

Python does have booleans and everything can be used as one - the
logical conclusion is that being able to use everything as a boolean is
a positive feature that has nothing to do with lacking a "proper"
boolean type.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: numpy

[Laura Creighton]

In a message of Fri, 11 Sep 2015 10:35:41 +0800, "chenc...@inhand.com.cn" write
s:
>hi, Laura:
>My embedded arm device supports floating point operation.  I 
>have to use numpy and pandas packages. But now, I do not known how to 
>cross compile numpy and pandas packages?

You are going to have to ask this one here:
http://mail.scipy.org/mailman/listinfo/numpy-discussion

I do not know anybody who has got this to work yet, but if somebody
has, the people there will know.

Laura

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

Re: subdividing a rectangle using numpy

[Laura Creighton]

I think pyeuclid will do what you want.
https://pypi.python.org/pypi/euclid

Laura

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

Re: Signal SIGINT ignored during socket.accept

[Grant Edwards]

On 2015-09-11, Chris Angelico  wrote:

> This is what I meant when I said you would be polling. Effectively,
> you wake up your program every half-second, check if Ctrl-C has been
> pressed, and if it hasn't, you go back to sleep again. This is pretty
> inefficient.

Though it offends one's engineering sensibilities[1], it's just not
that inefficient. I'd bet money you won't even be able to measure the
difference in CPU usage. Waking up twice per second and immediately
calling select() again on any hardware/OS built in the past 50 years
is going completely negligible (as long as you can ignore the smell).

Even waking up ten times per second won't be noticeable.

Waking up every millisecond or two might be noticeable.

> Stupid Windows.

Agreed.

[1] If offenses to engineering sensibility were of concern, then
he wouldn't be using Windows in the first place.  ;)

-- 
Grant Edwards   grant.b.edwardsYow! PIZZA!!
  at   
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Signal SIGINT ignored during socket.accept

[Marko Rauhamaa]

Grant Edwards :

> On 2015-09-11, Chris Angelico  wrote:
>> This is what I meant when I said you would be polling. Effectively,
>> you wake up your program every half-second, check if Ctrl-C has been
>> pressed, and if it hasn't, you go back to sleep again. This is pretty
>> inefficient.
>
> Though it offends one's engineering sensibilities[1], it's just not
> that inefficient. I'd bet money you won't even be able to measure the
> difference in CPU usage. Waking up twice per second and immediately
> calling select() again on any hardware/OS built in the past 50 years
> is going completely negligible (as long as you can ignore the smell).
>
> Even waking up ten times per second won't be noticeable.
>
> Waking up every millisecond or two might be noticeable.

It can add up. In particular, it can prevent the CPU from staying in the
low-power mode, especially on battery-powered devices.

  https://lwn.net/Articles/549580/>

Another environment where such polling circuses can actually overwhelm a
CPU is virtual machines. When dozens or hundreds of VMs are each polling
left and right, the host may not get much actual work done.


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

Re: Signal SIGINT ignored during socket.accept

[Chris Angelico]

On Fri, Sep 11, 2015 at 11:50 PM, Grant Edwards  wrote:
> On 2015-09-11, Chris Angelico  wrote:
>
>> This is what I meant when I said you would be polling. Effectively,
>> you wake up your program every half-second, check if Ctrl-C has been
>> pressed, and if it hasn't, you go back to sleep again. This is pretty
>> inefficient.
>
> Though it offends one's engineering sensibilities[1], it's just not
> that inefficient. I'd bet money you won't even be able to measure the
> difference in CPU usage. Waking up twice per second and immediately
> calling select() again on any hardware/OS built in the past 50 years
> is going completely negligible (as long as you can ignore the smell).
>
> Even waking up ten times per second won't be noticeable.
>

True (although, as Marko says, it can add up). The other difference,
though, is that I like to keep "cope-with-stupidity" code to itself -
ideally, the clean path shouldn't be infected with it. Waking up
periodically with select(), when you otherwise just want a blocking
accept(), affects all your code. Spinning off a thread that monitors
stdin and signals the main thread when it's time to shut down can be
kept to a single block of code, guarded by some sort of platform
check:

import socket

PORT = 8880
mainsock = socket.socket()
mainsock.bind(("", PORT))
mainsock.listen(1)

if Windows: # however you want to go about checking this
import threading

# Python 2/3 compat
try: input = raw_input
except NameError: pass

def console():
"""Constantly read from stdin and discard"""
try:
while "moar console": input()
except (KeyboardInterrupt, EOFError):
socket.socket().connect(("127.0.0.1",PORT))

threading.Thread(target=console).start()

while "moar sockets":
s = mainsock.accept()
print("New connection: %r" % s)
# Do whatever you want with the connection
s.close()


As well as keeping the Unix variant stupidity-free, this allows you to
vary your platform check in the event that a future version of Windows
allows blocking calls to be interrupted. Or if a future version of
Python implements this kind of check globally. Or if a Python built
with Cygwin doesn't exhibit this behaviour. Or if PyPy... you get the
idea. The clean path is clearly delineated, and hopefully, the
complexity of your code will increase linearly with the number of
problems you're coping with, rather than having each patch affect each
other.

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

Re: Python handles globals badly.

[Ian Kelly]

On Fri, Sep 11, 2015 at 2:42 AM, Steven D'Aprano  wrote:
> On Fri, 11 Sep 2015 10:35 am, Ian Kelly wrote:
>
>> On Thu, Sep 10, 2015 at 4:25 PM,   wrote:
> [...]
>>> So the compiler knows the distiction between global and local already.
>>
>> As we've said before, it doesn't. The compiler's current rules are
>> fairly simple:
>>
>> 1) If it's in the function's argument list, it's an argument (and
>> therefore local).
>> 2) If it's explicitly declared global, then it's global.
>> 3) If it's never assigned within the function, then it's global.
>
> Almost. If it's never assigned within the function, then it is looked up
> according to the non-local scoping rules:
>
> - closures and enclosing functions (if any);
> - globals;
> - builtins;
>
> in that order.

I excluded non-locals intentionally, but if you want to be pedantic
about it, then that's still not quite right. Non-locals are indeed
identified by the compiler and compiled with the
LOAD_DEREF/STORE_DEREF opcodes (rather than the _GLOBAL and _FAST
variants used by globals and locals, respectively). The compiler
doesn't make any such distinction between globals and builtins
however, as that can only be determined at run-time.

> There's also a bunch of specialised and complicated rules for what happens
> if you make a star import ("from module import *") inside a function, or
> call eval or exec without specifying a namespace. Both of these things are
> now illegal in Python 3.

Huh?

>>> exec("x = 42")
>>> x
42
>>> exec("x = 43", None, None)
>>> x
43

That's in Python 3.4.0. Maybe I don't understand what you mean by
"without specifying a namespace".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Sat, Sep 12, 2015 at 1:03 AM, Ian Kelly  wrote:
>> There's also a bunch of specialised and complicated rules for what happens
>> if you make a star import ("from module import *") inside a function, or
>> call eval or exec without specifying a namespace. Both of these things are
>> now illegal in Python 3.
>
> Huh?
>
 exec("x = 42")
 x
> 42
 exec("x = 43", None, None)
 x
> 43
>
> That's in Python 3.4.0. Maybe I don't understand what you mean by
> "without specifying a namespace".

*inside a function*

>>> def f():
...exec("x = 42")
...print(x)
...
>>> x = 231
>>> f()
231

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

Re: Python handles globals badly.

[Ian Kelly]

On Fri, Sep 11, 2015 at 9:15 AM, Chris Angelico  wrote:
> On Sat, Sep 12, 2015 at 1:03 AM, Ian Kelly  wrote:
>>> There's also a bunch of specialised and complicated rules for what happens
>>> if you make a star import ("from module import *") inside a function, or
>>> call eval or exec without specifying a namespace. Both of these things are
>>> now illegal in Python 3.
>>
>> Huh?
>>
> exec("x = 42")
> x
>> 42
> exec("x = 43", None, None)
> x
>> 43
>>
>> That's in Python 3.4.0. Maybe I don't understand what you mean by
>> "without specifying a namespace".
>
> *inside a function*
>
 def f():
> ...exec("x = 42")
> ...print(x)
> ...
 x = 231
 f()
> 231

Ah, I didn't parse the "inside a function" as applying to that clause,
but even so, I don't see in what way that is "now illegal". For
example:

>>> x = 231
>>> def f():
...   exec("print(x); x = 42; print(x)")
...   print(x)
...
>>> f()
231
42
231

The exec still happily runs; it's just using its own private locals namespace.

Tangent: does the help for exec need to be updated? It currently reads:

The globals and locals are dictionaries, defaulting to the current
globals and locals.  If only globals is given, locals defaults to it.

Which would seem to indicate that if called from within a function
with no globals or locals, the locals from the function would be used.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Sat, Sep 12, 2015 at 1:27 AM, Ian Kelly  wrote:
> The exec still happily runs; it's just using its own private locals namespace.
>
> Tangent: does the help for exec need to be updated? It currently reads:
>
> The globals and locals are dictionaries, defaulting to the current
> globals and locals.  If only globals is given, locals defaults to it.
>
> Which would seem to indicate that if called from within a function
> with no globals or locals, the locals from the function would be used.

And that's the thing... I think. It's using locals(), which starts out
as a copy of the function's locals (in this example, empty), but
without assignment affecting anything. Which is more than a little
weird:

>>> def f():
... x = [1]
... exec("print(x); x[0] = 2; print(x); x = [3]; print(x)")
... print(x)
...
>>> f()
[1]
[2]
[3]
[2]

It's kinda like how globals can shadow builtins, I think. Maybe.
Except that you can't del the name inside exec to unshadow and go back
to the outer version of it.

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

Re: Python handles globals badly.

[Ian Kelly]

On Fri, Sep 11, 2015 at 9:44 AM, Chris Angelico  wrote:
> On Sat, Sep 12, 2015 at 1:27 AM, Ian Kelly  wrote:
>> The exec still happily runs; it's just using its own private locals 
>> namespace.
>>
>> Tangent: does the help for exec need to be updated? It currently reads:
>>
>> The globals and locals are dictionaries, defaulting to the current
>> globals and locals.  If only globals is given, locals defaults to it.
>>
>> Which would seem to indicate that if called from within a function
>> with no globals or locals, the locals from the function would be used.
>
> And that's the thing... I think. It's using locals(), which starts out
> as a copy of the function's locals (in this example, empty), but
> without assignment affecting anything. Which is more than a little
> weird:
>
 def f():
> ... x = [1]
> ... exec("print(x); x[0] = 2; print(x); x = [3]; print(x)")
> ... print(x)
> ...
 f()
> [1]
> [2]
> [3]
> [2]

Ah, that makes sense. It's writing into the dict that is created and
returned by locals(), but not actually updating the frame locals which
are the source of truth.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly  wrote:
>> And that's the thing... I think. It's using locals(), which starts out
>> as a copy of the function's locals (in this example, empty), but
>> without assignment affecting anything. Which is more than a little
>> weird:
>>
> def f():
>> ... x = [1]
>> ... exec("print(x); x[0] = 2; print(x); x = [3]; print(x)")
>> ... print(x)
>> ...
> f()
>> [1]
>> [2]
>> [3]
>> [2]
>
> Ah, that makes sense. It's writing into the dict that is created and
> returned by locals(), but not actually updating the frame locals which
> are the source of truth.

Yeah... but it only makes sense to people who understand the
implementation. It's certainly not a logical and sane behaviour that
would be worth documenting and using.

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

Re: Python handles globals badly.

[random832]

On Fri, Sep 11, 2015, at 11:55, Chris Angelico wrote:
> On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly  wrote:
> > Ah, that makes sense. It's writing into the dict that is created and
> > returned by locals(), but not actually updating the frame locals which
> > are the source of truth.
> 
> Yeah... but it only makes sense to people who understand the
> implementation. It's certainly not a logical and sane behaviour that
> would be worth documenting and using.

What else would you document? Reading from them is a reasonable thing to
do, and works. Writing to them is a reasonable thing to want to do, but
won't work, so you need to document that it doesn't work.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Context-aware return

[Rustom Mody]

On Friday, September 11, 2015 at 12:53:28 AM UTC+5:30, Grant Edwards wrote:
> On 2015-09-10, Steven D'Aprano  wrote:
> 
> > I have a function which is intended for use at the interactive interpreter,
> > but may sometimes be used non-interactively. I wish to change it's output
> > depending on the context of how it is being called.
> 
> [...]
> 
> Sounds like an excellent way to waste somebody's afternoon when they
> start to troubleshoot code that's using your function.  Over and over
> and over we tell newbies who have questions about what something
> returns or how it works
> 
> "Start up an interactive session, and try it!".
> 
> If word gets out about functions like yours, we sort of end up looking
> like twits.  
> 
> > If I did this thing, would people follow me down the street booing
> > and jeering and throwing things at me?
> 
> Only the people who use your function. :)


In emacs:
You can make a function a 'command' by putting an (interactive) into it.
And then in the function if you check interactive-p (nowadays more fashionably
'called-interactively-p' ) then it can figure out whether it was called from 
elisp or from emacs (top level)... and then change behavior accordingly.

IOW this behavior is quite routine in emacs-land
The norm being 
- Some functions are meant to be called only from Lisp
- Some functions (commands) only from emacs
- And then there are the 'Steven-functions'

I find it curious that the people getting upset about this are all the
emacs users [as far as I know] ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Sat, Sep 12, 2015 at 1:57 AM,   wrote:
> On Fri, Sep 11, 2015, at 11:55, Chris Angelico wrote:
>> On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly  wrote:
>> > Ah, that makes sense. It's writing into the dict that is created and
>> > returned by locals(), but not actually updating the frame locals which
>> > are the source of truth.
>>
>> Yeah... but it only makes sense to people who understand the
>> implementation. It's certainly not a logical and sane behaviour that
>> would be worth documenting and using.
>
> What else would you document? Reading from them is a reasonable thing to
> do, and works. Writing to them is a reasonable thing to want to do, but
> won't work, so you need to document that it doesn't work.

Documenting that "it doesn't work" seems fine. Documenting the
specific behaviour (that it gives you a sort of "shadow" locals, into
which you can write, but which won't persist past the execution of
that block of code) seems pointless. Especially since this behaviour
is implementation-dependent anyway.

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

Re: Context-aware return

[Rustom Mody]

On Friday, September 11, 2015 at 12:53:28 AM UTC+5:30, Grant Edwards wrote:
> On 2015-09-10, Steven D'Aprano  wrote:
> 
> > I have a function which is intended for use at the interactive interpreter,
> > but may sometimes be used non-interactively. I wish to change it's output
> > depending on the context of how it is being called.
> 
> [...]
> 
> Sounds like an excellent way to waste somebody's afternoon when they
> start to troubleshoot code that's using your function.  Over and over
> and over we tell newbies who have questions about what something
> returns or how it works
> 
> "Start up an interactive session, and try it!".
> 
> If word gets out about functions like yours, we sort of end up looking
> like twits.  
> 
> > If I did this thing, would people follow me down the street booing
> > and jeering and throwing things at me?
> 
> Only the people who use your function. :)


In emacs:
You can make a function a 'command' by putting an (interactive) into it.
And then in the function if you check interactive-p (nowadays more fashionably
'called-interactively-p' ) then it can figure out whether it was called from 
elisp or from emacs (top level)... and then change behavior accordingly.

IOW this behavior is quite routine in emacs-land
The norm being 
- Some functions are meant to be called only from Lisp
- Some functions (commands) only from emacs
- And then there are the 'Steven-functions'

I find it curious that the people getting upset about this are all the
emacs users [as far as I know] ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Rustom Mody]

On Friday, September 11, 2015 at 9:27:46 PM UTC+5:30, rand...@fastmail.us wrote:
> On Fri, Sep 11, 2015, at 11:55, Chris Angelico wrote:
> > On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly  wrote:
> > > Ah, that makes sense. It's writing into the dict that is created and
> > > returned by locals(), but not actually updating the frame locals which
> > > are the source of truth.
> > 
> > Yeah... but it only makes sense to people who understand the
> > implementation. It's certainly not a logical and sane behaviour that
> > would be worth documenting and using.
> 
> What else would you document? Reading from them is a reasonable thing to
> do, and works. Writing to them is a reasonable thing to want to do, but
> won't work, so you need to document that it doesn't work.

This is actually an old elusive holy grail -- first class environments.
In denotational semantics the two tools used to model variables and control-flow
respectively are environments and continuations.
The Scheme inventors were brave enough to mandate first-class continuations
but could not make the courage for first-class environments.
So every Scheme dialect introduces 1½ class envs in a ½-assed inconsistent way

Likewise python's locals-dicts and (I am guessing) most languages with some
commitment to first-classness
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Ian Kelly]

On Fri, Sep 11, 2015 at 10:04 AM, Chris Angelico  wrote:
> On Sat, Sep 12, 2015 at 1:57 AM,   wrote:
>> On Fri, Sep 11, 2015, at 11:55, Chris Angelico wrote:
>>> On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly  wrote:
>>> > Ah, that makes sense. It's writing into the dict that is created and
>>> > returned by locals(), but not actually updating the frame locals which
>>> > are the source of truth.
>>>
>>> Yeah... but it only makes sense to people who understand the
>>> implementation. It's certainly not a logical and sane behaviour that
>>> would be worth documenting and using.
>>
>> What else would you document? Reading from them is a reasonable thing to
>> do, and works. Writing to them is a reasonable thing to want to do, but
>> won't work, so you need to document that it doesn't work.
>
> Documenting that "it doesn't work" seems fine. Documenting the
> specific behaviour (that it gives you a sort of "shadow" locals, into
> which you can write, but which won't persist past the execution of
> that block of code) seems pointless. Especially since this behaviour
> is implementation-dependent anyway.

It's documented in the standard library docs:
https://docs.python.org/3.4/library/functions.html#exec

I think that's probably sufficient.
-- 
https://mail.python.org/mailman/listinfo/python-list

Problem with handling errors in POP3 message retrieval/deletion

[cl]

I have a (fairly) simple script that does 'catchall' processing on my
POP3 mailbox.  It looks for messages To: strings that *might* be for
me and then throws everything else away.

I was getting the occasional error as follows:-

Traceback (most recent call last):
  File "/home/chris/.mutt/bin/getCatchall.py", line 59, in 
popmsg = pop3.retr(i+1)
  File "/usr/lib/python2.7/poplib.py", line 232, in retr
return self._longcmd('RETR %s' % which)
  File "/usr/lib/python2.7/poplib.py", line 167, in _longcmd
return self._getlongresp()
  File "/usr/lib/python2.7/poplib.py", line 152, in _getlongresp
line, o = self._getline()
  File "/usr/lib/python2.7/poplib.py", line 377, in _getline
raise error_proto('line too long')
poplib.error_proto: line too long


So I added a try/except round the pop3.retr() and now I get this error:-

Traceback (most recent call last):
  File "/home/chris/.mutt/bin/getCatchall.py", line 63, in 
x = pop3.dele(i+1)
  File "/usr/lib/python2.7/poplib.py", line 240, in dele
return self._shortcmd('DELE %s' % which)
  File "/usr/lib/python2.7/poplib.py", line 160, in _shortcmd
return self._getresp()
  File "/usr/lib/python2.7/poplib.py", line 136, in _getresp
raise error_proto(resp)
poplib.error_proto: Data Base /Diamond /Arm /Freeway /Pocket /Barbecue
/Bathroom /Eyes /Train /Hat /Planet /Web /Girl /Surveyor /Rocket
/Slave /Software /Vampire /Vacuum /Sun /Egg /Leg /Ice /Guitar
/Post-office /Pepper /Hat /Eartupletters:10,50:
AAMGQLMUHSMCCVXEOPQRDWUSFEJFSHPEAQWHh /Spiral /Garden /Tennis racquet
/Banana /Spectrum /Bed /Fruit /Earth /Wheelchair /Spoon /Bee /Highway
/God /Guitar /Sandpaper /Typewriter /Finger /Feather /Salt
/Electricity /Pants /Sphere /Table /Comet / /Bee /Button /Map /Data
Base /Hieroglyph /Carpet /Hose /Bank /Fire /Solid /Staircase /Eyes
/Rope /School /Onion /Barbecue /Gemstone /Ice-cream /Nail /Alphabet
/Feather /Compass /Bottle /Shop /Fruit /Map /Sphere /Coffee /Radar
/Tongue /Tapestry /Radar /Sandwich /Circus /Spectrum /Aeroplane /Clock
/Room /Stomach /Snail / Satellite /Worm /Money  /Bed /Pyramid /Boy
/Pepper /Fruit /Junk /Bank /Bird /Pebble /Chair /Microscope /Satellite
/Woman /Kaleidoscope /Perfume /Triangle /Sunglasses /Needle
/Thermometer /Freeway /Man /Mist upletters:10,50:
TQDPDUGSMYEPJGBPYCTEIKMNFXKCSNDY/Vulture /Thermometer /Treadmill
/Pillow /Hose /Necklace /Coffee-shop /Space Shuttle /Pyramid /Rope
/Surveyor /Spot Light /Nail /Bed /Mist /Sandwich /Family /Salt /Fan
/Air /Maze /Mouth /Vacuum /Tongue /Bible /Gate /Wheelchair /Jet
fighter /Bible /Tunnel /Navy /Festival /Shop /Tapestry /Shower
/Cappuccino /Sandpaper /PaintBrush /Prison /Sex /Church /Man /Meat
/Ring /Snail /Floodlight /Toilet /Shower /Computer /Tiger /Diamond
/Bathroom /Boss /Leather jacket /Dress /Ship /Finger /Torpedo /Car
/Compass /Water /Mist /Butterfly /Staircase /Child /Backpack /Umbrella
/Tiger /School /Explosive /Restaurant /Bird /Cycle /Television
/Cappuccino /Bible /Kaleidoscope /Drill /Church /Television
/Hieroglyph /Game /Fungus /Sword /Gloves /Highway /Box functon /2022
/browser /cowritten /livinglogic /ione /800 /susceptibles /psz


Can anyone make any suggestions as to how to overcome this issue, all
I want to do is throw away the offending message.


The code for the whole thing is as follows:-

#!/usr/bin/python
#
#
# Collect E-Mail from my catchall POP3 mailbox on tsohost, deliver anything 
# that looks remotely useful and bin the rest
# 
#
import getpass, poplib
import email
import mailbox
import string
import smtplib
import time
import mailLib

home = "/home/chris"

log = mailLib.initLog("getCatchall")
#
#
# Read the filter file
#
fltr = {}
f = open(home + "/.mutt/getCatchall.filter", 'r')
for ln in f:# for each line in filter
if ln[0] == '#':# ignore comments
continue
#
#
# split the line into fields and store in a dictionary
#
fld = ln.split()
fltr[fld[0]] = fld[1]
#
#
# Process the messages, do a maximum of 100 at a time
#
while (1):
#
#
# Connect to the POP3 server, get message count, exit if no messages
#
pop3 = poplib.POP3_SSL('pop.isbd.net')
pop3.user('catch...@isbd.net')
pop3.pass_('')
numMessages = len(pop3.list()[1])
if (numMessages == 0):
break
#
#
# Process a maximum of 100 messages
#
log.info(str(numMessages) + " messages")
for i in range(min(numMessages, 100)):
#
#
# Read each message into a string and then parse with the email 
module, if
# the

Windows mingw64 compile pthon module error

[Wannaphong]

I using Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 
64 bit (AM
D64)] on win32. I install tdm64-gcc-5-1-0.exe. I setting from 
https://stackoverflow.com/a/27506457 , but I using "pip install scandir". 

C:\TDM-GCC-64\bin\x86_64-w64-mingw32-gcc.exe -shared -s build\temp.win-amd64
-3.4\Release\_scandir.o build\temp.win-amd64-3.4\Release\_scandir.def -LC:\py34\
libs -LC:\py34\PCbuild\amd64 -lpython34 -o build\lib.win-amd64-3.4\_scandir.pyd

C:\py34\libs/python34.lib: error adding symbols: File in wrong format

collect2.exe: error: ld returned 1 exit status

error: command 'C:\\TDM-GCC-64\\bin\\x86_64-w64-mingw32-gcc.exe' failed with
 exit status 1


Command "C:\py34\python.exe -c "import setuptools, tokenize;__file__='C:\\Us
ers\\B15D~1\\AppData\\Local\\Temp\\pip-build-vnnkz86l\\scandir\\setup.py';exec(c
ompile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), _
_file__, 'exec'))" install --record C:\Users\B15D~1\AppData\Local\Temp\pip-hhbfw
636-record\install-record.txt --single-version-externally-managed --compile" fai
led with error code 1 in C:\Users\B15D~1\AppData\Local\Temp\pip-build-vnnkz86l\s
candir

I apologize here. I am not good in English. Thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Signal SIGINT ignored during socket.accept

[James Harris]

"Grant Edwards"  wrote in message 
news:msum6c$hv$1...@reader1.panix.com...

On 2015-09-11, Chris Angelico  wrote:


This is what I meant when I said you would be polling. Effectively,
you wake up your program every half-second, check if Ctrl-C has been
pressed, and if it hasn't, you go back to sleep again. This is pretty
inefficient.


Though it offends one's engineering sensibilities[1], it's just not
that inefficient.


Indeed.


I'd bet money you won't even be able to measure the
difference in CPU usage.


You would win your bet.


Waking up twice per second and immediately
calling select() again on any hardware/OS built in the past 50 years
is going completely negligible (as long as you can ignore the smell).


CPU usage is not the only issue but it is a consideration. I tested it 
before posting the code and couldn't see any significant increase in CPU 
use. To give it a better test I have just left running for a couple of 
hours or so. I am pleased to say it currently reports a cumulative total 
of 0:00:00, i.e. it has not clocked up even a second of CPU time yet!


...


[1] If offenses to engineering sensibility were of concern, then
   he wouldn't be using Windows in the first place.  ;)


LOL. I know that's tongue in cheek but I tend to favour portability over 
most other things. So running on Windows as well as Unix is, in my book, 
a Good Thing.


James

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

Re: Problem with handling errors in POP3 message retrieval/deletion

[cl]

c...@isbd.net wrote:
> I have a (fairly) simple script that does 'catchall' processing on my
> POP3 mailbox.  It looks for messages To: strings that *might* be for
> me and then throws everything else away.
> 
[snip]

Sorry folks, I found the problem, it's a known 'bug' due to someone
trying to protect poplib from excessively long lines.  See:-

https://bugs.python.org/issue16041

It's easy to work around by something like:-

import poplib
poplib._MAXLINE=20480


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

Re: RPI.GPIO Help

[John McKenzie]

 Hello.

 Thanks to the help of people here and in other newsgroups I seem to have 
something working doing the basics. (Buttons work, colours light up 
appropriately.)

 When I followed MRAB's instructions and read about scopes of variables 
that solved my most recent problem, but it introduced a bug. I think I 
fixed the bug but after all my stupid mistakes and forgetfulness that 
seems too good to be true. I expect there is a better, more elegant, or 
more Pythonic way to do what I did so please feel free to share on the 
subject.

 I had a problem where if I pressed a button while the LEDs were already 
flashing the colour of that button it would block a new colour from 
starting when I pressed a new button. So if the LED strip was red and I 
pressed the red button again nothing would happen when I pressed the blue 
or yellow button. Similar problem for the other two buttons.

 So inside my callbacks I added this code:

   if colour == 1:
pass
elif colour == 2 or 3:
colour = 1


 Now it seems OK from my limited testing.


 Here is the code that has buttons and colours working and includes my 
bug fix:


import atexit 
import time 
from blinkstick import blinkstick 
import RPi.GPIO as GPIO   

led = blinkstick.find_first() 
colour = 0
time_red = 0
time_yellow = 0
time_blue = 0
timestamp = time.strftime("%H:%M:%S")

GPIO.setmode(GPIO.BCM)
GPIO.setup(22, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(23, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(24, GPIO.IN, pull_up_down=GPIO.PUD_UP)


def red_button(channel):
global colour
if colour == 1:
pass
elif colour == 2 or 3:
colour = 1
while colour == 1:
led.pulse(red=255, green=0, blue=0, repeats=1, duration=2000, 
steps=50)
def yellow_button(channel):
global colour
if colour == 2:
pass
elif colour == 1 or 3:
colour = 2
while colour == 2:
led.pulse(red=255, green=96, blue=0, repeats=1, 
duration=2000, steps=50)
def blue_button(channel):
global colour
if colour == 3:
pass
elif colour == 1 or 2:
colour = 3
while colour == 3:
led.pulse(red=0, green=0, blue=255, repeats=1, duration=2000, 
steps=50)


GPIO.add_event_detect(22, GPIO.FALLING, callback=red_button, 
bouncetime=200)
GPIO.add_event_detect(23, GPIO.FALLING, callback=yellow_button, 
bouncetime=200)
GPIO.add_event_detect(24, GPIO.FALLING, callback=blue_button, 
bouncetime=200)


while True:
if colour == 1:
time_red += 1
elif colour == 2:
time_yellow += 1
elif colour == 3:
time_blue += 1

time.sleep(0.1)


def exit_handler():
print "\033[0;41;37mRed Team:\033[0m ", time_red
print "\033[0;43;30mYellow Time:\033[0m ", time_yellow
print "\033[0;44;37mBlue Time:\033[0m ", time_blue
flog = open("flag1.log", "a")
flog.write(timestamp + "\n" + "Red Team: " + str(time_red) + "\n" + 
"Yellow Team: " + str(time_yellow) + "\n" + "Blue Team: " + str
(time_blue) + "\n")
flog.close()
led.set_color(name="black")
atexit.register(exit_handler)
GPIO.cleanup()



 I think I am OK GPIO wise now, although always happy to improve the code 
and in the long term I want to do so.

 Will start new threads for more straight forward Python questions like 
help with saving a log of the results, timing, etc.

 Thanks for your help, everyone.

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

Re: RPI.GPIO Help

[MRAB]

On 2015-09-11 19:24, John McKenzie wrote:


  Hello.

  Thanks to the help of people here and in other newsgroups I seem to have
something working doing the basics. (Buttons work, colours light up
appropriately.)

  When I followed MRAB's instructions and read about scopes of variables
that solved my most recent problem, but it introduced a bug. I think I
fixed the bug but after all my stupid mistakes and forgetfulness that
seems too good to be true. I expect there is a better, more elegant, or
more Pythonic way to do what I did so please feel free to share on the
subject.

  I had a problem where if I pressed a button while the LEDs were already
flashing the colour of that button it would block a new colour from
starting when I pressed a new button. So if the LED strip was red and I
pressed the red button again nothing would happen when I pressed the blue
or yellow button. Similar problem for the other two buttons.

  So inside my callbacks I added this code:

if colour == 1:
 pass
 elif colour == 2 or 3:
 colour = 1


  Now it seems OK from my limited testing.


[snip]

"colour == 2 or 3" means the same as "(colour == 2) or 3", where 3 is a
true value (zero is a false value; any non-zero number is a true value).

What you mean is "colour == 2 or colour == 3".

A shorter alternative is "colour in (2, 3)".

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

Re: RPI.GPIO Help

[hakugin . gin]

On Friday, September 11, 2015 at 2:25:15 PM UTC-4, John McKenzie wrote:
> Hello.
> 
>  Thanks to the help of people here and in other newsgroups I seem to have 
> something working doing the basics. (Buttons work, colours light up 
> appropriately.)



> def red_button(channel):
> global colour
> if colour == 1:
> pass
> elif colour == 2 or 3:
> colour = 1
> while colour == 1:
> led.pulse(red=255, green=0, blue=0, repeats=1, duration=2000, 
> steps=50)



Another option for this would be:

def red_button(channel):
global colour
if colour != 1:
colour = 1
# Rest of your original code goes below here


I am currently checking some other options, unfortunately I am not at home or 
have access to a RPi right now so I am unable to fully test.

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

CIVIL HERO & COMMODITIES, CURRENCIES, STOCKS GENIUS MICHELE NISTA micheleni...@gmx.com: HE GET IT RIGHT ON WORLDWIDE SECURITIES DE FACTO ALWAYS! BOUT 7320 PREDICTIONS SINCE AUGUST 1987 ( WHEN HE WAS +

[PRINCIPAL OF MURDERS&SLAUGHTERS SILVIO BERLUSCONI!]

CIVIL HERO & COMMODITIES, CURRENCIES, STOCKS GENIUS MICHELE NISTA 
micheleni...@gmx.com: HE GET IT RIGHT ON WORLDWIDE SECURITIES DE FACTO ALWAYS! 
BOUT 7320 PREDICTIONS SINCE AUGUST 1987 ( WHEN HE WAS +/- 20): 7320 SUCCESS! 
100% SHOCKING WINNING SCORE!
  
 GENIUS, KING MIDAS, CIVIL HERO MICHELE NISTA micheleni...@gmx.com! HE GET IT 
RIGHT ON WORLDWIDE STOCKS, CURRENCIES & COMMODITIES ALWAYS! ABOUT 7320 
PREDICTIONS ON INTERNET SINCE 8.1987 (WHEN WAS MORE OR LESS 20 YEARS OLD): 7320 
SUCCESS! 100% SHOCKING WINNING SCORE!!! GENIUS, KING MIDAS, CIVIL HERO MICHELE 
NISTA (micheleni...@gmx.com) ADVANCED IN EXTREMELY PERFECT WAY THE CONTINUOUS 
WALL STREET CRASH OF 1987 ( AS SAID.. AT THAT TIME HE WAS, MORE OR LESS, JUST 
20 YEARS OLD)! AS THE ONE OF 2007, 2008 AND BEGINNING OF 2009 WITH "JUST" 1 AND 
HALF YEAR OF INCREDIBLY WINNING FORETASTE! GENIUS, KING MIDAS, CIVIL HERO 
MICHELE NISTA micheleni...@gmx.com AVDANCED IN EXTREMELY PERFECT WAY, THEN, THE 
MORE OF DOUBLING OF WALL STREET, SINCE 3.2009! HE PROPHESIED ALL THIS ON 
INTERNET, AGAIN, WITH MONTHS AND MONTHS IN ADVANCE! ALL AT FANTASTIC LIGHT OF 
SUNSHINE!!! ALL PROVABLE AND VISIBLE STILL NOW!!! GENIUS, KING MIDAS, CIVIL 
HERO MICHELE NISTA (micheleni...@gmx.com) WAS "ONE OF THE NUMBER ONES" OF
  ITALIAN STOCK EXCHANGE, IN THE 90S, PRODUCING OVER 10 MILIONS OF EUROS OF 
COMMISSIONS OF THE 90S ( SO, 15 MILIONS OF NOW), FROM BELOW ZERO: WAS THE 
ABSOLUTE IDOL OF GOLDMAN SACHS, MERRILL LYNCH, AND NEARLY ANY "FOR GOOD" 
INVESTMENT BANK IN THE WORLD! THAT'S WHY EVERYONE WAS GIVING HIM AND STILL GIVE 
HIM THE NICK OF KING MIDAS! INGENIOUS HERO MICHELE NISTA HAS A GREAT HEART TOO, 
"NOT JUST" A SORT OF INVINCIBLE INTUITION! HE DEDICATES, SINCE HE WAS 17, ALL 
HIS GIFTS OF HEAVEN HE HAS TO POOREST PEOPLE IN THE WORLD, VOLUNTEERING AND NOT 
ONLY, FOR MANY ORGANIZATIONS SAVING OR IMPROVING SUFFERING LIVES IN LATIN 
AMERICA AND AFRICA. HE IS CERTAINLY A CIVIL INCORRUPTIBLE HERO TOO! IN THE LAST 
21 YEARS, IN MILAN, WAS THE MOST TENACIOUS MAN HUNTING TO DESTROY THE ASSASSIN 
DICTATORSHIP OF MAFIOSO, MEGA MAFIA MONEY LAUNDERER, EXTREME NAZIFASCIST, LIAR, 
MEGA THIEF, CORRUPTING PIG, PRINCIPAL OF HUNDREDS OF MURDERS AND SLAUGHTERS, 
VERY ASCERTAINED PEDOPHILE SILVIO BERLUSCONI! FOR ALL THIS, THERE W
 ERE FOUR ATTEMPTS OF KILLING HIM, ORDERED BY BASTARD SANGUINARY, AS WELL AS 
METASTASES OF THE ENTIRE WORLD: SILVIO BERLUSCONI!!! AND HIS FATHER LOST LIFE 
ON ORDER OF NAZIFASCIST AND COSA NOSTRA'S BRUTAL, VICIOUS, CRUEL, FEROCIOUS 
PRINCIPAL OF KILLING SILVIO BERLUSCONI (MAKING SHREWDLY TO PASS, VIA HIS 
PRIVATE OR PUBLIC NEW "OVRA, GESTAPO AND DINA" AL HIS ABSOLUTE REPELLENT 
HINDREDS OF HOMICIDES FOR FALSE ACCIDENTS, FALSE SUICIDES, FALSE ILLNESS, ALL 
THE TIMES)! AS A MATTER OF FACT, GENIUS, KING MIDAS, DEMOCRAT HERO MICHELE 
NISTA micheleni...@gmx.com "DECIDED TO EMIGRATE" TO LONDON, ON 2003, TO REMAIN 
ALIVE!! BUT GOD, IF HE'LL CONTINUE TO DESERVE SO, WILL MAKE HIM WIN!!! GROUP OF 
FRIENDS AND CLIENTS, EXTREMELY GRATEFUL TO THIS KING MIDAS, TO THIS INGENIOUS 
AND CIVIL HERO OF OUR TIMES: MICHELE NISTA (micheleni...@gmx.com)!!!

 

RUDI STUEZLI. SENIOR CONSULTANT GOLDMAN SACHS.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with handling errors in POP3 message retrieval/deletion

[Laura Creighton]

In a message of Fri, 11 Sep 2015 17:33:32 +0100, c...@isbd.net writes:
>I have a (fairly) simple script that does 'catchall' processing on my
>POP3 mailbox.  It looks for messages To: strings that *might* be for
>me and then throws everything else away.

Somebody tried to protect you from yourself.
see https://bugs.python.org/issue1604

after your imput do
poplib._MAXLINE=
20480 has been big enough for me ...

Laura

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

Re: RPI.GPIO Help

[hakugin . gin]

On Friday, September 11, 2015 at 2:25:15 PM UTC-4, John McKenzie wrote:
> Hello.
> 
>  Thanks to the help of people here and in other newsgroups I seem to have 
> something working doing the basics. (Buttons work, colours light up 
> appropriately.)
> 
>  When I followed MRAB's instructions and read about scopes of variables 
> that solved my most recent problem, but it introduced a bug. I think I 
> fixed the bug but after all my stupid mistakes and forgetfulness that 
> seems too good to be true. I expect there is a better, more elegant, or 
> more Pythonic way to do what I did so please feel free to share on the 
> subject.
> 
>  I had a problem where if I pressed a button while the LEDs were already 
> flashing the colour of that button it would block a new colour from 
> starting when I pressed a new button. So if the LED strip was red and I 
> pressed the red button again nothing would happen when I pressed the blue 
> or yellow button. Similar problem for the other two buttons.
> 
>  So inside my callbacks I added this code:
> 
>if colour == 1:
> pass
> elif colour == 2 or 3:
> colour = 1
> 
> 
>  Now it seems OK from my limited testing.
> 
> 
>  Here is the code that has buttons and colours working and includes my 
> bug fix:
> 
> 
> import atexit 
> import time 
> from blinkstick import blinkstick 
> import RPi.GPIO as GPIO   
> 
> led = blinkstick.find_first() 
> colour = 0
> time_red = 0
> time_yellow = 0
> time_blue = 0
> timestamp = time.strftime("%H:%M:%S")
> 
> GPIO.setmode(GPIO.BCM)
> GPIO.setup(22, GPIO.IN, pull_up_down=GPIO.PUD_UP)
> GPIO.setup(23, GPIO.IN, pull_up_down=GPIO.PUD_UP)
> GPIO.setup(24, GPIO.IN, pull_up_down=GPIO.PUD_UP)
> 
> 
> def red_button(channel):
> global colour
> if colour == 1:
> pass
> elif colour == 2 or 3:
> colour = 1
> while colour == 1:
> led.pulse(red=255, green=0, blue=0, repeats=1, duration=2000, 
> steps=50)
> def yellow_button(channel):
> global colour
> if colour == 2:
> pass
> elif colour == 1 or 3:
> colour = 2
> while colour == 2:
> led.pulse(red=255, green=96, blue=0, repeats=1, 
> duration=2000, steps=50)
> def blue_button(channel):
> global colour
> if colour == 3:
> pass
> elif colour == 1 or 2:
> colour = 3
> while colour == 3:
> led.pulse(red=0, green=0, blue=255, repeats=1, duration=2000, 
> steps=50)
> 
> 
> GPIO.add_event_detect(22, GPIO.FALLING, callback=red_button, 
> bouncetime=200)
> GPIO.add_event_detect(23, GPIO.FALLING, callback=yellow_button, 
> bouncetime=200)
> GPIO.add_event_detect(24, GPIO.FALLING, callback=blue_button, 
> bouncetime=200)
> 
> 
> while True:
> if colour == 1:
> time_red += 1
> elif colour == 2:
> time_yellow += 1
> elif colour == 3:
> time_blue += 1
> 
> time.sleep(0.1)
> 
> 
> def exit_handler():
> print "\033[0;41;37mRed Team:\033[0m ", time_red
> print "\033[0;43;30mYellow Time:\033[0m ", time_yellow
> print "\033[0;44;37mBlue Time:\033[0m ", time_blue
> flog = open("flag1.log", "a")
> flog.write(timestamp + "\n" + "Red Team: " + str(time_red) + "\n" + 
> "Yellow Team: " + str(time_yellow) + "\n" + "Blue Team: " + str
> (time_blue) + "\n")
> flog.close()
> led.set_color(name="black")
> atexit.register(exit_handler)
> GPIO.cleanup()
> 
> 
> 
>  I think I am OK GPIO wise now, although always happy to improve the code 
> and in the long term I want to do so.
> 
>  Will start new threads for more straight forward Python questions like 
> help with saving a log of the results, timing, etc.
> 
>  Thanks for your help, everyone.

I just noticed another potential issue with your code. You added "while" loops 
to your button functions, you should adjust the code so that the "led.pulse" 
call is in the main loop.

For example, at the beginning add something like:

pulse_settings = []


Change your button functions to change this new variable when the button is 
pressed:


def red_button(channel):
global colour, pulse_settings
if colour != 1:
colour = 1
pulse_settings = (red=255, green=0, blue=0, repeats=1, duration=2000, 
steps=50)


Then change your main "while" loop:

while True:
if colour == 1:
time_red += 1
elif colour == 2:
time_yellow += 1
elif colour == 3:
time_blue += 1
led.pulse(pulse_settings)
time.sleep(pulse_settings[4]) # sets the delay to the duration of the pulse 
effect


These are merely suggestions, again I do not have access to my RPi to test, 
your mileage may vary.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[tdev]

Reflecting latest answers to global and "proposals"


Ad hominem. 
There is a slogan: "There are always two persons involved"
This I dont want talk about. I dont go into such a discussion.
It seems more a problem of misinterpretations.


Proofs. 
Not really proofs. I meant more or less proofs. Proofs in "Proofs".
Proofs from my point of view or you can say from my understanding 
(or say also high level position view) and from the answers given so far


Samples 
(+main discussion "global"). 
Samples are often as text only in this thread. 
I think it is clear when you have followed the thread.
But the thread has now taken some new directions.
Yes, it is litte awkward searching back now.

But you can say, the "general" sample is:
You have to specify global that the compiler can distinguish
between local and global
Other words: global is needed to distinct global from local.

But this is "not" true.
You specify global cause you want write access.
Even the rules specified proves it:

> 1) If it's in the function's argument list, it's an argument (and
> therefore local).
> 2) If it's explicitly declared global, then it's global.
> 3) If it's never assigned within the function, then it's global.
> 4) Otherwise, it's local.

Take step 2 out than it is again recognized as global.  
So the global keyword is not needed to distinguish global from local.
Rule 3 proves it.



Identation.
It is stated
> It is correct that there have to be a decision for spaces or tabs.

With that I meant clearly no mixing of tabs and spaces.
So forget tabs (tabs changed to spaces) and take spaces.

The meaning is clearly:

def x():
  pass 2 spaces to the right

def y():
   pass3 spaces to the right


Surprisingly this runs now.
Sometimes I run into indentations errors similiar to sample above for no 
reasons 
(maybe cause of existing spaces on the end of a line - next occurences I will 
try to note it down)
But I have to remove this proposal for now.
Sorry.


PEP.
As previously stated I am not in the position (and/or knowledge)
to write a PEP. I wanted only to start a general (high-level point of view) 
discussion about it, in the hope there is somehow an agreement which starts 
somehow a PEP.

But from answers in this list I would say: No chance.
Practically no agreements. This I have to accept, although 
I cannot understand it (reasons given in previous post:
it was/is nothing more than to enhance and give even more flexibility 
to the language as with all the other features already available in 
parallel for the same reasons).


Conclusion.
I will use Python, but never become a Pythonier, 
although quite conform with its philosophy "One best way".
But even a traditional switch is denied, although much clearer
in reading and writing than any if-else construct.
I can and will not understand it.


Thanks for your answers.


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

Re: Python handles globals badly.

[Skybuck Flying]

Hello,

I'll add some arguments to the global discussion for you.

First a look back at the origin of this "global" keyword, basically it's 
idea behind it, which is probably a flawed assumption.


The origin/purpose of global as I now understand it is to give "write" 
access to globally declared variables.


This is first of all something unusual. Which other programmer language has 
this weird/whacky inconsistency ?


In general I believe inconsistent behaviour should be prevented in 
programming languages.


Anyway... having written/said that... there is a flawed assumption with this 
idea.


The assumption is that: "writing to globals is bad and can lead to bugs".

The further assumption is that: "denieing write access to globals prevents 
bugs".


Especially the last assumption is just plain wrong.

Not giving write access to globals can also lead to even much harder to find 
bugs.


The unaware programmer may assume that a global was changed, while in 
reality it was not.


How will such a bug be found ? Very hard to do in general, especially in an 
interpreter like python... where these bugs will need to be catched at run 
time.


Catching these bugs at runtime is far more difficult than bugs/errors which 
show up during compile time.


Thus forgetting "global" is going to be a far worse mistake... then actually 
overwritten or re-using some global accidently.


This kind of mistake can be checked by the programmer without requiring 
runtime inspection.


As soon as the programmer notices that some global is being re-used 
abusively the programmer can correct the situation.


With forgetting the global keyword not so... much harder to find.

Only possibility is to add "global" everywhere out of paranoya... which 
prevents the programmer from having to inspect every possibly line of code.


The global/write access requirement right now basically forces the 
programmer to check EVERY line of python code to see if a global is being 
written to which actually does not have the required write permission ?!?


How can anybody in their right mind think that is is somehow an improvement 
? It simply is not... unless the interpreter at runtime would start to BEEP 
or show ERROR messages in some log... that a global is being written too 
which actually does not have WRITE permissions ?


So far I have only used Sikuli to develop in Python... so let me ask a 
question here: Is there ANY Python IDE that actually produces such a warning 
or error message at runtime 


Is there any IDE which outputs:

"Error: GLOBAL variable being written too without WRITE permission ?!?".

How would the interpreter know that it is a global variable ? Well it's 
declared somewhere outside the scope of the function... so that's not the 
issue... issue is missing GLOBAL declaration inside the function... so it's 
more of a "WRITE" permission than "global permission".


So the name itself: "GLOBAL" is somewhat misleading... it's more a "WRITE" 
permission lol.


Just that reason alone is enough to remove "GLOBAL" from python language and 
replace it with: "WRITE".


or if it has to be: "GLOBAL-WRITE".

But any programmer would probably find that ridicilous.

So that basically proves that this GLOBAL requirement in itself is pretty 
ridicilous... though it does give a nice hint that this variable is a global 
variable ?! But is that really necessary ?!?


Perhaps, perhaps not... in PASCAL one would simply look at the top section 
of the function... where all variable must be declared, python lacks this 
feature which is kinda nice... but it does make it a bit problematic to spot 
if something is local or global.


While the next best thing the python programmer can do is: inspect the 
entire function to see if the variable is being written to or read from 
somewhere... but in reality this is no garantuee that it is local or 
global... so hence a little bit of a problem... adding global to the 
language is not really going to solve that... since programmer will have to 
add that manually to a variable... might forget it... and then the variable 
will actually still be a global variable.. and any bug fixer will still need 
to inspect code.


So basically this global requirement doesn't really help that much... as 
some say... it's a bit of a hint... a shitty one for that... it's almost 
like fuzzy logic... 50% chance that it's gonna help... 50% it's not gonna 
help ;) or might even lead to problems if read-only behaviour was actually 
required.


So when it comes to assumptions which bug is worse:

1. Willfully writing to a read-only global variable. (assignment failed-bug)
2. Mistakenly writing to a writeable global variable. (overwrite-bug)

As I already wrote before I think bug1 is much harder to spot then bug 2 by 
pure code inspection.


Ask yourself one question:

How many times does a programmer actually want a "read-only" global variable 
? This seems very weird to me.


Pascal solves this very nicely for "constants" with 

Re: Python handles globals badly.

[Ian Kelly]

On Fri, Sep 11, 2015 at 3:26 PM,   wrote:
> Ad hominem.
> There is a slogan: "There are always two persons involved"
> This I dont want talk about. I dont go into such a discussion.
> It seems more a problem of misinterpretations.

I think you misunderstand my comment. The paragraph that I was
responding to commits the ad hominem logical fallacy by supposing that
the credentials of the person making an argument have any bearing on
the validity of the argument. It therefore is dismissed as being
poorly reasoned. I point this out not to criticize, but to point out
that your argument is fallacious.

> But you can say, the "general" sample is:
> You have to specify global that the compiler can distinguish
> between local and global
> Other words: global is needed to distinct global from local.

This is not what I would consider a sample. I thought you were
referring to actual code examples demonstrating something.

> But this is "not" true.
> You specify global cause you want write access.
> Even the rules specified proves it:
>
>> 1) If it's in the function's argument list, it's an argument (and
>> therefore local).
>> 2) If it's explicitly declared global, then it's global.
>> 3) If it's never assigned within the function, then it's global.
>> 4) Otherwise, it's local.
>
> Take step 2 out than it is again recognized as global.
> So the global keyword is not needed to distinguish global from local.
> Rule 3 proves it.

Rule 3 works because it's generally safe to assume that a variable
that is never assigned locally can't be local; any attempt to access
it would result in an UnboundLocalError. (I say "generally" because
this assumption only holds as long as it's not possible to set locals
via eval or by updating locals(). That's true in the C implementation
of Python but not necessarily true in other implementations.)

Rule 3 doesn't imply that the compiler is capable of distinguishing
globals from locals. It's a guess based on a rule of thumb. So it's
less accurate to say that "you specify global cause you want write
access" and more accurate to say that "you specify global in cases
where the compiler can't guess it without assistance". It just so
happens that the two line up with one another.

> Surprisingly this runs now.
> Sometimes I run into indentations errors similiar to sample above for no 
> reasons
> (maybe cause of existing spaces on the end of a line - next occurences I will 
> try to note it down)
> But I have to remove this proposal for now.
> Sorry.

Yes, you can already choose between tabs or spaces for indentation.
You just can't mix them within the same code block.
-- 
https://mail.python.org/mailman/listinfo/python-list

monospaced font in MS Windows with wxpython

[Javier]

I am trying to use a monospaced font (preferably small) in MS Windows
with wxpython.  I have tried

txtctrl.SetFont(wx.Font(10, wx.MODERN, wx.NORMAL, wx.NORMAL, False, 
u'Consolas'))

but no success, I still get a proportional font.

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

Re: monospaced font in MS Windows with wxpython

[Emile van Sebille]

On 9/11/2015 3:16 PM, Javier wrote:

I am trying to use a monospaced font (preferably small) in MS Windows
with wxpython.  I have tried

txtctrl.SetFont(wx.Font(10, wx.MODERN, wx.NORMAL, wx.NORMAL, False, 
u'Consolas'))

but no success, I still get a proportional font.




You may also want to try posting to http://www.wxpython.org/maillist.php 
as they're more wxpython focused.


Emile


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

Re: Python handles globals badly.

[MRAB]

On 2015-09-11 22:26, t...@freenet.de wrote:

Reflecting latest answers to global and "proposals"


[snip]


But you can say, the "general" sample is:
You have to specify global that the compiler can distinguish
between local and global
Other words: global is needed to distinct global from local.

But this is "not" true.
You specify global cause you want write access.
Even the rules specified proves it:


1) If it's in the function's argument list, it's an argument (and
therefore local).
2) If it's explicitly declared global, then it's global.
3) If it's never assigned within the function, then it's global.
4) Otherwise, it's local.


Take step 2 out than it is again recognized as global.
So the global keyword is not needed to distinguish global from local.
Rule 3 proves it.


I'd would rephrase 3 and 4:

1) If it's in the function's argument list, it's local.

2) If it's declared global, it's global.

3) If it's assigned within the function, it's local.

4) Otherwise, it's global.



Conclusion.
I will use Python, but never become a Pythonier,
although quite conform with its philosophy "One best way".
But even a traditional switch is denied, although much clearer
in reading and writing than any if-else construct.
I can and will not understand it.


No-one can decide on how it should be written without it looking
syntactically inconsistent in some way compared to the other control 
structures.




Thanks for your answers.




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

Re: Signal SIGINT ignored during socket.accept

[James Harris]

"James Harris"  wrote in message 
news:msv21t$n1m$1...@dont-email.me...


"Grant Edwards"  wrote in message 
news:msum6c$hv$1...@reader1.panix.com...


...


Waking up twice per second and immediately
calling select() again on any hardware/OS built in the past 50 years
is going completely negligible (as long as you can ignore the smell).


CPU usage is not the only issue but it is a consideration. I tested it 
before posting the code and couldn't see any significant increase in 
CPU use. To give it a better test I have just left running for a 
couple of hours or so. I am pleased to say it currently reports a 
cumulative total of 0:00:00, i.e. it has not clocked up even a second 
of CPU time yet!


I am beginning to wonder if time is being accounted properly. It has now 
been running 8 hours and still shows CPU time as zero.


James

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

Re: Python handles globals badly.

[Michael Torrie]

On 09/11/2015 03:50 PM, Skybuck Flying wrote:
> Something which python does not seem to do currently ?!
> 
> So that's weird.
> 
> I will leave it at that for now.

Seems to me you have a completely mistaken understanding of how
variables work in Python.  This is one of the reasons why I have said in
the past, erroneously, that Python does not have variables.  It does of
course but not in the same way as C or Pascal.  In those languages names
are source-code abstractions only, and irrelevant to the compiler and
machine code.  C and Pascal define variables as boxes that can be
written to.  Not so in Python.

In Python most common objects are immutable. Meaning they can never
change or be overwritten.  They are bound to names.  This binding is
what makes names look like and act like traditional variables.

The secret to understanding the global keyword is to understand how
Python namespaces work.  The statement "a=5" does not assign a 5 to the
box called "a."  Rather it binds the name "a" to the "5" object, which
is immutable and called into existence by the interpreter
implementation.  Subsequently "a=6" disconnects a from the 5 object,
casting the 5 object loose to be reclaimed in some fashion that doesn't
matter at this point.  "a" is then rebound to a new object, 6.

When doing a look-up on a name, the interpreter first checks the local
scope's dictionary and if it does not find the name there there, goes to
the outer scope and so forth until you get to the module global
namespace.  So we don't need any special keywords to do Pascal-style
constants.  We just define them in the module and they work.  Usually we
name them in all caps so we have a bit of a convention as to where they
come from.  And yes we're talking about looking up strings in a
dictionary here.

When binding a name to an object, the interpreter always binds a name in
the local namespace, unless the global keyword has been used previously
and then it goes right to the global namespace.  As has been said
numerous times on this thread, how else would the interpreter do this?
There simply isn't any other way that makes sense. Certainly you haven't
made the case for it, seeing as you have some fundamental
misunderstandings about variables in Python.

You keep saying things like "writing to a variable" or "declared
variables" which just don't apply to Python because that's not how
Python variables work.  It may appear this way on the surface, but the
differences are subtle yet important.  Namespaces are written to, not
variables, some objects can be mutated. Names are bound to objects, but
variables are not declared, as a name can be bound to an object of any type.

Namespaces are powerful constructs that give Python much of its dynamic
nature and expressivity. Learn to use them!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[random832]

On Fri, Sep 11, 2015, at 20:01, Michael Torrie wrote:
> The secret to understanding the global keyword is to understand how
> Python namespaces work.  The statement "a=5" does not assign a 5 to the
> box called "a."  Rather it binds the name "a" to the "5" object, which
> is immutable and called into existence by the interpreter
> implementation.

In other words, it assigns a pointer to the "5" object [otherwise known
as "a 5"] to the box called "a". (And increments its reference count, if
you care about how the CPython garbage collector works)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Michael Torrie]

On 09/11/2015 06:11 PM, random...@fastmail.us wrote:
> On Fri, Sep 11, 2015, at 20:01, Michael Torrie wrote:
>> The secret to understanding the global keyword is to understand how
>> Python namespaces work.  The statement "a=5" does not assign a 5 to the
>> box called "a."  Rather it binds the name "a" to the "5" object, which
>> is immutable and called into existence by the interpreter
>> implementation.
> 
> In other words, it assigns a pointer to the "5" object [otherwise known
> as "a 5"] to the box called "a". (And increments its reference count, if
> you care about how the CPython garbage collector works)

Yes I suppose that works. It shows the difference between Pascal's "a :=
5" and Python's "a = 5".  So long as it's not just a pointer we're
talking about here; it's a counted reference. I think I prefer the word
"reference" to "pointer" in this case.  The word, pointer has certain
connotations that come from C.  Certainly in the implementation you
would probably use pointers.  But we don't really need a full physical
memory abstraction to understand names and how they are bound (made to
refer) to objects.  In fact it might be more useful to forget about the
underlying mechanisms in the interpreter.  And it's useful to think
about namespaces because then we can understand what happens when python
sees a variable in an expression. In any case, we're not overwriting any
values in Python assignments.

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

Re: monospaced font in MS Windows with wxpython

[Javier]

The font I posted before was actually monospaced.
I was just putting the definition in the wrong place

All solved now.  Sorry for the noise.

> txtctrl.SetFont(wx.Font(10, wx.MODERN, wx.NORMAL, wx.NORMAL, False, 
> u'Consolas'))

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

Re: Context-aware return

[Mark Lawrence]

On 10/09/2015 18:54, Steven D'Aprano wrote:

I have a function which is intended for use at the interactive interpreter,
but may sometimes be used non-interactively. I wish to change it's output
depending on the context of how it is being called.

If the function is being called as if it were a procedure or command, that
is the return result is just ignored, I want to return one thing. But if it
is being called where the return result goes somewhere, I want to return
something else. Most importantly, I don't want to pass a flag to the
function myself, I want the function to know its own context.

I don't mind if it is CPython only, or if it is a bit expensive.

E.g.

def func():
 do_stuff()
 if procedure:  # FIXME what goes here???
 return "Awesome"
 else:
 return 999

Now I can do this:

x = func()
assert x == 999

L = [1, 2, func(), 4]
assert L[2] == 999

func()
# interactive interpreter prints "Awesome"

Is such a thing possible, and if so, how would I do it?

If I did this thing, would people follow me down the street booing and
jeering and throwing things at me?



Not unless you were thrown in the Australian equivalent of Broadmoor 
first.  For those who don't know, Broadmoor is a famous place in the UK 
for the criminally insane.


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

Mark Lawrence

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

Re: Python handles globals badly.

[Mark Lawrence]

On 10/09/2015 23:25, t...@freenet.de wrote:

Some notes to the "global"-keyword and the other proposals.

It has been proposed to have these six enhancements

1. optional keyword "global"


Won't happen.


2. switch statement


Won't happen.


3. less restrictive indentation


Won't happen.


4. universal scope


No idea what you mean by this.


5. goto label


Won't happen.


6- "include" script statement


No idea what you mean by this.



with following proofs uncommented:



Your "proofs" hold about as much water as a bottomless bucket.


There is the big question:

Who is responding or has responded?
Extreme Programmers, Python-Hardliner, Python-Evangelists, ... .
Presumably no core Python Programmers (wrting compiler and standard library 
stuff)


Core Python Programmers have better things to do than waste their time 
on rubbish like this.  Examples include writing code and fixing bugs.  I 
understand that some of them are actually really weird and do other 
things like paid jobs, see their families, take holidays and worst of 
all, have other hobbies.




On Google groups you can currently read for this thread:
37 Authors. 152 posts. 443 views.

That is not that much for views (probably mostly from the writer's itself)

So, is this really the place where a PEP can be started?
When has a proposal to be accepted? If ten-thousands say yes?
Which ten-thousands? Who decides it?



The BDFL or his delegate decides, not that a PEP like this should be 
written.  If you want to waste your time please feel free to go ahead, I 
won't stop you.  However I do feel you should put this on python-ideas 
where it will be shot to pieces and then with any luck we'll get some 
peace and quiet.


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

Mark Lawrence

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

Re: Python handles globals badly.

[Mark Lawrence]

On 11/09/2015 03:19, Gene Heskett wrote:

On Thursday 10 September 2015 20:33:03 Dennis Lee Bieber wrote:


On Thu, 10 Sep 2015 12:04:05 -0700 (PDT), rurpy--- via Python-list

 declaimed the following:

I also doubt there were more programming languages around in the
1970s than now, on the grounds that there were far fewer people
capable of writing a compiler or interpreter in those days, and
there were far fewer tools to help, or easily accessible knowledge
about how to do do it.


Yet there were enough assorted semi-specialized languages in use on
military programs to induce the DoD to run the competition for a
singular language -- which became Ada.


And which should be noted that it has been a rather spectacular failure
in the commercial market.  Does that mean that those who can code in Ada
are working only for the military's suppliers, and because they are a
scarce commodity, writing their own paycheck? I don't know, other than
no one is publically bragging about it.


--
Wulfraed Dennis Lee Bieber AF6VN
 wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/



Cheers, Gene Heskett



Ada took over from CORAL in the UK, at least in military projects.  It 
was also used in the aircraft industry. My old work mates tell me that 
its completely died a death, to be replaced by C++.  Someone please 
remind me never to fly again.


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

Mark Lawrence

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

Re: Python handles globals badly.

[Mark Lawrence]

On 11/09/2015 06:15, Marko Rauhamaa wrote:

Chris Angelico :


Personally, I like to use tab characters for indentation. You can
choose how many pixels or ems or ens or spaces the actual visual shift
is, and if I disagree with your choice, it won't affect anything. As
long as tabs are used _exclusively_, Python won't be bothered by it
either.


Your preferred, novel usage of TABs, which runs counter to the age-old
programming convention, has won enough supporters to make TABs unusable.

No harm done. TABs have been banished. They were a bad idea in the first
place.

Marko



TABs might have been banished from some places, but certainly not 
Python.  Of course you have to be careful or you run into problems with 
this:-


TabError - Raised when indentation contains an inconsistent use of tabs 
and spaces.


https://docs.python.org/3/library/exceptions.html#TabError

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

Mark Lawrence

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

Re: Python handles globals badly.

[Gene Heskett]

On Friday 11 September 2015 22:35:00 Mark Lawrence wrote:

> On 11/09/2015 03:19, Gene Heskett wrote:
> > On Thursday 10 September 2015 20:33:03 Dennis Lee Bieber wrote:
> >> On Thu, 10 Sep 2015 12:04:05 -0700 (PDT), rurpy--- via Python-list
> >>
> >>  declaimed the following:
> >>> I also doubt there were more programming languages around in the
> >>> 1970s than now, on the grounds that there were far fewer people
> >>> capable of writing a compiler or interpreter in those days, and
> >>> there were far fewer tools to help, or easily accessible knowledge
> >>> about how to do do it.
> >>
> >>Yet there were enough assorted semi-specialized languages in use
> >> on military programs to induce the DoD to run the competition for a
> >> singular language -- which became Ada.
> >
> > And which should be noted that it has been a rather spectacular
> > failure in the commercial market.  Does that mean that those who can
> > code in Ada are working only for the military's suppliers, and
> > because they are a scarce commodity, writing their own paycheck? I
> > don't know, other than no one is publically bragging about it.
> >
> >> --
> >>Wulfraed Dennis Lee Bieber AF6VN
> >>  wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
> >
> > Cheers, Gene Heskett
>
> Ada took over from CORAL in the UK, at least in military projects.  It
> was also used in the aircraft industry. My old work mates tell me that
> its completely died a death, to be replaced by C++.  Someone please
> remind me never to fly again.
>
Oh my gawd. C++ in a airplane autopilot?  Now that's scarey.  And I was 
just in one, three each way actually, round trip halfway across the 
country, last December.

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


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 handles globals badly.

[Mark Lawrence]

On 11/09/2015 09:42, Steven D'Aprano wrote:

On Fri, 11 Sep 2015 10:35 am, Ian Kelly wrote:


On Thu, Sep 10, 2015 at 4:25 PM,   wrote:

[...]

So the compiler knows the distiction between global and local already.


As we've said before, it doesn't. The compiler's current rules are
fairly simple:

1) If it's in the function's argument list, it's an argument (and
therefore local).
2) If it's explicitly declared global, then it's global.
3) If it's never assigned within the function, then it's global.


Almost. If it's never assigned within the function, then it is looked up
according to the non-local scoping rules:

- closures and enclosing functions (if any);
- globals;
- builtins;

in that order.



4) Otherwise, it's local.


"Otherwise" meaning "if it is assigned to", except that "del" counts as an
assignment. That is:

def spam():
 del x

makes x a local variable inside the function spam.


There's also a bunch of specialised and complicated rules for what happens
if you make a star import ("from module import *") inside a function, or
call eval or exec without specifying a namespace. Both of these things are
now illegal in Python 3.

And lastly, in Python 3 only, there is also a nonlocal declaration which
works like global except it applies only to closures and enclosing
functions.



Another proof about identation:
The parser can recognise identation with tabs and spaces.


You can use tabs *or* spaces.


In Python 3.

In Python 2, you can mix tabs *and* spaces, and Python will try to guess
what you mean. This causes more trouble than it is worth, and is removed in
Python 3.


[...]

I really doubt that you're going to gain any traction with this one,
because the decision that was made with Python 3 was to make the
compiler *more* rigid about not mixing tabs and spaces, not less.


Correct.

[...]

Who is responding or has responded?
Extreme Programmers, Python-Hardliner, Python-Evangelists, ... .
Presumably no core Python Programmers (wrting compiler and standard
library stuff)


Ad hominem.


For the record, I am the author of the statistics module in Python 3.4, and
Terry Reedy is the very active maintainer of IDLE. If I have missed anyone,
my apologies. So, yes, there are core developers here.

(Although not any of the senior core devs, as far as I know.)



IIRC Serhiy Storchaka pops in occasionally, as on the one genuine report 
from the RUE about the FSR.  Slight aside, I swear blind that Serhiy 
never sleeps as he always seems to be doing something on the bug tracker.


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

Mark Lawrence

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

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 01:11, random...@fastmail.us wrote:

On Fri, Sep 11, 2015, at 20:01, Michael Torrie wrote:

The secret to understanding the global keyword is to understand how
Python namespaces work.  The statement "a=5" does not assign a 5 to the
box called "a."  Rather it binds the name "a" to the "5" object, which
is immutable and called into existence by the interpreter
implementation.


In other words, it assigns a pointer to the "5" object [otherwise known
as "a 5"] to the box called "a". (And increments its reference count, if
you care about how the CPython garbage collector works)



If everything in Python is an object, how can it assign a pointer? 
Especially how do Jython and IronPython assign pointers?


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

Mark Lawrence

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

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 01:01, Michael Torrie wrote:

On 09/11/2015 03:50 PM, Skybuck Flying wrote:

Something which python does not seem to do currently ?!

So that's weird.

I will leave it at that for now.


Seems to me you have a completely mistaken understanding of how
variables work in Python.  This is one of the reasons why I have said in
the past, erroneously, that Python does not have variables.  It does of
course but not in the same way as C or Pascal.  In those languages names
are source-code abstractions only, and irrelevant to the compiler and
machine code.  C and Pascal define variables as boxes that can be
written to.  Not so in Python.

In Python most common objects are immutable. Meaning they can never
change or be overwritten.  They are bound to names.  This binding is
what makes names look like and act like traditional variables.

The secret to understanding the global keyword is to understand how
Python namespaces work.  The statement "a=5" does not assign a 5 to the
box called "a."  Rather it binds the name "a" to the "5" object, which
is immutable and called into existence by the interpreter
implementation.  Subsequently "a=6" disconnects a from the 5 object,
casting the 5 object loose to be reclaimed in some fashion that doesn't
matter at this point.  "a" is then rebound to a new object, 6.

When doing a look-up on a name, the interpreter first checks the local
scope's dictionary and if it does not find the name there there, goes to
the outer scope and so forth until you get to the module global
namespace.  So we don't need any special keywords to do Pascal-style
constants.  We just define them in the module and they work.  Usually we
name them in all caps so we have a bit of a convention as to where they
come from.  And yes we're talking about looking up strings in a
dictionary here.

When binding a name to an object, the interpreter always binds a name in
the local namespace, unless the global keyword has been used previously
and then it goes right to the global namespace.  As has been said
numerous times on this thread, how else would the interpreter do this?
There simply isn't any other way that makes sense. Certainly you haven't
made the case for it, seeing as you have some fundamental
misunderstandings about variables in Python.

You keep saying things like "writing to a variable" or "declared
variables" which just don't apply to Python because that's not how
Python variables work.  It may appear this way on the surface, but the
differences are subtle yet important.  Namespaces are written to, not
variables, some objects can be mutated. Names are bound to objects, but
variables are not declared, as a name can be bound to an object of any type.

Namespaces are powerful constructs that give Python much of its dynamic
nature and expressivity. Learn to use them!



My favourite analogy for Python names, the sticky note, here 
https://mail.python.org/pipermail/tutor/2006-October/049767.html


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

Mark Lawrence

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

Re: Python handles globals badly.

[Steven D'Aprano]

On Fri, 11 Sep 2015 05:28 pm, Antoon Pardon wrote:

> Should C have chosen '<-' as token for assignment, that error
> would have been far less common.
> 
> The error is also facilitated because C doesn't have booleans
> and so everything can be used as one. If C would have had
> proper booleans 
[...]


In other words, "If C were some other language, then assignment as an
expression would be fine."

I believe I already acknowledged that assignment-as-expression was fine if
it avoided the = versus == error, from the perspective of avoiding errors.
But from the perspective of a clean and logical programming model, perhaps
not so much. Assignment is imperative, not functional, and requiring it to
return a result is somewhat unclean.

Look at it this way: suppose you had a robot servant that always, without
fail or misunderstanding, did what you instructed. There are broadly two
sorts of things that you can give as instructions: questions, and commands.
Questions always require an answer: "What's the length of this list?" is
functional. Commands are imperative, not functional, and don't necessarily
require an answer: "Move the small red pyramid onto the large green cube."
Some commands arguable might require an answer, but arguable they are
better served by an out-of-band error condition (an exception). *Requiring*
all commands to give an answer is silly, given that the robot servant is
infallible.

There's an argument to be made that, clean or not, assignment as an
expression is useful. So be it -- other languages do that. I personally
find it more confusing and annoying than useful when I come across it, but
YMMV.



-- 
Steven

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

Re: Python handles globals badly.

[Random832]

Mark Lawrence  writes:

> On 12/09/2015 01:11, random...@fastmail.us wrote:
> If everything in Python is an object, how can it assign a pointer?
> Especially how do Jython and IronPython assign pointers?

The Java and .NET runtimes also have pointers, they just don't [usually]
call them pointers, just like Python doesn't call them pointers (a match
made in... well, somewhere starting with an H, for sure).

Honestly, whether you want to call the thing a pointer or a reference,
you have to call it *something*, and I think "reference" is a worse fit
based on its connotations from C++. Whatever you call it, it's an arrow
on a diagram.

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

Re: Python handles globals badly.

[Random832]

Mark Lawrence  writes:
> My favourite analogy for Python names, the sticky note, here
> https://mail.python.org/pipermail/tutor/2006-October/049767.html

Is player3[3] also a sticky note? Wouldn't the note have to have the id
of player3 written on it somehow? Should the player3 sticky note have
the id of the global namespace that "player3" is valid in written on it?

I like my analogy better because it means both player3 and (the list we
call player3)[3] are both the *same* kind of thing: boxes that have
pointers in them (i.e. variables).

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

Re: Python handles globals badly.

[Mario Figueiredo]

On 12-09-2015 03:35, Mark Lawrence wrote:
>
> Ada took over from CORAL in the UK, at least in military projects.  It
> was also used in the aircraft industry. My old work mates tell me that
> its completely died a death, to be replaced by C++.  Someone please
> remind me never to fly again.

Alright. But then someone should probably have reminded you that a long
time ago.

Maybe you missed it when an Ada integer overflow bug produced one of the
most expensive software bugs in history by crashing the Ariane 501
rocket and its 4 cluster sattelites payload.

But sure. Don't let that get in your way of thinking there are safe
languages.


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

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 05:06, Random832 wrote:

Mark Lawrence  writes:


On 12/09/2015 01:11, random...@fastmail.us wrote:
If everything in Python is an object, how can it assign a pointer?
Especially how do Jython and IronPython assign pointers?


The Java and .NET runtimes also have pointers, they just don't [usually]
call them pointers, just like Python doesn't call them pointers (a match
made in... well, somewhere starting with an H, for sure).

Honestly, whether you want to call the thing a pointer or a reference,
you have to call it *something*, and I think "reference" is a worse fit
based on its connotations from C++. Whatever you call it, it's an arrow
on a diagram.



I think pointer is even worse because of its connection with C and hence 
cPython.  What is wrong with object if that is the only thing Python 
knows about?


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

Mark Lawrence

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

Terminology: “reference” versus “pointer” (was: Python handles globals badly.)

[Ben Finney]

Random832  writes:

> Honestly, whether you want to call the thing a pointer or a reference,
> you have to call it *something*, and I think "reference" is a worse
> fit based on its connotations from C++. Whatever you call it, it's an
> arrow on a diagram.

With the significant difference that “pointer” implies that it has its
own value accessible directly by the running program, such as a pointer
in C.

That's different from a “reference”, which to my understanding implies
the running program does *not* normally have direct access to it as a
distinct value. The only way you can use a reference is to get at the
object to which it refers.

That's the distinction I've been reying on for years, anyway: Python's
names are references, collections are collections of references, etc.
They aren't pointers because you can't get them as a distinct value; you
can only use them to refer to the object at the other end.

-- 
 \ “If we don't believe in freedom of expression for people we |
  `\   despise, we don't believe in it at all.” —Noam Chomsky, |
_o__)   1992-11-25 |
Ben Finney

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

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 05:16, Random832 wrote:

Mark Lawrence  writes:

My favourite analogy for Python names, the sticky note, here
https://mail.python.org/pipermail/tutor/2006-October/049767.html


Is player3[3] also a sticky note? Wouldn't the note have to have the id
of player3 written on it somehow? Should the player3 sticky note have
the id of the global namespace that "player3" is valid in written on it?

I like my analogy better because it means both player3 and (the list we
call player3)[3] are both the *same* kind of thing: boxes that have
pointers in them (i.e. variables).



For the final time I hope, "pointer" is not appropriate for Python, so 
I'll stick with the sticky note analogy, thanks all the same.


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

Mark Lawrence

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

Re: Python handles globals badly.

[Random832]

Mark Lawrence  writes:
> I think pointer is even worse because of its connection with C and
> hence cPython.  What is wrong with object if that is the only thing
> Python knows about?

Because the object is the *thing the arrow points at*. You don't have
two objects when store the same object in two variables (names, list
slots, whatever), but you do have two pointers.

And they *are* pointers in cPython - so that "connection" is a feature,
not a bug.

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

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 05:11, Mario Figueiredo wrote:

On 12-09-2015 03:35, Mark Lawrence wrote:


Ada took over from CORAL in the UK, at least in military projects.  It
was also used in the aircraft industry. My old work mates tell me that
its completely died a death, to be replaced by C++.  Someone please
remind me never to fly again.


Alright. But then someone should probably have reminded you that a long
time ago.

Maybe you missed it when an Ada integer overflow bug produced one of the
most expensive software bugs in history by crashing the Ariane 501
rocket and its 4 cluster sattelites payload.

But sure. Don't let that get in your way of thinking there are safe
languages.



Nothing to do with this being untested software then?  Actually it was 
so I'd put that down to a programmer error.  "The code always worked 
before so it's bound to work this time".  Such a pity that this 
particular launch wasn't the same as anything done previously.


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

Mark Lawrence

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

Re: Terminology: “reference” versus “pointer”

[Random832]

Ben Finney  writes:
> With the significant difference that “pointer” implies that it has its
> own value accessible directly by the running program, such as a pointer
> in C.

Its own value *is* what you're accessing when you assign or return
it. You just can't do math on it, but there are lots of things you can't
do math on.

> That's different from a “reference”, which to my understanding implies
> the running program does *not* normally have direct access to it as a
> distinct value. The only way you can use a reference is to get at the
> object to which it refers.

In C++, references cannot be reassigned. I consider *that* the
fundamental difference - a pointer is a variable that you can reassign
and return; a reference always refers to the same object once created.

> That's the distinction I've been reying on for years, anyway: Python's
> names are references, collections are collections of references, etc.
> They aren't pointers because you can't get them as a distinct value; you
> can only use them to refer to the object at the other end.

Anyway, maybe we do need a term to distinguish Python/C#/Java pointers
from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since
the key thing about it is you can't do pointer arithmetic on them to get
the object "next to" the one it points at.

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

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 05:34, Random832 wrote:

Mark Lawrence  writes:

I think pointer is even worse because of its connection with C and
hence cPython.  What is wrong with object if that is the only thing
Python knows about?


Because the object is the *thing the arrow points at*. You don't have
two objects when store the same object in two variables (names, list
slots, whatever), but you do have two pointers.

And they *are* pointers in cPython - so that "connection" is a feature,
not a bug.



How do I access these pointers?  Is there a builtin called pointer() 
that's analogous to id()?  I'll ask again, where do pointers come into 
the Jython and IronPython models?  How do I access their pointers, the 
same builtin?  The fact that the underlying implementation language has 
some terminology that it uses, has no bearing on the actual language 
being implemented.  This seems to me rather important, or have I missed 
something here?


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

Mark Lawrence

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

Re: Terminology: “reference” versus “pointer”

[Ben Finney]

Random832  writes:

> Ben Finney  writes:
> > With the significant difference that “pointer” implies that it has its
> > own value accessible directly by the running program, such as a pointer
> > in C.
>
> Its own value *is* what you're accessing when you assign or return it.

You're not describing Python references. But I don't know what you are
describing with all those “it”s — what language, what behaviour, what
concept?

Can you clarify what you mean, and what in my description you are
disagreeing with?

> > That's different from a “reference”, which to my understanding
> > implies the running program does *not* normally have direct access
> > to it as a distinct value. The only way you can use a reference is
> > to get at the object to which it refers.
>
> In C++, references cannot be reassigned. I consider *that* the
> fundamental difference - a pointer is a variable that you can reassign
> and return; a reference always refers to the same object once created.

Sure, that will work fine.

So in Python, we don't have pointers because we don't have access to
change or reassign them.

A Python reference isn't accessible and can't be changed; you can just
make another reference and switch to that.

You can't, for example, keep the old reference (there are no references
to references in Python), because they're not accessible as values in
themselves. Once you assign a different reference, the old one is gone
and can't be found again.

-- 
 \“[T]he great menace to progress is not ignorance but the |
  `\   illusion of knowledge.” —Daniel J. Boorstin, historian, |
_o__)1914–2004 |
Ben Finney

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

Re: Terminology: “reference” versus “pointer”

[Random832]

Ben Finney  writes:

> Random832  writes:
>
>> Ben Finney  writes:
>> > With the significant difference that “pointer” implies that it has its
>> > own value accessible directly by the running program, such as a pointer
>> > in C.
>>
>> Its own value *is* what you're accessing when you assign or return it.
>
> You're not describing Python references.

Yes I am. You're just making the implicit assumption that a "value" has
to be a number, and I was ignoring that assumption. The value is the
address of an object. Like I said, an arrow on a diagram.

> Can you clarify what you mean, and what in my description you are
> disagreeing with?
>
>> > That's different from a “reference”, which to my understanding
>> > implies the running program does *not* normally have direct access
>> > to it as a distinct value. The only way you can use a reference is
>> > to get at the object to which it refers.
>>
>> In C++, references cannot be reassigned. I consider *that* the
>> fundamental difference - a pointer is a variable that you can reassign
>> and return; a reference always refers to the same object once created.
>
> Sure, that will work fine.
>
> So in Python, we don't have pointers because we don't have access to
> change or reassign them.

Yes you do. That's _exactly what happens_ in an assignment statement -
you are reassigning it to the address of another object. And that's
something you *can't do* with references in C++.

Neither term is perfect, but "reference" is a *terrible* fit because of
that.

> A Python reference isn't accessible and can't be changed; you can just
> make another reference and switch to that.

Huh?

> You can't, for example, keep the old reference (there are no references
> to references in Python), because they're not accessible as values in
> themselves. Once you assign a different reference, the old one is gone
> and can't be found again.

You can keep it by copying it to somewhere. The pointer is the value,
not the variable, you don't _need_ a reference to it.

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

Re: Python handles globals badly.

[Random832]

Mark Lawrence  writes:
> How do I access these pointers?  Is there a builtin called pointer()
> that's analogous to id()?

You access them *all the time*. They are the *only* thing you access.

But if you want... pointer = lambda x: return x

> I'll ask again, where do pointers come into
> the Jython and IronPython models?  How do I access their pointers, the
> same builtin?  The fact that the underlying implementation language
> has some terminology that it uses, has no bearing on the actual
> language being implemented.

I am not using "pointer" as language-specific terminology, I am using it
as *the* name of the concept we are talking about. The Java and .NET
runtimes *don't* use that terminology, but they still *actually* have
pointers, in the same way that Python does.

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

Re: Terminology: “reference” versus “pointer”

[Ben Finney]

Random832  writes:

> Ben Finney  writes:
>
> > Random832  writes:
> >
> >> Ben Finney  writes:
> >> > With the significant difference that “pointer” implies that it has its
> >> > own value accessible directly by the running program, such as a pointer
> >> > in C.
> >>
> >> Its own value *is* what you're accessing when you assign or return it.
> >
> > You're not describing Python references.
>
> Yes I am. You're just making the implicit assumption that a "value" has
> to be a number, and I was ignoring that assumption. The value is the
> address of an object. Like I said, an arrow on a diagram.

I made no assumption about the type; I don't care how the reference is
implemented in the Python interpreter. That's not accessible to the
running Python program without some API.

My assertion still stands: the address of the object is *not* what the
reference is, in Python. Calling ‘id(foo)’ does not return a reference
to ‘foo’, so I don't know how you think the value is accessible in the
Python program.

The reference value is inaccessible to the program, it can only be used
to get at the referenced object.

> > So in Python, we don't have pointers because we don't have access to
> > change or reassign them.
>
> Yes you do. That's _exactly what happens_ in an assignment statement -
> you are reassigning it to the address of another object. And that's
> something you *can't do* with references in C++.

The operation you describe doesn't change the reference; it doesn't
mutate an existing value which can be compared with whatever value it
had before. Instead, it throws away one reference and replaces it with a
different one.

That's significant, because unlike a mutable value you can never again
get at the old reference in the Python program.

> > You can't, for example, keep the old reference (there are no references
> > to references in Python), because they're not accessible as values in
> > themselves. Once you assign a different reference, the old one is gone
> > and can't be found again.
>
> You can keep it by copying it to somewhere.

How do you propose to “copy” a reference in Python? Making a new
reference to the referenced object is not making a copy of the
reference.

-- 
 \ “Demagogue: One who preaches doctrines he knows to be untrue to |
  `\ men he knows to be idiots.” —Henry L. Mencken |
_o__)  |
Ben Finney

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

Re: Python handles globals badly.

[Skybuck Flying]

"Michael Torrie"  wrote in message 
news:mailman.384.1442016089.8327.python-l...@python.org...


On 09/11/2015 03:50 PM, Skybuck Flying wrote:

Something which python does not seem to do currently ?!

So that's weird.

I will leave it at that for now.


"
Seems to me you have a completely mistaken understanding of how
variables work in Python.  This is one of the reasons why I have said in
the past, erroneously, that Python does not have variables.  It does of
course but not in the same way as C or Pascal.  In those languages names
are source-code abstractions only, and irrelevant to the compiler and
machine code.  C and Pascal define variables as boxes that can be
written to.  Not so in Python.
"

Well you basically said it yourself:

" irrelevant to the compiler and machine code".

That's kinda nice about a high level language.

Programmer does not need to understand anything below the language.

A python programmer shouldn't need to understand a damn thing to write:

A  =  10
A = A + 1
print A

However for sake of your discussion I will continue your arguments below, 
since I get the impression you guys are clueless how to change python 
implementation ;)


"
In Python most common objects are immutable. Meaning they can never
change or be overwritten.  They are bound to names.  This binding is
what makes names look like and act like traditional variables.

The secret to understanding the global keyword is to understand how
Python namespaces work.  The statement "a=5" does not assign a 5 to the
box called "a."  Rather it binds the name "a" to the "5" object, which
is immutable and called into existence by the interpreter
implementation.  Subsequently "a=6" disconnects a from the 5 object,
casting the 5 object loose to be reclaimed in some fashion that doesn't
matter at this point.  "a" is then rebound to a new object, 6.
"

What happens for following code:

A=123456789011

Are you going to claim it's going to bind to all these numbers and then also 
multiple times ?


Sounds a bit shady ?! ;)

Perhaps python considers it a string ?

Python applies math to strings ?

Sounds a bit slow... therefore perhaps you're wrong...

"
When doing a look-up on a name, the interpreter first checks the local
scope's dictionary and if it does not find the name there there, goes to
the outer scope and so forth until you get to the module global
namespace.  So we don't need any special keywords to do Pascal-style
constants.  We just define them in the module and they work.  Usually we
name them in all caps so we have a bit of a convention as to where they
come from.  And yes we're talking about looking up strings in a
dictionary here.
"

So big deal, solution is easy to see, invert interpreter logic:

Everything declared is "not constant".

Everything declared as "constant" suddenly becomes constant.

And thus everything declared as not constant behaves the same way as 
"global", problem solved.


"
When binding a name to an object, the interpreter always binds a name in
the local namespace, unless the global keyword has been used previously
and then it goes right to the global namespace.  As has been said
numerous times on this thread, how else would the interpreter do this?
There simply isn't any other way that makes sense. Certainly you haven't
made the case for it, seeing as you have some fundamental
misunderstandings about variables in Python.
"

You didn't completely explain how the global namespace becomes writeable ? 
or re-bindeable ?


(It seems not necessary to explain it you implement the constant idea, as 
explained above already).


Do I have to assume that global namespace is "re-bindeable" = writeable ?

"
You keep saying things like "writing to a variable" or "declared
variables" which just don't apply to Python because that's not how
Python variables work.  It may appear this way on the surface, but the
differences are subtle yet important.  Namespaces are written to, not
variables, some objects can be mutated. Names are bound to objects, but
variables are not declared, as a name can be bound to an object of any type.
"

Well again you didn't explain how using namespaces suddenly lead to 
"rewritable" and/or "rebinding"


if A is declared as global as follows:

global A

and then code is written as follows:

A = 10
A = 20

def Test()
   global A = 30
   return

How does this make A "rewriteable" ? Or "rebindable" to 30 ?

"
Namespaces are powerful constructs that give Python much of its dynamic
nature and expressivity. Learn to use them!
"

I didn't learn anything from this posting, sorry ! ;)

Bye,
 Skybuck. 


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

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 06:07, Random832 wrote:

Mark Lawrence  writes:

How do I access these pointers?  Is there a builtin called pointer()
that's analogous to id()?


You access them *all the time*. They are the *only* thing you access.

But if you want... pointer = lambda x: return x


I'll ask again, where do pointers come into
the Jython and IronPython models?  How do I access their pointers, the
same builtin?  The fact that the underlying implementation language
has some terminology that it uses, has no bearing on the actual
language being implemented.


I am not using "pointer" as language-specific terminology, I am using it
as *the* name of the concept we are talking about. The Java and .NET
runtimes *don't* use that terminology, but they still *actually* have
pointers, in the same way that Python does.



Let's put it another way, in the 15 years I've been using Python I do 
not recall any experienced Python programmer using "pointer", so what 
makes you think, in 2015, that you are correct and everybody else is 
wrong?  I still say that everything in Python is an object, and should 
add that it has one or more things, "names", that are associated with 
it.  Hence my preferred analogy about the sticky note.


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

Mark Lawrence

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

Re: Python handles globals badly.

[Random832]

Mark Lawrence  writes:
> Let's put it another way, in the 15 years I've been using Python I do
> not recall any experienced Python programmer using "pointer", so what
> makes you think, in 2015, that you are correct and everybody else is
> wrong?  I still say that everything in Python is an object, and should
> add that it has one or more things, "names", that are associated with
> it.  Hence my preferred analogy about the sticky note.

So is player3[3] also a name, a sticky note? What if we copy player3 to
another name; does it get two sticky notes, player3[3] and foo[3]? Your
"sticky note" analogy doesn't unify variables/names/whatever you want to
call them with other places that you can assign stuff to, and it implies
that the objects themselves have knowledge of their "names", and that
names are global (if I have two functions each with a result variable,
does that mean there are two different result sticky notes?)

It doesn't matter that a pointer isn't what it's *called*, it's what it
*is*. And it's not an object, because you can copy it to more than one
place with only one object.

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

Re: Terminology: “reference” versus “pointer”

[Random832]

Ben Finney  writes:
> The reference value is inaccessible to the program, it can only be used
> to get at the referenced object.

That's like saying an integer is inaccessible since it can only be used
to add/subtract/etc (list of all operations you can do with an
integer). What does it mean to access something, if not to do some
operation on it? Getting the referenced object is the operation you can
do with it.

>> > So in Python, we don't have pointers because we don't have access to
>> > change or reassign them.
>>
>> Yes you do. That's _exactly what happens_ in an assignment statement -
>> you are reassigning it to the address of another object. And that's
>> something you *can't do* with references in C++.
>
> The operation you describe doesn't change the reference; it doesn't
> mutate an existing value which can be compared with whatever value it
> had before. Instead, it throws away one reference and replaces it with a
> different one.

So, if you have a list x, and assign a new value to x[0], it doesn't
change the list, because you can't compare the list to the value the
list had before?

You're not making any sense. It's a value. Changing it and "throwing
away and replacing with a different one" are the same thing.

> That's significant, because unlike a mutable value you can never again
> get at the old reference in the Python program.

I don't understand what you mean by "can never again get at" it if you
think you _can_ do it for mutable values.

>> > You can't, for example, keep the old reference (there are no references
>> > to references in Python), because they're not accessible as values in
>> > themselves. Once you assign a different reference, the old one is gone
>> > and can't be found again.
>>
>> You can keep it by copying it to somewhere.
>
> How do you propose to “copy” a reference in Python? Making a new
> reference to the referenced object is not making a copy of the
> reference.

Yes it is. I don't know why you think it's not, so I can't even figure
out how to respond to this.

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

Re: numpy

[Miki Tebeka]

On Thursday, September 10, 2015 at 1:11:59 PM UTC+3, chen...@inhand.com.cn 
wrote:
> hi:
> I have to use numpy package. My python runs on my embedded arm 
> device. So, how do i cross compile numpy?
conda has support for ARM - http://continuum.io/blog/new-arch

BTW: I suggest you write a better subject next time, almost missed this one :)
http://www.catb.org/esr/faqs/smart-questions.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Mark Lawrence]

On 12/09/2015 06:35, Random832 wrote:

Mark Lawrence  writes:

Let's put it another way, in the 15 years I've been using Python I do
not recall any experienced Python programmer using "pointer", so what
makes you think, in 2015, that you are correct and everybody else is
wrong?  I still say that everything in Python is an object, and should
add that it has one or more things, "names", that are associated with
it.  Hence my preferred analogy about the sticky note.


So is player3[3] also a name, a sticky note? What if we copy player3 to
another name; does it get two sticky notes, player3[3] and foo[3]? Your
"sticky note" analogy doesn't unify variables/names/whatever you want to
call them with other places that you can assign stuff to, and it implies
that the objects themselves have knowledge of their "names", and that
names are global (if I have two functions each with a result variable,
does that mean there are two different result sticky notes?)

It doesn't matter that a pointer isn't what it's *called*, it's what it
*is*. And it's not an object, because you can copy it to more than one
place with only one object.



There is NO CONCEPT in Python of a "pointer".  player3[3] is the fourth 
item of a list or similar, or a reference to something in a dictionary, 
but regardless of the type it is an object that has a name player3. 
player3 then gets copied to foo.  Both names are referring to the same 
object.  It certainly DOES NOT imply anything about objects having 
knowledge of their names and it DOES NOT say anything about the scope of 
names.  As for "two functions each with a result variable" I haven't the 
faintest notion what you could be talking about, would you please 
explain for the benefit of everybody reading this thread.


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

Mark Lawrence

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

Re: Terminology: “reference” versus “pointer”

[Chris Angelico]

On Sat, Sep 12, 2015 at 3:03 PM, Random832  wrote:
>> You can't, for example, keep the old reference (there are no references
>> to references in Python), because they're not accessible as values in
>> themselves. Once you assign a different reference, the old one is gone
>> and can't be found again.
>
> You can keep it by copying it to somewhere. The pointer is the value,
> not the variable, you don't _need_ a reference to it.

CPython happens to implement references using pointers, which leads a
lot of people to think that Python's references are pointers in
disguise. But Python (the language) does not have any concept of
pointers or memory. An integer is not a GNU Multiprecision Bignum
object, it is simply an integer. A string is not a series of bytes in
Latin-1/UCS-2/UCS-4, it is a series of codepoints. Aside from fiddling
around with ctypes (which isn't a supported action), there is nothing
you can do within Python to find out what a reference "is"; there is
literally ONE operation you can do with a reference, and that's to get
at the object it refers to. (For example, you might think that the
'is' operator is comparing two references to see if they point to the
same object. In CPython, it probably is implemented as a pointer
comparison; but actually, it's comparing two objects to see if they're
the same object.)

Python does not have pointers, not because you can't do arithmetic on
those pointers, but because they do not exist in the language spec.
The Python interpreter in my brain, which I use frequently when
diagnosing bugs (whether in my own or someone else's code), does not
have pointers; I'm not prepared to guarantee that it's 100% compliant
with the spec, but I know for sure that it _could be_, without adding
any notion of pointers.

C has pointers, and still would even pointer arithmetic were
disallowed. The languages are architected differently.

(Oh, and an object's identity is a special attribute of that object.
It's not like its location in memory, which is an attribute of the
reference to the object; it's a number that can be retrieved from the
object itself.)

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

Re: Terminology: “reference” versus “pointer”

[Mark Lawrence]

On 12/09/2015 06:42, Random832 wrote:

Ben Finney  writes:

The reference value is inaccessible to the program, it can only be used
to get at the referenced object.


That's like saying an integer is inaccessible since it can only be used
to add/subtract/etc (list of all operations you can do with an
integer). What does it mean to access something, if not to do some
operation on it? Getting the referenced object is the operation you can
do with it.


So in Python, we don't have pointers because we don't have access to
change or reassign them.


Yes you do. That's _exactly what happens_ in an assignment statement -
you are reassigning it to the address of another object. And that's
something you *can't do* with references in C++.


The operation you describe doesn't change the reference; it doesn't
mutate an existing value which can be compared with whatever value it
had before. Instead, it throws away one reference and replaces it with a
different one.


So, if you have a list x, and assign a new value to x[0], it doesn't
change the list, because you can't compare the list to the value the
list had before?


x still refers to a object which in this case happens to be a list. 
You've merely changed the value of the first element of the object that 
is referred to by the name x.




You're not making any sense. It's a value. Changing it and "throwing
away and replacing with a different one" are the same thing.


That's significant, because unlike a mutable value you can never again
get at the old reference in the Python program.


I don't understand what you mean by "can never again get at" it if you
think you _can_ do it for mutable values.


You can't, for example, keep the old reference (there are no references
to references in Python), because they're not accessible as values in
themselves. Once you assign a different reference, the old one is gone
and can't be found again.


You can keep it by copying it to somewhere.


How do you propose to “copy” a reference in Python? Making a new
reference to the referenced object is not making a copy of the
reference.


Yes it is. I don't know why you think it's not, so I can't even figure
out how to respond to this.



No it isn't.  When you make a copy of an object you will end up with two 
names that refer to the same object.


>>> x = [1,2,3]
>>> y = x
>>> x;y
[1, 2, 3]
[1, 2, 3]
>>> del x
>>> y
[1, 2, 3]

If y was a copy of x, then when x is blown away how can y still know 
about the list that x originally referred to?


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

Mark Lawrence

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

Re: Python handles globals badly.

[Chris Angelico]

On Sat, Sep 12, 2015 at 3:35 PM, Random832  wrote:
> Mark Lawrence  writes:
>> Let's put it another way, in the 15 years I've been using Python I do
>> not recall any experienced Python programmer using "pointer", so what
>> makes you think, in 2015, that you are correct and everybody else is
>> wrong?  I still say that everything in Python is an object, and should
>> add that it has one or more things, "names", that are associated with
>> it.  Hence my preferred analogy about the sticky note.
>
> So is player3[3] also a name, a sticky note? What if we copy player3 to
> another name; does it get two sticky notes, player3[3] and foo[3]? Your
> "sticky note" analogy doesn't unify variables/names/whatever you want to
> call them with other places that you can assign stuff to, and it implies
> that the objects themselves have knowledge of their "names", and that
> names are global (if I have two functions each with a result variable,
> does that mean there are two different result sticky notes?)

Whatever you want to use to describe a name-binding reference, the
exact same thing applies to a list element or anything else. If your
analogy is strings tied to sheets of paper, with sticky notes on the
ends of strings to represent actual names, then you have similar
strings connecting list elements to their referents. (The sticky notes
aren't actually part of the objects, and you just have to understand
that you can't trace a string "backwards", only "forwards"; there's no
way to start with an object and ask "what refers to this?".)

Here. Ned Batchelder explains it better than I can.

http://nedbatchelder.com/text/names1.html
https://www.youtube.com/watch?v=_AEJHKGk9ns

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

Re: Terminology: “reference” versus “pointer”

[Random832]

Mark Lawrence  writes:

> No it isn't.  When you make a copy of an object you will end up with
> two names that refer to the same object.

No, when you *make a copy of* an object, you get two objects.

>>> x = [1, 2, 3]
>>> y = copy.copy(x)
>>> x is y
False

What you make a copy of when you do y = x is not the object.

> If y was a copy of x, then when x is blown away how can y still know
> about the list that x originally referred to?

Because what is in x, and therefore what is copied when you assign y =
x, *is* the knowledge of how to find the list. Not the list itself. The
object is also not what is deleted when you delete it.

And deleting the original does not delete a copy and I don't even
understand how you can possibly think it could.

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

Re: Python handles globals badly.

[Random832]

Chris Angelico  writes:
> Here. Ned Batchelder explains it better than I can.

See, those diagrams are perfect (well, almost, I think the names should
have square boxes too). They're arrows. They *point* at
things. *Pointers*.

The boxes are variables. The circles represent special boxes
(implemented in C or Java or whatever) that hold things other than
pointers and therefore can't be used as Python variables.

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

Re: Terminology: “reference” versus “pointer”

[Ben Finney]

Random832  writes:

> Ben Finney  writes:
> > The reference value is inaccessible to the program, it can only be
> > used to get at the referenced object.
>
> What does it mean to access something, if not to do some operation on
> it? Getting the referenced object is the operation you can do with it.

You've clearly committed to some ontology that just doesn't match the
Python data model.

The following are some of the axioms in Python's data model:

* All values are objects that persist over time.

* All objects have an immutable identity, that is guaranteed different
  from all other coexisting objects.

* The identity of an object has no particular relationship to the
  object's implementation or location [0], it is an abstract value that
  has no meaning other than uniquely identifying the object.

* The ‘id’ function returns the identity of the object passed as the
  parameter to the call.

* A name used to access an object is a reference to that object,
  equivalent to an item in a dictionary.

* A collection instance — a list, a dict, a set, etc. — contains
  references to objects, and provide access to those references via the
  container type's API.

If you don't agree with those, that's too bad, and it means there's not
much point continuing the discussion. I hope, therefore, that you do
agree with those axioms.

If you do agree with those, some corollaries follow:

* Container types do not contain objects.

  It is a useful analogy to say the objects are “in” the container; but
  that would imply they are not simultaneously in any other container.
  That's not true, so it's a flawed (though very useful) analogy.

* Names do not contain anything.

  They aren't what some other languages call “variables”. They are
  oblivious to the type of the value and can never exist except while
  referencing some object.

* References are not values.

  The reference obviously must have an implementation that deals with
  values, but those values are not available in Python. Each reference
  is inaccessible, hidden away; it is not a value, it is not an object.

> So, if you have a list x, and assign a new value to x[0], it doesn't
> change the list, because you can't compare the list to the value the
> list had before?

Yes, it changes the list. It doesn't change any of the references
themselves.

The list's value is the sequence of references it contains. Removing one
reference changes the list's value; putting a different reference in the
collection changes the list's value.

None of that changes any reference, it just changes *which* references
are in the list.

The references themselves don't have any value accessible to Python.

> You're not making any sense. It's a value. Changing it and "throwing
> away and replacing with a different one" are the same thing.

Not true. To throw away one and replace it with another is to switch to
a different value with a different identity::

>>> foo = 17 # One reference to the integer object.
>>> bar = foo# A different reference to the object.
>>> id(foo) == id(bar)# Are these references to the same object?
True
>>> bar = 9   # Try to “change” the object.
>>> id(foo) == id(bar)# Is ‘bar’ still the same object?
False

To change a value is to keep the same identity::

>>> foo = [17, 23, 42]# One reference to the list object.
>>> bar = foo # A different reference to the object.
>>> id(foo) == id(bar)# Are these references to the same object?
True
>>> id(foo[2]) == id(bar[2])  # How about the references contained in the 
list?
True
>>> bar[2] = 9# Try to “change” the object.
>>> id(foo) == id(bar)# Is ‘bar’ still the same object?
True

References aren't values, so their identity doesn't even feature in
Python's data model.

From the point of view of a Python program, a reference *has no value*
(and no identity). It is just a metaphorical label, tag, or “sticky
note” one can invoke to make a specific object available.

> > That's significant, because unlike a mutable value you can never
> > again get at the old reference in the Python program.
>
> I don't understand what you mean by "can never again get at" it if you
> think you _can_ do it for mutable values.

In the above example, the different references originally created for
‘foo’ and ‘bar’ are inaccessible. ‘foo’ and ‘bar’ are not the same, they
are different references that happen to lead to the same object.

When ‘bar’ switches to a different reference, whatever reference it had
at prior points in time are gone for good. Any other references to the
same object continue on unaffected, because they are not the same
reference.



[0]: This axiom is unfortunately confused in the documentation's
  statement “you may think of it as the object’s address in memory”
  https://docs.python.org/3/reference/datamodel.html>. That's not a
  guarantee of the data model, it is merely meant to help 

Re: Python handles globals badly.

[Chris Angelico]

On Sat, Sep 12, 2015 at 4:25 PM, Random832  wrote:
> Chris Angelico  writes:
>> Here. Ned Batchelder explains it better than I can.
>
> See, those diagrams are perfect (well, almost, I think the names should
> have square boxes too). They're arrows. They *point* at
> things. *Pointers*.
>
> The boxes are variables. The circles represent special boxes
> (implemented in C or Java or whatever) that hold things other than
> pointers and therefore can't be used as Python variables.

Okay, okay, you've won. They're pointers. Now, try to do anything with
them. They *instantly* devolve to their referent objects, which means
you cannot do anything with the pointer at all. Congratulations,
pointers do not exist.

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

Re: Terminology: “reference” versus “pointer”

[Chris Angelico]

On Sat, Sep 12, 2015 at 4:26 PM, Ben Finney  wrote:
> If you do agree with those, some corollaries follow:
>
> * Container types do not contain objects.
>
>   It is a useful analogy to say the objects are “in” the container; but
>   that would imply they are not simultaneously in any other container.
>   That's not true, so it's a flawed (though very useful) analogy.

It's so useful that we have an operator called "in", implemented using
a magic method "__contains__", to test exactly that concept. As long
as you understand that containment here really means something more
like "is accessible from", it's correct. Flawed in a minor way, but so
extremely convenient that it's not worth going for complete technical
correctness.

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

Re: From logging to files to a better solution: syslog, Sentry, Logstash, ....

[dieter]

Thomas Güttler  writes:

> Am Donnerstag, 10. September 2015 08:42:47 UTC+2 schrieb dieter:
>> Thomas Güttler writes:
>> > ...
>> > Why we are unhappy with logging to files:
>> >
>> >  - filtering: We don't want to get INFO messages over the VPN.
>> 
>> You can quite easily control at what level messages are logged with
>> the standard Python logging framework. Each handler has a level
>> and will ignore messages at a lower level.
>
>
> I want INFO to be logged and stored on the remote host.
> Therefore I must not filter INFO messages.
>
> I don't want to pull INFO messages over the VPN.

Thus, you could define one handler which logs at INFO level and
another one which logs at WARNING level. The latter handler
would log only WARNING and more serious events.

> ...
> Yes, there are tools to parse that soup. But why create this soup in 
> the first place?
>
> That's why I want to move from file based logging to a different solution.

As you have explained above, you need this "soup" (both INFO messages
as well as messages above WARNING level - but handled differently).

Define an additional handler which handles "WARNING" (and above).
This is easy with Zope (I do not know for Django).


> Unfortunately there too many choices (graylog, logstash, sentry, ...) :-(

I do not know any of them - but I doubt that they will help you much to
untangle your "soup".

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