Question about import

[Frank Millman]

Hi all

My project comprises a number of modules, split into packages. Modules 
frequently need to access the contents of other modules, in the same or in a 
different package. I am getting better at it, but I still occasionally bump 
my head against circular imports, and have to fiddle around until it settles 
down again. Not ideal, I know.


I have just noticed something odd, and I wondered if it might provide a 
solution, or if it is a dangerous sidetrack. Here is a simple example -


/test
| start.py
 /a
 | aa.py
 /b
 | bb.py

start.py
   import a.aa
   import b.bb
   a.aa.aaa()
   b.bb.bbb()

aa.py
   import b
   def aaa():
   print('in aaa')
   b.bb.()
   def ():
   print('in ')

bb.py
   import a
   def bbb():
   print('in bbb')
   a.aa.()
   def ():
   print('in ')

c:\test>start.py
in aaa
in 
in bbb
in 

The surprising thing is that, within aa.py, I just have to say 'import b', 
and I can access 'b.bb.', and the same applies to 'bb.py'.


That makes me wonder if, in my project, I can import all modules inside 
'start.py', and then just use 'import package_name' inside each module?


Another question - I thought that, because aa.py and bb.py are in different 
sub-directories, I would have to set them up as packages by adding 
'__init__.py' to each one, but it works fine without that. What am I 
missing?


I am using python 3.4.

Any comments appreciated.

Frank Millman


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

Re: Python handles globals badly.

[Antoon Pardon]

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?

-- 
Antoon Pardon


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

Re: Silly question about pip

[breamoreboy]

On Wednesday, September 9, 2015 at 10:06:31 AM UTC+1, wxjm...@gmail.com wrote:
> Le mardi 8 septembre 2015 21:02:31 UTC+2, wxjm...@gmail.com a écrit :
> > Le mardi 8 septembre 2015 20:18:20 UTC+2, Irmen de Jong a écrit :
> > > On 8-9-2015 17:54, wxjmfa...@gmail.com wrote:
> > > > win7 / py433
> > > > 
> > > > How to downgrade from the latest pip (7.1.2) to
> > > > the previous one?
> > > > I'm sorry, I do not remember the numerous msgs
> > > > I saw when updating. (Yesterday)
> > > > 
> > > > (I'm serious)
> > > > 
> > > > Now, what?
> > > > 
> > > 
> > > I think:
> > > 
> > > $ pip install --upgrade pip==7.0.0
> > > 
> > > 
> > > would do the trick, where you substitute the required version number for 
> > > 7.0.0.
> > > 
> > > 
> > > Irmen
> > 
> > Addendum (your question)
> > 
> > > pip install --upgrade pip
> > 
> > which probably selects the latest version
> 
> 
> ---
> > pip install --upgrade pip==6.0.8
> 
> is indeed a valid command
> except I'm seeing the same previous mess.

The minor snag is we're not seeing your mess.  However as I'm getting really 
good vibes from my crystal ball today, I'd guess that you're getting a known 
problem on Windows with a permissions error, but the pip upgrade has actually 
worked fine.  Am I close?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Marko Rauhamaa]

Antoon Pardon :

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

C is an extremely strong language. However, I also think they made some
slightly regrettable choices, some of which later standards have
alleviated. One of my main issues with C has been the intentional
confusion between arrays and pointers. Also, the type notation is
clearly inferior to that of Pascal.

The greatest blessing C has bestowed upon programmers is the void
pointer. While C++ programmers (among others) have built a ridiculous
cathedral (templates) to capture the same universal notion, C
programmers just shrug their shoulders and store the reference in a void
pointer variable.


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

numpy

[chenc...@inhand.com.cn]

hi:
   I have to use numpy package. My python runs on my embedded arm 
device. So, how do i cross compile numpy?

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

Re: Can't use Python Launcher on Windows after update to 3.5

[Tim Golden]

On 10/09/2015 00:52, Mark Lawrence wrote:
> I've installed 3.5 for all users so it's in C:\Program Files
> 
> From
> https://docs.python.org/3.5/using/windows.html#from-the-command-line it
> says "System-wide installations of Python 3.3 and later will put the
> launcher on your PATH. The launcher is compatible with all available
> versions of Python, so it does not matter which version is installed. To
> check that the launcher is available, execute the following command in
> Command Prompt:", but:-
> 
> C:\Users\Mark\Documents\MyPython>py -3.4
> 'py' is not recognized as an internal or external command,
> operable program or batch file.
> 
> Further running ftype shows nothing for Python, assoc just gives this
> .pyproj=VisualStudio.Launcher.pyproj.14.0.  Surely this is wrong?
> 
> Before I go to the bug tracker to raise an issue could somebody please
> confirm what I'm seeing, thanks.
> 

Well I've just installed 64-bit 3.5.0rc4 via the web installer (ie this:
https://www.python.org/ftp/python/3.5.0/python-3.5.0rc4-amd64-webinstall.exe)
onto a machine with 64-bit 3.4.2 already installed. I went for the
default install.

It all seems to be ok and py -3.4 --version gives  me "Python 3.4.2" as
expected. assoc/ftype both look ok. c:\windows\py.exe has the versions &
dates I expect.

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

textfile: copy between 2 keywords

[Gerald]

Hey,

is there a easy way to copy the content between 2 unique keywords in a .txt 
file?

example.txt

1, 2, 3, 4
#keyword1
3, 4, 5, 6
2, 3, 4, 5
#keyword2 
4, 5, 6 ,7


Thank you very much


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

Re: textfile: copy between 2 keywords

[Steven D'Aprano]

On Thu, 10 Sep 2015 09:18 pm, Gerald wrote:

> Hey,
> 
> is there a easy way to copy the content between 2 unique keywords in a
> .txt file?
> 
> example.txt
> 
> 1, 2, 3, 4
> #keyword1
> 3, 4, 5, 6
> 2, 3, 4, 5
> #keyword2
> 4, 5, 6 ,7
> 
> 
> Thank you very much


Copy in what sense? Write to another file, or just copy to memory?

Either way, your solution will look something like this:

* read each line from the input file, until you reach the first keyword;
* as soon as you see the first keyword, change to "copy mode" and start
copying lines in whatever way you feel is best;
* until you see the second keyword, then stop.


E.g.

with open("input.txt") as f:
# Skip lines as fast as possible.
for line in f:
if line == "START\n":
break
# Instead of copying, I'll just print the lines. That's sort of a copy.
for line in f:  # This will pick up where the previous for loop ended.
if line == "STOP\n":
break
print(line)
# If you like, you can just finish now.
# Or, we can read the rest of the lines.
for line in f:  # continue from just after the STOP keyword.
pass  # This is a waste of time...
print("Done!")



-- 
Steven

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

Re: Python handles globals badly.

[Steven D'Aprano]

On Thu, 10 Sep 2015 05:18 am, Chris Angelico wrote:

> On Thu, Sep 10, 2015 at 5:14 AM, Laura Creighton  wrote:
>> In a message of Thu, 10 Sep 2015 05:00:22 +1000, Chris Angelico writes:
>>>To get started, you need some other sort of kick.
>>
>> Having Brian Kernighan write a really nice book about you, helps a lot.
> 
> It kinda does. And of course, it also helps to have a time machine, so
> you can launch your language when there are less languages around.
> Today, you compete for attention with myriad languages that simply
> didn't exist when C was introduced to an unsuspecting world.

I don't think that's quite right. I think, if anything, there were more
languages in the 1970s than now, it's just that they tended to be
proprietary, maybe only running on a single vendor's machine. But even if
I'm mistaken, I think that there is near-universal agreement that the
single biggest factor in C's popularity and growth during the 1970s and 80s
is that it was tied so intimately to Unix, and Unix was taking over from
mainframes, VAX, etc.



-- 
Steven

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

Re: Python handles globals badly.

[Steven D'Aprano]

On Thu, 10 Sep 2015 04:23 am, Emile van Sebille wrote:

> On 9/9/2015 10:55 AM, Steven D'Aprano wrote:
> 
>> (I wanted to link to the "Everything Is Broken" essay on The Medium, but
>> the page appears to be gone.
> 
> Is this it?
> http://www.sott.net/article/280956-Everything-is-broken-on-the-Internet

Looks like that's a mirror of the original, which is the one Laura found:

https://medium.com/message/everything-is-broken-81e5f33a24e1


Thanks guys. I don't know why I couldn't get to it earlier.



-- 
Steven

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

Re: textfile: copy between 2 keywords

[Jussi Piitulainen]

Gerald writes:

> Hey,
>
> is there a easy way to copy the content between 2 unique keywords in a
> .txt file?
>
> example.txt
>
> 1, 2, 3, 4
> #keyword1
> 3, 4, 5, 6
> 2, 3, 4, 5
> #keyword2 
> 4, 5, 6 ,7

Depending on your notion of easy, you may or may not like itertools.
The following code gets you the first keyword and the lines between but
consumes the second keyword. If I needed more control, I'd probably
write what Steven D'Aprano wrote but as a generator function, to get the
flexibility of deciding separately what kind of copy I want in the end.

And I'd be anxious about the possibility that the second keyword is not
there in the input at all. Steven's code and mine simply take every line
after the first keyword in that case. Worth a comment in the code, if
not an exception. Depends.

Code:

from itertools import dropwhile, takewhile
from sys import stdin

def notbeg(line): return line != '#keyword1\n'
def notend(line): return line != '#keyword2 \n' # sic!

if __name__ == '__main__':
print(list(takewhile(notend, dropwhile(notbeg, stdin

Output with your original mail as input in stdin:

['#keyword1\n', '3, 4, 5, 6\n', '2, 3, 4, 5\n']
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about import

[Ian Kelly]

On Thu, Sep 10, 2015 at 1:12 AM, Frank Millman  wrote:
> That makes me wonder if, in my project, I can import all modules inside
> 'start.py', and then just use 'import package_name' inside each module?

You can, but for readability and reuse I think it's better to be
explicit in each module and import the fully qualified module names
that are needed, rather than relying on some other module to import
them for you.

> Another question - I thought that, because aa.py and bb.py are in different
> sub-directories, I would have to set them up as packages by adding
> '__init__.py' to each one, but it works fine without that. What am I
> missing?

That surprises me also, but I suspect it's because they're
subdirectories of the current working directory rather than packages
found on the sys.path.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[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();

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.

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

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

Re: textfile: copy between 2 keywords

[Vlastimil Brom]

2015-09-10 13:18 GMT+02:00 Gerald :
> Hey,
>
> is there a easy way to copy the content between 2 unique keywords in a .txt 
> file?
>
> example.txt
>
> 1, 2, 3, 4
> #keyword1
> 3, 4, 5, 6
> 2, 3, 4, 5
> #keyword2
> 4, 5, 6 ,7
>
>
> Thank you very much

Hi,
just to add another possible approach, you can use regular expression
search for this task, e.g.
(after you have read the text content to an input string):

>>> import re
>>> input_txt ="""1, 2, 3, 4
... #keyword1
... 3, 4, 5, 6
... 2, 3, 4, 5
... #keyword2
... 4, 5, 6 ,7"""
>>> re.findall(r"(?s)(#keyword1)(.*?)(#keyword2)", input_txt)
[('#keyword1', '\n3, 4, 5, 6\n2, 3, 4, 5\n', '#keyword2')]
>>>

like in the other approaches, you might need to specify the details
for specific cases (no keywords, only one of them, repeated keywords
(possible in different order, overlapping or "crossed"), handling of
newlines etc.

hth,
   vbr
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about import

[Peter Otten]

Ian Kelly wrote:

> On Thu, Sep 10, 2015 at 1:12 AM, Frank Millman  wrote:
>> That makes me wonder if, in my project, I can import all modules inside
>> 'start.py', and then just use 'import package_name' inside each module?
> 
> You can, but for readability and reuse I think it's better to be
> explicit in each module and import the fully qualified module names
> that are needed, rather than relying on some other module to import
> them for you.
> 
>> Another question - I thought that, because aa.py and bb.py are in
>> different sub-directories, I would have to set them up as packages by
>> adding '__init__.py' to each one, but it works fine without that. What am
>> I missing?
> 
> That surprises me also, but I suspect it's because they're
> subdirectories of the current working directory rather than packages
> found on the sys.path.

So even the experts cannot keep up with all those nifty new features:

https://www.python.org/dev/peps/pep-0420/ (Implicit Namespace Packages)

I'm waiting to see the language collapse under all its nice and -- seen in 
isolation -- incredibly useful additions. 

C++ we're coming :(

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

Re: Python handles globals badly.

[jkn]

On Thursday, 10 September 2015 13:18:39 UTC+1, Steven D'Aprano  wrote:
> On Thu, 10 Sep 2015 05:18 am, Chris Angelico wrote:
> 
> > On Thu, Sep 10, 2015 at 5:14 AM, Laura Creighton  wrote:
> >> In a message of Thu, 10 Sep 2015 05:00:22 +1000, Chris Angelico writes:
> >>>To get started, you need some other sort of kick.
> >>
> >> Having Brian Kernighan write a really nice book about you, helps a lot.
> > 
> > It kinda does. And of course, it also helps to have a time machine, so
> > you can launch your language when there are less languages around.
> > Today, you compete for attention with myriad languages that simply
> > didn't exist when C was introduced to an unsuspecting world.
> 
> I don't think that's quite right. I think, if anything, there were more
> languages in the 1970s than now, it's just that they tended to be
> proprietary, maybe only running on a single vendor's machine. But even if
> I'm mistaken, I think that there is near-universal agreement that the
> single biggest factor in C's popularity and growth during the 1970s and 80s
> is that it was tied so intimately to Unix, and Unix was taking over from
> mainframes, VAX, etc.
> 
> 
> 
> -- 
> Steven

In 'The Design and Evolution of C++', Bjarne Stroustrup writes about a 
principle that was applied to C with classes (an early embodiment of C++):

"C with Classes has to be a weed like C or Fortran because we cannot afford to
take care of a rose like Algol68 or Simula. If we deliver an implementation and
go away for a year, we want to find several systems running when we come back.
That will not happen if complicated maintenance is needed or if a simple port
to a new machine takes longer than a week". (pp. 37)

I think the 'C is a weed' observation one is a good one to explain the
proliferation. I say this as a good thing, and as a programmer in C, C++ and 
Python.

Jon N



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

Re: Question about import

[Ian Kelly]

On Thu, Sep 10, 2015 at 8:47 AM, Peter Otten <__pete...@web.de> wrote:
> Ian Kelly wrote:
>> That surprises me also, but I suspect it's because they're
>> subdirectories of the current working directory rather than packages
>> found on the sys.path.
>
> So even the experts cannot keep up with all those nifty new features:
>
> https://www.python.org/dev/peps/pep-0420/ (Implicit Namespace Packages)

I've seen that before, but forgot about it. I wouldn't call myself an
expert, though; I haven't been using Python regularly for the past
couple of years, so I am getting a bit rusty.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: textfile: copy between 2 keywords

[Jussi Piitulainen]

Vlastimil Brom writes:

> just to add another possible approach, you can use regular expression

Now you have three problems: whatever the two problems are that you are
alleged to have whenever you decide to use regular expressions for
anything at all, plus all the people piling on you to tell that a Jamie
Zawinski once said that whenever you decide to use regular expressions
to solve a problem, you end up with two problems.

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

Re: Python handles globals badly.

[Steven D'Aprano]

On Thu, 10 Sep 2015 04:26 am, Sven R. Kunze wrote:

> Just to understand it the way you want it to be understood: what do you
> mean by "technical excellence"?

That's one of those things that are difficult to define precisely. All I can
do is give some partial examples, and counter-examples.

Lisp embodies a form of mathematical elegance and simplicity that one might
call technical excellence. Forth does too, despite their completely
different syntax and computational model.

BASIC does not.

ML's type-checker displays technical excellence:

http://perl.plover.com/yak/typing/notes.html

Haskell, which inherits the same sort of type-checker, does too.

Inform 7's natural language syntax and inference engine displays technical
excellence. APL's mathematics syntax does not, as it doesn't even follow
the same rules that mathematicians expect. (APL, I'm lead to believe, is
evaluated purely from left-to-right -- or was it right to left? -- so that
1+2*3 gives 9 rather than 7 like mathematicians expect.)

Credit where credit is due: although I think that in the broader computing
ecosystem it does more harm than good, the efforts put into optimization by
C compilers show technical excellence. If there's a cycle that can be
shaved, good C compilers like gcc and clang will find it.

It's hard (impossible?) to think of a language that gets *everything* right,
because so much of that depends on subjective factors, but I think that
languages can display technical excellence in a particular subset of
features. It's not "all or nothing" -- a language can be excellent in one
area, and poor in another.


[...]
>> (I wanted to link to the "Everything Is Broken" essay on The Medium, but
>> the page appears to be gone. This makes me sad. BTW, what's the point of
>> Google's cache when it just redirects to the original, missing, page?)
>
> Do you mean https://medium.com/message/everything-is-broken-81e5f33a24e1 ?

Yes, that's the one, thanks.



-- 
Steven

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

Re: Can't use Python Launcher on Windows after update to 3.5

[Mark Lawrence]

On 10/09/2015 11:20, Tim Golden wrote:

On 10/09/2015 00:52, Mark Lawrence wrote:

I've installed 3.5 for all users so it's in C:\Program Files

From
https://docs.python.org/3.5/using/windows.html#from-the-command-line it
says "System-wide installations of Python 3.3 and later will put the
launcher on your PATH. The launcher is compatible with all available
versions of Python, so it does not matter which version is installed. To
check that the launcher is available, execute the following command in
Command Prompt:", but:-

C:\Users\Mark\Documents\MyPython>py -3.4
'py' is not recognized as an internal or external command,
operable program or batch file.

Further running ftype shows nothing for Python, assoc just gives this
.pyproj=VisualStudio.Launcher.pyproj.14.0.  Surely this is wrong?

Before I go to the bug tracker to raise an issue could somebody please
confirm what I'm seeing, thanks.



Well I've just installed 64-bit 3.5.0rc4 via the web installer (ie this:
https://www.python.org/ftp/python/3.5.0/python-3.5.0rc4-amd64-webinstall.exe)
onto a machine with 64-bit 3.4.2 already installed. I went for the
default install.

It all seems to be ok and py -3.4 --version gives  me "Python 3.4.2" as
expected. assoc/ftype both look ok. c:\windows\py.exe has the versions &
dates I expect.

TJG



So I ran the 64-bit 3.5.0rc4 via the web installer and still no joy. 
Ran repair with same and it's business as usual.  I'm not that bothered, 
it's here for the record should anybody else come searching, so chalk it 
up to experience and move on.  Thanks anyway :)


--
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: RPI.GPIO Help

[John McKenzie]

 MRAB:

 Thanks for replying. I got so hyper focused on solving my hardware 
problems, and excited that I did, that I forgot details from previous 
comments. Thanks for your post.

 Off to make things global...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Steven D'Aprano]

On Thu, 10 Sep 2015 04:59 am, random...@fastmail.us wrote:

> On Wed, Sep 9, 2015, at 13:55, Steven D'Aprano wrote:
>> 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?
> 
> Whoa, hold on. The problem with C assignment isn't that it's an
> expression, it's that it's spelled "=" and can be used in contexts where
> one would normally do an equality comparison.

Yes, that's what I'm referring to.

Although, I'm not sure that I agree with the idea that "everything is an
expression". I think that's a category mistake, like asking for the speed
of dark[1], or for a bucket of cold. Some things are functional by nature,
and other things are imperative; some may be both, but I don't think that
assignment is one. I think that assignment is imperative, not functional,
and forcing it to return a value is artificial.


> In some languages (Lisp/Scheme/etc come to mind), *everything* is an
> expression. But assignment is spelled with, generally, some variant of
> "set" [setq, set!, etc].

Yes, that at least avoids the possibility of mistaking = for == or similar.



[1] Obviously it's faster than light, since wherever the light arrives, it
finds the dark got there first.


-- 
Steven

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

Re: numpy

[Laura Creighton]

In a message of Thu, 10 Sep 2015 18:11:08 +0800, "chenc...@inhand.com.cn" write
s:
>hi:
>I have to use numpy package. My python runs on my embedded arm 
>device. So, how do i cross compile numpy?
>-- 
>https://mail.python.org/mailman/listinfo/python-list

Ask that one here:
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Do you even have a floating point processor?  I'm not an
expert but I don't think that it makes sense to try to run
numpy anywhere that doesn't have one.

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

Re: Python handles globals badly.

[random832]

On Thu, Sep 10, 2015, at 11:59, Steven D'Aprano wrote:
> Although, I'm not sure that I agree with the idea that "everything is an
> expression". I think that's a category mistake, like asking for the speed
> of dark[1], or for a bucket of cold. Some things are functional by
> nature,
> and other things are imperative; some may be both, but I don't think that
> assignment is one. I think that assignment is imperative, not functional,
> and forcing it to return a value is artificial.

Why shouldn't imperative things be expressions? Why should all
expressions return a value?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Fri, Sep 11, 2015 at 2:31 AM,   wrote:
> On Thu, Sep 10, 2015, at 11:59, Steven D'Aprano wrote:
>> Although, I'm not sure that I agree with the idea that "everything is an
>> expression". I think that's a category mistake, like asking for the speed
>> of dark[1], or for a bucket of cold. Some things are functional by
>> nature,
>> and other things are imperative; some may be both, but I don't think that
>> assignment is one. I think that assignment is imperative, not functional,
>> and forcing it to return a value is artificial.
>
> Why shouldn't imperative things be expressions? Why should all
> expressions return a value?

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:

but the trouble is that you can check for falsiness, but nothing else.
(In C, EOF is an integer outside the range 0..255, such that it's
distinct from any byte value. It's usually -1.) If assignment is an
expression, you can capture a value and keep going - something like
this:

stash = [None]
while (stash.__setitem__(0, getchar()) or stash[0]) != -1:
ch = stash[0]

It's ugly, but it does work - because the setitem call is an
expression. However, for this to succeed, the expression MUST yield a
value. Otherwise it doesn't make sense, and the difference between
expression and statement is a purely technical/theoretical one. (In
this case, the value of the "assignment" expression is always None,
which is less useful than C's policy of returning the value itself;
but at least I know what it's going to be, so I can use the "or
stash[0]" notation.)

Having assignment be a statement (and therefore illegal in a loop
condition) makes sense. Having it be an expression that yields a
useful or predictable value makes sense. Having it be an expression,
but not returning a value, doesn't.

(I'm not going to get into the argument here about whether assignment
SHOULD be a statement or an expression. There are plenty of languages
to choose from, so you can have it both ways if you like.)

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

Re: textfile: copy between 2 keywords

[Christian Gollwitzer]

Am 10.09.15 um 13:18 schrieb Gerald:

Hey,

is there a easy way to copy the content between 2 unique keywords in a .txt 
file?

example.txt

1, 2, 3, 4
#keyword1
3, 4, 5, 6
2, 3, 4, 5
#keyword2
4, 5, 6 ,7


If "copying" does mean copy it to another file, and you are not obliged 
to use Python, this is unmatched in awk:


Apfelkiste:Tests chris$ cat kw.txt
1, 2, 3, 4
#keyword1
3, 4, 5, 6
2, 3, 4, 5
#keyword2
4, 5, 6 ,7
Apfelkiste:Tests chris$ awk '/keyword1/,/keyword2/' kw.txt
#keyword1
3, 4, 5, 6
2, 3, 4, 5
#keyword2

Consequently, awk '/keyword1/,/keyword2/' kw.txt  > kw_copy.txt

would write it out to kw_copy.txt

Beware that between the two slashes there are regexps, so if you have 
metacharacters in your keywords, you need to quote them.


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

Context-aware return

[Steven D'Aprano]

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?




-- 
Steven

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

Re: Context-aware return

[Sven R. Kunze]

http://stackoverflow.com/questions/2356399/tell-if-python-is-in-interactive-mode


On 10.09.2015 19: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?


Probably. ;)

But it it solve a problem, why not.


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

Re: Context-aware return

[Ben Finney]

Steven D'Aprano  writes:

> 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.
> […]
>
> 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?

That makes my skin creep. In the name of all the tea I've sacrificed to
Python over the years, I pray this isn't possible.

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

First thing in the morning I will purchase a head of cabbage and store
it in a warm place to make it rot, on the off chance you find some
obscure way to achieve your benighted goal, just so I can be first in
line to throw it as you pass.

If ever I have to worry that some arbitrary Python function, unbenownst
to me, might have a branch that will make it behave differently
depending on *whether I bind a reference to its return value*, then I'll
know you are sent to us as an evil spirit to make all software suck.

-- 
 \   “Nothing exists except atoms and empty space; everything else |
  `\  is opinion.” —Democritus |
_o__)  |
Ben Finney

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

Re: Python handles globals badly.

[Steven D'Aprano]

On Fri, 11 Sep 2015 02:31 am, random...@fastmail.us wrote:

> On Thu, Sep 10, 2015, at 11:59, Steven D'Aprano wrote:
>> Although, I'm not sure that I agree with the idea that "everything is an
>> expression". I think that's a category mistake, like asking for the speed
>> of dark[1], or for a bucket of cold. Some things are functional by
>> nature,
>> and other things are imperative; some may be both, but I don't think that
>> assignment is one. I think that assignment is imperative, not functional,
>> and forcing it to return a value is artificial.
> 
> Why shouldn't imperative things be expressions?

Sometimes they might be. But in general, I think it is meaningless to expect
a imperative command to have a return result. The whole point of an
imperative command is that it operates by side-effect.

For example, what would `del x` return if it were an expression instead of a
statement? I can think of two reasonable alternatives, but both feel a bit
wrong to me.

(1) Return True if x was successfully unbound, False if it wasn't. Except
that raising an exception seems more Pythonic, in which case returning True
seems redundant. It will *always* return True, unless there's an exception.
So why bother? We only bother because there's no way to *not* return a
result if "everything is an expression".

(2) Return None, like functions do by default. But again, it only returns
None, not because None is a meaningful thing to return, but because we
don't actually have a way to say "it doesn't return anything".

Or os.abort. The docs for that say:

Help on built-in function abort in module posix:

abort(...)
abort() -> does not return!

Abort the interpreter immediately.  This 'dumps core' or otherwise fails
in the hardest way possible on the hosting operating system.


So, what would os.abort() return, if everything is an expression?

Obviously one can always find some arbitrary value for expressions to
return, in order to keep the invariant "all expressions return something".
But I dislike the arbitrariness of it. Some things aren't conceptually
functional expressions, they're imperative commands that (like Pascal
procedures, or Python statements) don't naturally have a return result.



> Why should all expressions return a value?

Because that's the definition of an expression in this context. An
expression is evaluated to either return a result, or raise an exception.



-- 
Steven

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

Re: Context-aware return

[Ben Finney]

"Sven R. Kunze"  writes:

> http://stackoverflow.com/questions/2356399/tell-if-python-is-in-interactive-mode

I'm pretty sure Steven knows full well the answer to that question,
which is not anything like the one he asked. Would you care to read the
question he did ask?

-- 
 \   “The optimist thinks this is the best of all possible worlds. |
  `\   The pessimist fears it is true.” —J. Robert Oppenheimer |
_o__)  |
Ben Finney

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

Re: Context-aware return

[Sven R. Kunze]

I need to add: you need to look up the stack to see if you have been 
called by __main__ and if __main__.__file__ is missing.


Implementation: I would write decorator for your func.

Best,
Sven

PS: did I say it would probably be a bad idea? If not, it would probably 
be a bad idea.


PPS: what is the reason for this special behavior?

On 10.09.2015 20:03, Sven R. Kunze wrote:
http://stackoverflow.com/questions/2356399/tell-if-python-is-in-interactive-mode 




On 10.09.2015 19: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?


Probably. ;)

But it it solve a problem, why not.


Best,
Sven


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

Signal SIGINT ignored during socket.accept

[James Harris]

I have a listening socket, self.lsock, which is used in an accept() call 
as follows


 endpoint = self.lsock.accept()

The problem is that if control-C is pressed it is not recognised until 
something connects to that socket. Only when the accept() call returns 
is the signal seen.


The question, then, is how to get the signal to break out of the 
accept() call. This is currently on Windows but I would like it to run 
on Unix too. I see from the web that this type of thing is a common 
problem with the underlying C libraries but I cannot quite relate the 
posts I have found to Python.


Any ideas?

James

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

Re: Context-aware return

[Sven R. Kunze]

On 10.09.2015 20:12, Ben Finney wrote:

First thing in the morning I will purchase a head of cabbage and store
it in a warm place to make it rot, on the off chance you find some
obscure way to achieve your benighted goal, just so I can be first in
line to throw it as you pass.


Well, go ahead. And make photos!

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

Re: Context-aware return

[Sven R. Kunze]

On 10.09.2015 20:14, Ben Finney wrote:

"Sven R. Kunze"  writes:


http://stackoverflow.com/questions/2356399/tell-if-python-is-in-interactive-mode

I'm pretty sure Steven knows full well the answer to that question,
which is not anything like the one he asked. Would you care to read the
question he did ask?

You are right. I turned out to me harder that I first thought.

My initial guess was like: use AST. But now I see, it would be hard to 
get the source code.


So, what actually could work, would be faking the interactive 
interpreter wrapping it up and thus have control over the source code 
typed in.


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

Re: Signal SIGINT ignored during socket.accept

[Chris Angelico]

On Fri, Sep 11, 2015 at 4:24 AM, James Harris  wrote:
> I have a listening socket, self.lsock, which is used in an accept() call as
> follows
>
>  endpoint = self.lsock.accept()
>
> The problem is that if control-C is pressed it is not recognised until
> something connects to that socket. Only when the accept() call returns is
> the signal seen.
>
> The question, then, is how to get the signal to break out of the accept()
> call. This is currently on Windows but I would like it to run on Unix too. I
> see from the web that this type of thing is a common problem with the
> underlying C libraries but I cannot quite relate the posts I have found to
> Python.

What version of Python are you using? Also (in case it matters), what
version of Windows?

Have you tested on any Unix system? I just tried on my Linux, and
Ctrl-C interrupted the accept() straight away, so this is quite
probably a Windows-only issue.

Can you produce an absolute minimal demo program? I'd try something like this:

import socket
s = socket.socket()
s.listen(1)
s.accept()

which is what worked for me (interactively, Python 2.7.9 and 3.6.0a0,
Debian Linux).

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

Re: Python handles globals badly.

[Chris Angelico]

On Fri, Sep 11, 2015 at 4:13 AM, Steven D'Aprano  wrote:
> Sometimes they might be. But in general, I think it is meaningless to expect
> a imperative command to have a return result. The whole point of an
> imperative command is that it operates by side-effect.
>
> For example, what would `del x` return if it were an expression instead of a
> statement? I can think of two reasonable alternatives, but both feel a bit
> wrong to me.
>
> (1) Return True if x was successfully unbound, False if it wasn't. Except
> that raising an exception seems more Pythonic, in which case returning True
> seems redundant. It will *always* return True, unless there's an exception.
> So why bother? We only bother because there's no way to *not* return a
> result if "everything is an expression".
>
> (2) Return None, like functions do by default. But again, it only returns
> None, not because None is a meaningful thing to return, but because we
> don't actually have a way to say "it doesn't return anything".

Yes, or: (3) Return the old value that x contained, the way dict.pop()
does. That makes it a "destructive retrieval" rather than simply a
destruction operation.

> Or os.abort. The docs for that say:
>
> Help on built-in function abort in module posix:
>
> abort(...)
> abort() -> does not return!
>
> Abort the interpreter immediately.  This 'dumps core' or otherwise fails
> in the hardest way possible on the hosting operating system.
>
>
> So, what would os.abort() return, if everything is an expression?

Since this is in the os module, and is thus a thin wrapper around
lower-level operations, I could imagine it returning an error code
(the way the C-level exec functions do - if they succeed, they don't
return, but if they fail, they return an error number); in Python,
it'd be best to have it either abort the process (and thus not
return), or raise an exception (and thus not return).

But abort functions are a rarity. It's not a problem to have a rule
"all functions must return something" (as Python does), and then have
functions that never actually use the normal return path:

def raise_(exc): raise exc
raise_stopiteration = iter([]).__next__
raise_typeerror = lambda: ""()

Calling one of these functions is *syntactically* an expression, but
at run time, it'll never actually get as far as producing a value. If
it's at all possible for the operation to, based on run-time
information, NOT abort, then it absolutely has to be able to return.

> Because that's the definition of an expression in this context. An
> expression is evaluated to either return a result, or raise an exception.

I'd define it more simply: An expression always produces a result.
It's possible that, during the evaluation of an expression, an
exception will be raised; if that happens, evaluation stops. Doesn't
matter whether the expression itself caused that, or if an OS-level
signal did (eg triggering KeyboardInterrupt), or if the expression was
"yield 1" and an exception got thrown in. But yes, an expression is
something that generates a result; a statement isn't.

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

Re: Context-aware return

[Chris Angelico]

On Fri, Sep 11, 2015 at 3:54 AM, Steven D'Aprano  wrote:
> 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.

The first thing that comes to mind is a repr hack. If you make your
function return an int-like object with a different repr, it could
look like it's returning "Awesome" interactively. The usefulness of
that depends on what the two forms are you're trying to return,
though.

Advantage: Doesn't get Ben's cabbage. I think.

Disadvantage: Looks weird if you try to debug stuff and get the repr
staring back at you.

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

Re: Context-aware return

[Laura Creighton]

In a message of Fri, 11 Sep 2015 03:54:14 +1000, "Steven D'Aprano" writes:

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

Why, why, why do you want such a horrid thing?
I have an function that isn't always doing what I want.
I make a reference to it, so I can print it from time to time,
and do some other things to try to see why sometimes I am getting
an unwanted result.

I can no longer debug my problem.
You are seriously proposing this?

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

I might start ahead of time, just for thinking of it ...

There has got to be a better way to get what you want -- or perhaps
for you to want something saner.

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

Re: Context-aware return

[Sven R. Kunze]

On 10.09.2015 20:34, Sven R. Kunze wrote:

You are right. I turned out to me harder that I first thought.

My initial guess was like: use AST. But now I see, it would be hard to 
get the source code.


So, what actually could work, would be faking the interactive 
interpreter wrapping it up and thus have control over the source code 
typed in.


Ha, got it:  sys.settrace

>>> def traceit(frame, event, arg):
... return traceit

>>> sys.settrace(traceit)

>>> a=1
(, 'call', None)
(, 'line', None)
(, 'return', (u'a=1\n', 4))
(, 'call', None)
(, 'line', None)
(, 'return', None)


There you got the source. The use an AST to find out whether the line 
fits your definition of 'interactive'.


That should only be necessary when the top frame is interactive.


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

Re: Context-aware return

[Sven R. Kunze]

Oops, missing print:

On 10.09.2015 20:45, Sven R. Kunze wrote:

On 10.09.2015 20:34, Sven R. Kunze wrote:

You are right. I turned out to me harder that I first thought.

My initial guess was like: use AST. But now I see, it would be hard 
to get the source code.


So, what actually could work, would be faking the interactive 
interpreter wrapping it up and thus have control over the source code 
typed in.


Ha, got it:  sys.settrace

>>> def traceit(frame, event, arg):

...print(frame, event, arg)

... return traceit

>>> sys.settrace(traceit)

>>> a=1
(, 'call', None)
(, 'line', None)
(, 'return', (u'a=1\n', 4))
(, 'call', None)
(, 'line', None)
(, 'return', None)


There you got the source. The use an AST to find out whether the line 
fits your definition of 'interactive'.


That should only be necessary when the top frame is interactive.


Best,
Sven


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

Re: Python handles globals badly.

[rurpy--- via Python-list]

On Thursday, September 10, 2015 at 6:18:39 AM UTC-6, Steven D'Aprano wrote:
> On Thu, 10 Sep 2015 05:18 am, Chris Angelico wrote:
> > On Thu, Sep 10, 2015 at 5:14 AM, Laura Creighton  wrote:
> >> In a message of Thu, 10 Sep 2015 05:00:22 +1000, Chris Angelico writes:
> >>>To get started, you need some other sort of kick.
> >>
> >> Having Brian Kernighan write a really nice book about you, helps a lot.
> > 
> > It kinda does. And of course, it also helps to have a time machine, so
> > you can launch your language when there are less languages around.
> > Today, you compete for attention with myriad languages that simply
> > didn't exist when C was introduced to an unsuspecting world.
> 
> I don't think that's quite right. I think, if anything, there were more
> languages in the 1970s than now, it's just that they tended to be
> proprietary, maybe only running on a single vendor's machine. But even if
> I'm mistaken, I think that there is near-universal agreement that the
> single biggest factor in C's popularity and growth during the 1970s and 80s
> is that it was tied so intimately to Unix, and Unix was taking over from
> mainframes, VAX, etc.

The growth of C and Unix were mutually interdependent, one was not 
the cause of the other.

A big factor in the growth of Unix was that it was portable to 
new hardware relatively easily, a portability made possible by C.

I note that even today, 3 or 4 decades later, the availability of 
Python on a wide variety of platforms is made possible by C.

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Signal SIGINT ignored during socket.accept

[James Harris]

"Chris Angelico"  wrote in message 
news:mailman.332.1441910212.8327.python-l...@python.org...
On Fri, Sep 11, 2015 at 4:24 AM, James Harris 
 wrote:


I have a listening socket, self.lsock, which is used in an accept() 
call as

follows

 endpoint = self.lsock.accept()

The problem is that if control-C is pressed it is not recognised 
until
something connects to that socket. Only when the accept() call 
returns is

the signal seen.

The question, then, is how to get the signal to break out of the 
accept()
call. This is currently on Windows but I would like it to run on Unix 
too. I

see from the web that this type of thing is a common problem with the
underlying C libraries but I cannot quite relate the posts I have 
found to

Python.


What version of Python are you using? Also (in case it matters), what
version of Windows?


Good point. It turns out that it does matter. I have one implementation 
which fails (Windows) and one which works (Linux). The Linux one breaks 
out on Control-C. The Windows one does not recognise Control-C until the 
accept() call returns.


The implementations are:

$ uname -srm
Linux 3.18.7-v7+ armv7l
$ python -V
Python 2.7.3

And

c:\>ver
Microsoft Windows XP [Version 5.1.2600]
c:\>python -V
Python 2.7.9


Have you tested on any Unix system? I just tried on my Linux, and
Ctrl-C interrupted the accept() straight away,


Thanks.


so this is quite probably a Windows-only issue.


That turns out to be exactly right.

Can you produce an absolute minimal demo program? I'd try something 
like this:


import socket
s = socket.socket()
s.listen(1)
s.accept()


Yes:

port = 8880
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(("", port))
s.listen(1)
endpoint = s.accept()


which is what worked for me (interactively, Python 2.7.9 and 3.6.0a0,
Debian Linux).


On Linux I get

$ python socktest.py
^CTraceback (most recent call last):
 File "socktest.py", line 6, in 
   endpoint = s.accept()
 File "/usr/lib/python2.7/socket.py", line 202, in accept
   sock, addr = self._sock.accept()
KeyboardInterrupt
$

On Windows I get

S:\>python socktest.py
Traceback (most recent call last):
 File "socktest.py", line 6, in 
   endpoint = s.accept()
 File "C:\Python27\lib\socket.py", line 202, in accept
   sock, addr = self._sock.accept()
KeyboardInterrupt

S:\>

However, on Windows the recognition of Control-C does not happen until 
after something connects to the socket.


I will carry on researching it but maybe the above gives a clue to those 
in the know...!


James

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

Re: Python handles globals badly.

[Jussi Piitulainen]

Steven D'Aprano writes:

> Or os.abort. The docs for that say:
>
> Help on built-in function abort in module posix:
>
> abort(...)
> abort() -> does not return!
>
> Abort the interpreter immediately.  This 'dumps core' or otherwise
> fails in the hardest way possible on the hosting operating system.
>
>
> So, what would os.abort() return, if everything is an expression?

But os.abort() *is* an expression. It's allowed where only an expression
is valid syntax.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Context-aware return

[Paul Rubin]

Steven D'Aprano  writes:
> 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.

That sounds crazy but if it's really what you want, you can probably
fake it by examining the control stack using the backtrace module.  I
remember doing some hack of raising and catching an exception in order
to retrieve the backtrace, but there might be a cleaner way that I
didn't bother researching since it was just for a quick debugging
problem.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Context-aware return

[Grant Edwards]

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

-- 
Grant Edwards   grant.b.edwardsYow! FROZEN ENTREES may
  at   be flung by members of
  gmail.comopposing SWANSON SECTS ...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Signal SIGINT ignored during socket.accept

[Chris Angelico]

On Fri, Sep 11, 2015 at 5:11 AM, James Harris  wrote:
> S:\>python socktest.py
> Traceback (most recent call last):
>  File "socktest.py", line 6, in 
>endpoint = s.accept()
>  File "C:\Python27\lib\socket.py", line 202, in accept
>sock, addr = self._sock.accept()
> KeyboardInterrupt
>
> S:\>
>
> However, on Windows the recognition of Control-C does not happen until after
> something connects to the socket.
>
> I will carry on researching it but maybe the above gives a clue to those in
> the know...!

This is a known problem on Windows. I can't remember what the best
solution was, but there's a chance something got into 2.7.10, as it
was fairly recent. There's a significantly better chance that
something's different in Python 3.x. You may find it worth grabbing a
few different versions of Python and trying the same code on all of
them.

You may run into issues with XP, though. For instance, Python 3.5
doesn't support it, and (IIRC) won't install at all; 3.4 does work, as
will all releases of 2.7.x. Worst case, grab yourself a Windows 7 and
try a few tests.

But a quick test on one of my VMs, with 3.4 on Win 7, didn't show any
change. It's entirely possible that a blocking socket-accept call will
continue to block. There is one rather silly option, and that's to use
select() to effectively poll for Ctrl-C... or, possibly better, have a
separate program that shuts down your server (by connecting to it,
which thus breaks the stranglehold).

Of course, switching over to Unix is also a good option...

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

Re: textfile: copy between 2 keywords

[alister]

On Thu, 10 Sep 2015 12:11:55 -0700, wxjmfauth wrote:

 s = """1, 2, 3, 4
> ... #keyword1 ... 3, 4, 5, 6 ... 2, 3, 4, 5 ... #keyword2 ... 4, 5, 6
> ,7"""
 s[s.find('keyword1') + len('keyword1'):s.find('keyword2') - 1]
> '\n3, 4, 5, 6\n2, 3, 4, 5\n'
 #or s[s.find('keyword1') + len('keyword1') + 1:s.find('keyword2') -
 2]
> '3, 4, 5, 6\n2, 3, 4, 5'


split works well
as a simple 1 liner (well 2 if you include the string setup)

>>>a="crap word1 more crap word1 again word2 still more crap"

>>>a.split('word1',1)[1].split('word2')[0]

' more crap word1 again '



-- 
All bad precedents began as justifiable measures.
-- Gaius Julius Caesar, quoted in "The Conspiracy of
   Catiline", by Sallust
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[alister]

On Fri, 11 Sep 2015 01:59:27 +1000, Steven D'Aprano wrote:
> 
> Although, I'm not sure that I agree with the idea that "everything is an
> expression". I think that's a category mistake, like asking for the
> speed of dark[1], or for a bucket of cold. Some things are functional by
> nature, and other things are imperative; some may be both, but I don't
> think that assignment is one. I think that assignment is imperative, not
> functional, and forcing it to return a value is artificial.
> 
> 
> [1] Obviously it's faster than light, since wherever the light arrives,
> it finds the dark got there first.

Incorrect light is simply the absence of dark

https://astro.uni-bonn.de/~dfischer/dark_sucker_2.html

http://tristan.ethereal.net/humor/dark-suckers.html




-- 
Neutrinos have bad breadth.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[random832]

On Thu, Sep 10, 2015, at 12:48, Chris Angelico wrote:
> Having assignment be a statement (and therefore illegal in a loop
> condition) makes sense. Having it be an expression that yields a
> useful or predictable value makes sense. Having it be an expression,
> but not returning a value, doesn't.

Why not? Having it not return a value (and thus be illegal in places
that expect a value), but be legal in places like C's comma operator or
Lisp's progn that do not use the value, would make logical sense. Your
while loop could be written as something like "while (ch = getchar();
ch): ..."

The main purpose of this would be to prevent you from using it where a
boolean is expected, which wouldn't be necessary if Python hadn't
repeated C's mistake of spelling it "=".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Signal SIGINT ignored during socket.accept

[James Harris]

"Chris Angelico"  wrote in message 
news:mailman.337.1441913195.8327.python-l...@python.org...
On Fri, Sep 11, 2015 at 5:11 AM, James Harris 
 wrote:


...

However, on Windows the recognition of Control-C does not happen 
until after

something connects to the socket.


...


This is a known problem on Windows.


...


It's entirely possible that a blocking socket-accept call will
continue to block. There is one rather silly option, and that's to use
select() to effectively poll for Ctrl-C... or, possibly better, have a
separate program that shuts down your server (by connecting to it,
which thus breaks the stranglehold).


Thanks for your help, Chris. Using select() is a very good option. I 
tried first without a timeout and even then this version of Windows does 
not recognise Control-C until after the select() call returns (which 
needs similar prompting as with the accept() call. However, select() 
with a timeout allows the code to work both on Windows and Linux. 
Hooray!


For anyone else who is looking for this the earlier test code was 
changed to


port = 8880
import select
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setblocking(0)
s.bind(("", port))
s.listen(1)
while 1:
 ready = select.select((s,), (), (), 0.5)
 #print '(ready %s)' % repr(ready)
 if (ready[0]):
   try:
 endpoint = s.accept()
   except socket.error, details:
 print 'Ignoring socket error:', repr(details)
 continue
   print '(endpoint %s)' % repr(endpoint)
   if endpoint:
 break

James

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

Re: Context-aware return

[Akira Li]

Grant Edwards  writes:

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

There are cases when it might be justified to alter the behavior e.g.,
*colorama* allows to strip ANSI codes (e.g., disable colored output) if
stdout is not a tty or *win-unicode-console* make sys.stdout to use
WriteConsoleW() to write Unicode to Windows console (interactive case).

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

Re: Context-aware return

[Grant Edwards]

On 2015-09-10, Akira Li <4kir4...@gmail.com> wrote:
> Grant Edwards  writes:
>
>> 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. :)
>
> There are cases when it might be justified to alter the behavior e.g.,
> *colorama* allows to strip ANSI codes (e.g., disable colored output) if
> stdout is not a tty or *win-unicode-console* make sys.stdout to use
> WriteConsoleW() to write Unicode to Windows console (interactive case).

I hate that sort of behavior also, but there's a long historical
precident on Unix of command line utilities changing output format
based on the results of isatty(STDIN_FILENO).  IMO, that was
definitely a mistake, and to this day regularly wastes my time when
troubleshooting bash programs. But, it's been that way for 45 years,
and it's not going to get fixed now.  That sort of auto-magical
"trying to guess what the user wants" instead of doing what the user
says is what makes PHP smell so bad.  

A bad idea copied by thousand of people over several decades is still
a bad idea.

Let's not duplicate that mistake in Python.
   
But, just to clarify, we're talking about the function's return value,
not what it writes to stdout, right?

-- 
Grant Edwards   grant.b.edwardsYow! I would like to
  at   urinate in an OVULAR,
  gmail.comporcelain pool --
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[random832]

On Thu, Sep 10, 2015, at 14:13, Steven D'Aprano wrote:
> Because that's the definition of an expression in this context. An
> expression is evaluated to either return a result, or raise an exception.

Nonsense. An expression is something allowed within a larger expression.
It's easy to imagine an expression allowing a subexpression that does
not return a result. For example, in non-tail positions of something
like C-comma/Lisp-progn.

Or, for example, if a C-style "for" loop was an expression, the
initializer and increment bits.

This is semantics, to some extent - you could just as well say an
expression may "return" a "result" that is a special non-value which
transforms into an error if it's allowed to escape into a context where
the value is needed (e.g. the argument to a function, a place a boolean
is expected, being assigned to a variable) - C (and other C-family
languages) has such a thing, Lisp does not.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Context-aware return

[random832]

On Thu, Sep 10, 2015, at 16:15, Akira Li wrote:
> There are cases when it might be justified to alter the behavior e.g.,
> *colorama* allows to strip ANSI codes (e.g., disable colored output) if
> stdout is not a tty or *win-unicode-console* make sys.stdout to use
> WriteConsoleW() to write Unicode to Windows console (interactive case).

These conditions have nothing to do with whether it is running in the
interactive interpreter, since you can still be on the console (or a
tty) without being in the interactive interpreter. What you are talking
about is detecting file redirection.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Peter Pearson]

On Wed, 9 Sep 2015 20:20:42 +0100, Mark Lawrence wrote:
> On 09/09/2015 18:59, William Ray Wing wrote:
>>> On Sep 9, 2015, at 1:22 PM, Steven D'Aprano  wrote:
[snip]
>> Right.  Note that the Arabs, who DID invent zero, still count from one.
[snip]
> Would you please provide a citation to support your claim as this 
> http://www.livescience.com/27853-who-invented-zero.html disagrees.

That's baffling.  Livescience.com says this:

Robert Kaplan, author of "The Nothing That Is: A Natural History of
Zero," suggests that an ancestor to the placeholder zero may have
been a pair of angled wedges used to represent an empty number
column. However, Charles Seife, author of "Zero: The Biography of a
Dangerous Idea," disagrees that the wedges represented a
placeholder.

In that exact book, Seife says the exact opposite of the above allegation:

Zero was the solution to the problem.  By around 300 BC the
Babylonians had started using two slanted wedges, [graphics
omitted], to represent an empty space, an empty column on the
abacus.  This _placeholder_ [italics in original] mark made it easy
to tell which position a symbol was in.

Either Seife completely changed his mind after my copy of his book was
published (2000), or Livescience.com got it completely wrong.

-- 
To email me, substitute nowhere->runbox, invalid->com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[tdev]

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

It has been proposed to have these six enhancements

1. optional keyword "global"  
2. switch statement
3. less restrictive indentation 
4. universal scope 
5. goto label
6- "include" script statement


with following proofs uncommented:

Each sample provided would work without global 
(or you get runtime failure while try to write a global). 
So the compiler knows the distiction between global and local already. 
Otherwise you would have to write in every function this keyword 
But this is not the case.  You write it because you need write access.
And this is an over-regulation. So, NO need for an explicit global. 
Optional ok.


Another proof about identation:
The parser can recognise identation with tabs and spaces. 
Otherwise semcicolons or brackets would be needed.
It is correct that there have to be a decision for spaces or tabs.
But sure not necessarily the exact same indentation to the right for each block.
Jus more same inserter to the right and the context is clear.


Another proof is Python itself (from Tutorial):
"Python is an ... powerful programming language. It has ... and a simple but 
effective approach 
to object-oriented programming. Python's elegant syntax ... together with its 
interpreted nature, 
make it an ideal language for scripting ... .

The proposals are all made for structual programming enhancements 
This is nothing else than having structural programming, functional programming 
and OO
and many more features in parallel. Why that all?
For the same reason: 
For an another type of programmers - or say: nothing more than even more 
flexibility.

Read also here: https://en.wikipedia.org/wiki/History_of_Python
Especially sections: "incfluences from other languages"



But all proposals are more or less fully denied - for more or less no reasons.


The last statement against the proposals:
   
> "EVERYONE who suggests massive, sweeping changes says "hey, if you only
> make these changes, Python will actually become popular". It's almost
> mandatory."


Additionally, that proofs: that this is not a single meaning.
And also speaking from changes is wrong. 
Enhancements or extensions would be correct.



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)

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?



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

Re: Python handles globals badly.

[Emile van Sebille]

On 9/10/2015 3:25 PM, t...@freenet.de wrote:

> Who decides it?

The BDFL or his delegate. It's simplest that way.

Emile


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

Re: Python handles globals badly.

[Ian Kelly]

On Thu, Sep 10, 2015 at 4:25 PM,   wrote:
> with following proofs uncommented:

None of these are "proofs".

> Each sample provided would work without global
> (or you get runtime failure while try to write a global).

What samples? It would be easier to follow your messages if you would
include quotes from previous messages as context.

> 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.
4) Otherwise, it's local.

If you take out step 2, then the compiler has no way of distinguishing
whether a variable that is assigned to is local or global.

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

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?

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.

> It is correct that there have to be a decision for spaces or tabs.
> But sure not necessarily the exact same indentation to the right for each 
> block.
> Jus more same inserter to the right and the context is clear.

I don't understand what you're trying to say here.

> But all proposals are more or less fully denied - for more or less no reasons.

You've been given reasons. You seem unwilling to accept them.

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

Ad hominem.

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

This is not a Google Group. This is the comp.lang.python newsgroup,
which is mirrored bidirectionally to the python.org python-list
mailing list. Google Groups provides another portal to the newsgroup.
There is no way to measure how many users have been reading this
thread in the newsgroup or the mailing list.

> So, is this really the place where a PEP can be started?

No, this list is for general Python discussion. The place to present a
PEP is the python-dev mailing list. It is generally considered
advisable to post the idea to the python-ideas mailing list first, to
find support for the idea and to hone it before going to the trouble
of writing a PEP.

If you do get to the point of writing a PEP, you will also need to
have a clear picture of how you plan to actually implement the idea.
It's not enough to just propose that "the global keyword should be
optional". Precisely how would scopes be determined? How would you
ensure backward compatibility? These are questions that would need
answers before anything could be implemented.

> When has a proposal to be accepted? If ten-thousands say yes?
> Which ten-thousands? Who decides it?

That's up to the BDFL.
-- 
https://mail.python.org/mailman/listinfo/python-list

finding the diff

[Noah]

Hi there,

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?


What are some options that work well?

Cheers,

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

Re: Context-aware return

[Denis McMahon]

On Fri, 11 Sep 2015 03:54:14 +1000, Steven D'Aprano wrote:

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

Yes

>>> x = func()
>>> x
>>> func()
>>> print x == func() 
>>> assert x == func()

Would you expect the last two calls to func() to return 999 or "Awesome"? 
Why? What is the material difference if any between interpreter (a) 
displaying the return value and (b) comparing the return value with 
another value.

Debugging nightmare!

-- 
Denis McMahon, denismfmcma...@gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[MRAB]

On 2015-09-11 01:35, Ian Kelly wrote:

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

[snip]

It is correct that there have to be a decision for spaces or tabs.
But sure not necessarily the exact same indentation to the right for each block.
Jus more same inserter to the right and the context is clear.


I don't understand what you're trying to say here.


[snip]
I don't understand either, but perhaps he means that as long as the
lines of a suite are indented more than their introductory line, the
meaning should be clear (although "sibling" lines of the introductory
line should still be indented the same as the introductory line, e.g.
"elif" lines should still be indented the same amount as their "if"
line).

It would look untidy though! :-)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Fri, Sep 11, 2015 at 6:07 AM,   wrote:
> On Thu, Sep 10, 2015, at 12:48, Chris Angelico wrote:
>> Having assignment be a statement (and therefore illegal in a loop
>> condition) makes sense. Having it be an expression that yields a
>> useful or predictable value makes sense. Having it be an expression,
>> but not returning a value, doesn't.
>
> Why not? Having it not return a value (and thus be illegal in places
> that expect a value), but be legal in places like C's comma operator or
> Lisp's progn that do not use the value, would make logical sense. Your
> while loop could be written as something like "while (ch = getchar();
> ch): ..."
>
> The main purpose of this would be to prevent you from using it where a
> boolean is expected, which wouldn't be necessary if Python hadn't
> repeated C's mistake of spelling it "=".

I didn't say it doesn't make _technical_ sense to have an expression
without  value, but it doesn't make any _useful_ sense. In previous
posts I consciously avoided this wording, but I'm going to say it, and
clink my pun jar: There's no value in doing it that way.

In order to make this valueless expression useful, you have to first
have some sort of expression that consists of two subexpressions,
where one of them is ignored. (Like C's comma operator.) Why do it?
Why not simply have the expression yield a useful value - or else not
be an expression, such that you have two _statements_?

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

Re: Signal SIGINT ignored during socket.accept

[Chris Angelico]

On Fri, Sep 11, 2015 at 6:12 AM, James Harris  wrote:
> Thanks for your help, Chris. Using select() is a very good option. I tried
> first without a timeout and even then this version of Windows does not
> recognise Control-C until after the select() call returns (which needs
> similar prompting as with the accept() call. However, select() with a
> timeout allows the code to work both on Windows and Linux. Hooray!
>
> For anyone else who is looking for this the earlier test code was changed to
>
> port = 8880
> import select
> import socket
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s.setblocking(0)
> s.bind(("", port))
> s.listen(1)
> while 1:
>  ready = select.select((s,), (), (), 0.5)
>  #print '(ready %s)' % repr(ready)
>  if (ready[0]):
>try:
>  endpoint = s.accept()
>except socket.error, details:
>  print 'Ignoring socket error:', repr(details)
>  continue
>print '(endpoint %s)' % repr(endpoint)
>if endpoint:
>  break

(Your indentation is looking like a single space, here. I would
suggest indenting a bit more, for readability; but it might just be an
artefact of posting.)

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.

Assuming you don't need stdin for any other purpose, one solution
would be to spin off a thread that simply watches for a keyboard
signal. I tested this on Windows 7 with 2.7.10 and 3.4.3, and it
appears to work:

import socket
import threading

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

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

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 long as you have _some_ thread reading from the console, you can
get woken up by Ctrl-C. When that happens, it simply fires off a quick
socket connection to itself, thus waking up the main thread; and then
the main thread sees the KeyboardInterrupt. (I'm not sure why, but
instead of seeing KeyboardInterrupt in the console thread, I've been
seeing EOFError. Since I don't particularly care to explore the
problem, I just wrote the except clause to catch both.)

This eliminates the polling, but you have to sacrifice stdin to do it.
It may be worth bracketing all of that code with a platform check -
don't bother doing all this unless you're on Windows. Up to you.

Stupid Windows.

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

Re: Python handles globals badly.

[Gene Heskett]

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
-- 
"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: numpy

[chenc...@inhand.com.cn]

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?


On 09/11/2015 12:05 AM, Laura Creighton wrote:

In a message of Thu, 10 Sep 2015 18:11:08 +0800, "chenc...@inhand.com.cn" write
s:

hi:
I have to use numpy package. My python runs on my embedded arm
device. So, how do i cross compile numpy?
--
https://mail.python.org/mailman/listinfo/python-list

Ask that one here:
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Do you even have a floating point processor?  I'm not an
expert but I don't think that it makes sense to try to run
numpy anywhere that doesn't have one.

Laura





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

subdividing a rectangle using numpy

[Seb]

Hello,

The code below is what I came up with to solve the problem:

1. We're given geographic coordinates for two opposite vertices of a
   rectangle.
2. If any of the sides of the rectangle is larger than some number of
   degrees, then subdivide the rectangle into squares/rectangles such
   that all sub-units have sides smaller than the specified amount.
3. Define each sub-unit by providing a list of all vertices, where the
   first and last vertices are identical so as to close the polygon.

I've ignored the "if" part of the problem to simplify.

The key to my solution was to use numpy's meshgrid to generate the
coordinates for defining the sub-units.  However, it seems awfully
complex and contrived, and am wondering if there's a simpler solution,
or perhaps some package offers this functionality.  I couldn't find any,
so any tips appreciated.

------
# Let's say we have these coordinates
lons = [-96, -51.4]
lats = [60, 72]
# And we want to create 10x10 (max) degree polygons covering the rectangle
# defined by these coordinates
step = 10
# Calculate how many samples we need for linspace.  The ceiling is required
# to cover the last step, and then add two to accomodate for the inclusion
# of the end points... what a pain.
xn = np.ceil((lons[1] - lons[0]) / step) + 2
yn = np.ceil((lats[1] - lats[0]) / step) + 2
xgrd = np.linspace(lons[0], lons[1], xn)
ygrd = np.linspace(lats[0], lats[1], yn)
# Create grids of longitudes and latitudes with dimension (yn, xn).  The
# elements of the longitude grid are the longitude coordinates along the
# rows, where rows are identical.  The elements of the latitude grid are
# the latitude coordinates along the columns, where columns are identical.
longrd, latgrd = np.meshgrid(xgrd, ygrd, sparse=False)
for i in range(int(xn) - 1):
for j in range(int(yn) - 1):
print [(longrd[j, i], latgrd[j, i]), # lower left
   (longrd[j, i + 1], latgrd[j, i]), # lower right
   (longrd[j, i + 1], latgrd[j + 1, i]), # upper right
   (longrd[j, i], latgrd[j + 1, i]), # upper left
   (longrd[j, i], latgrd[j, i])] # close at lower left
------


-- 
Seb

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

Re: subdividing a rectangle using numpy

[Nobody]

On Thu, 10 Sep 2015 22:05:07 -0500, Seb wrote:

> The key to my solution was to use numpy's meshgrid to generate the
> coordinates for defining the sub-units.  However, it seems awfully
> complex and contrived,

Half a dozen lines of code is "complex and contrived"?

Also, you should lose marks for having those for loops. Hint:

corners = np.array([[0,0],[0,1],[1,1],[1,0],[0,0]])

> or perhaps some package offers this functionality. 

People don't write packages for such trivial tasks.

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

Re: Python handles globals badly.

[Marko Rauhamaa]

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.

For example, in the default emacs configuration, the C indentation
levels go like this:

   SPC SPC
   SPC SPC SPC SPC
   SPC SPC SPC SPC SPC SPC
   TAB
   TAB SPC SPC

etc. The TAB *key* is a command that makes emacs indent with a mix of
spaces and TABs.


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

Re: Python handles globals badly.

[Chris Angelico]

On Fri, Sep 11, 2015 at 2:34 PM, Marko Rauhamaa  wrote:
> etc. The TAB *key* is a command that makes emacs indent with a mix of
> spaces and TABs.

I don't care how you key them in. If your tab key moves you to the
next position, that's good. If you convert a sequence of N spaces into
a tab character, though, that's bad, because then your file ends up
with a mix, and an inconsistent one. To make emacs safe for use with
Python code, you'll need to reconfigure it so the tab key inserts
either a tab character or spaces, but never switches between them.

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.

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

Re: Python handles globals badly.

[Ian Kelly]

On Thu, Sep 10, 2015 at 10:34 PM, 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.
>
> For example, in the default emacs configuration, the C indentation
> levels go like this:
>
>SPC SPC
>SPC SPC SPC SPC
>SPC SPC SPC SPC SPC SPC
>TAB
>TAB SPC SPC
>
> etc. The TAB *key* is a command that makes emacs indent with a mix of
> spaces and TABs.

That's all true but is tangential to my point. Emacs users with that
setup would probably want the Python compiler to interpret a tab as
eight spaces. On the other hand, the major benefit that is often
touted for indentation using tab characters is that the reader can set
their tab width and read the code with their preferred indentation
(this fails however when using mixed tabs and spaces as in that Emacs
scheme). Such users typically use one tab character as one level of
indentation and would presumably prefer to have those tab characters
interpreted as two or four spaces, not eight.

If we're forced to choose a canonical tab width, both groups can't
win. (Of course that Emacs indentation scheme already doesn't work for
Python, but then the only possible benefit I can see to using it is a
mild compression of the source code, an economy of disk space that
really isn't necessary in this day and age.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Marko Rauhamaa]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python handles globals badly.

[Chris Angelico]

On Fri, Sep 11, 2015 at 3:15 PM, 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.

I don't understand. How does that usage run counter to the old
conventions? A tab character, a press of the tab key, was a signal to
move to the next logical column - regardless of the exact width of a
column. It's also completely compatible with the stricter rule "a tab
is equivalent to eight spaces".

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

Re: Python handles globals badly.

[Marko Rauhamaa]

Ian Kelly :

> Emacs users with that setup would probably want the Python compiler to
> interpret a tab as eight spaces.

Which it does:

   Tabs are replaced (from left to right) by one to eight spaces such
   that the total number of characters up to and including the
   replacement is a multiple of eight (this is intended to be the same
   rule as used by Unix).

   https://docs.python.org/3/reference/lexical_analysis.html#lin
   e-structure>

although that definition has been rendered insignificant in Python 3 by
the footnote:

   Indentation is rejected as inconsistent if a source file mixes tabs
   and spaces in a way that makes the meaning dependent on the worth of
   a tab in spaces; a TabError is raised in that case.

> On the other hand, the major benefit that is often touted for
> indentation using tab characters is that the reader can set their tab
> width and read the code with their preferred indentation (this fails
> however when using mixed tabs and spaces as in that Emacs scheme).
> Such users typically use one tab character as one level of indentation
> and would presumably prefer to have those tab characters interpreted
> as two or four spaces, not eight.

That "innovation" has destroyed the TAB character. It won't be missed,
though.

> If we're forced to choose a canonical tab width, both groups can't
> win. (Of course that Emacs indentation scheme already doesn't work for
> Python, but then the only possible benefit I can see to using it is a
> mild compression of the source code, an economy of disk space that
> really isn't necessary in this day and age.)

Emacs didn't invent that scheme. That's how TABs worked in my childhood
across operating systems.

However, TABs were always problematic for other reasons. If you added
a space to the beginning of every line to shift everything to the right,
TABs caused a misalignment.


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

Re: Question about import

[dieter]

"Frank Millman"  writes:
>...
> My project comprises a number of modules, split into packages. Modules
> frequently need to access the contents of other modules, in the same
> or in a different package. I am getting better at it, but I still
> occasionally bump my head against circular imports, and have to fiddle
> around until it settles down again. Not ideal, I know.

Ideally, you have only oneway dependencies between modules.
In most cases, cyclic dependencies can be removed by refactoring - yielding
a better architecture.

> ...
> The surprising thing is that, within aa.py, I just have to say 'import
> b', and I can access 'b.bb.', and the same applies to 'bb.py'.

As a side effect of importing "." ""
is bound in "". Thus, after the first import
of ".", "" can be accessed via ""
after only importing "".


> That makes me wonder if, in my project, I can import all modules
> inside 'start.py', and then just use 'import package_name' inside each
> module?

You could - but you should not as this make you vulnerable with
respect to the import order.

In a small project, this is likely no problem. However, when your
projects grow and reuse components intially developped for other
projects, this may become unfeasable.

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

Re: Question about import

[Frank Millman]

"Ian Kelly"  wrote in message 
news:calwzidm3khnagtt0ohveo5bhqk1tfejbuuuinw9tnuxrpnr...@mail.gmail.com...


On Thu, Sep 10, 2015 at 1:12 AM, Frank Millman  wrote:

> That makes me wonder if, in my project, I can import all modules inside
> 'start.py', and then just use 'import package_name' inside each module?

You can, but for readability and reuse I think it's better to be
explicit in each module and import the fully qualified module names
that are needed, rather than relying on some other module to import
them for you.


I don't disagree. However, I started this exercise because I found a 
situation in one of my modules where I was referring to another module 
without ever importing it, and it worked! It took me quite a while to track 
down what was happening. So there could be a case for being explicit in the 
other direction - import all modules up front, and explicitly state that all 
modules are now free to reference anything in any other module. I will give 
it more thought.


> Another question - I thought that, because aa.py and bb.py are in 
> different

> sub-directories, I would have to set them up as packages by adding
> '__init__.py' to each one, but it works fine without that. What am I
> missing?



That surprises me also, but I suspect it's because they're
subdirectories of the current working directory rather than packages
found on the sys.path.


I had a look at PEP 420, as mentioned by Peter. I did not understand much of 
it, but it did say that omitting __init__.py incurs an additional overhead, 
so I will stick with including it.


Many thanks for the useful input.

Frank


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

Re: XML Binding

[Michele Simionato]

On Thursday, September 3, 2015 at 6:55:06 PM UTC+2, Palpandi wrote:
> Hi All,
> 
> Is there any module available in python standard library for XML binding? If 
> not, any other suggestions.
> 
> Which is good for parsing large file?
> 1. XML binding
> 2. Creating our own classes
> 
> 
> Thanks,
> Palpandi

I am one who has just abandoned lxml for xml.etree in the standard library. The 
reasons for that change were:

1. we had issues compiling/installing lxml on different platforms
2. we had instabilities from one version to the other for what we wanted to do 
(XML validation with an XSD schema)

At the end we solved everything by replacing the XSD validation with a custom 
validation (which we had to do anyway); at that point the need for lxml 
disappeared and ElementTree did everything we wanted, except providing the line 
error in case of invalid files, which was easy to add. It was also smaller, 
easier to understand and to customize. Its speed was more than enough.

However I hear that everybody else is happy with lxml, so YMMV.


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