Re: Need help to write data onto an XML file after reading data from another xml file

[varun7rs]

I try to add an edge with the source id and destination id over a loop but this 
is the error I am getting. And the range for the for addEdge is something I 
have no clue about. 

python export.py --output topology.xml --xml germany50.xml
Traceback (most recent call last):
  File "export.py", line 239, in 
main(sys.argv[1:])
  File "export.py", line 234, in main
network.addEdge( PHY_LINKS( j , sourcen, destnn, sid, did, cap_bdw) )
  File "/home/srva/Approach_Read.py", line 89, in addEdge
self.nodes[ edge.SourceID ].addInEdge( edge )
IndexError: list index out of range

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

Re: Why isn't my re.sub replacing the contents of my MS Word file?

[wxjmfauth]

Le mardi 13 mai 2014 22:26:51 UTC+2, MRAB a écrit :
> On 2014-05-13 20:01, scottca...@gmail.com wrote:
> 
> > On Tuesday, May 13, 2014 9:49:12 AM UTC-4, Steven D'Aprano wrote:
> 
> >>
> 
> >> You may have missed my follow up post, where I said I had not noticed you
> 
> >> were operating on a binary .doc file.
> 
> >>
> 
> >> If you're not willing or able to use a full-blown doc parser, say by
> 
> >> controlling Word or LibreOffice, the other alternative is to do something
> 
> >> quick and dirty that might work most of the time. Open a doc file, or
> 
> >> multiple doc files, in a hex editor and *hopefully* you will be able to
> 
> >> see chunks of human-readable text where you can identify how en-dashes
> 
> >> and similar are stored.
> 
> >
> 
> >I created a .doc file and opened it with UltraEdit in binary (Hex) mode. 
> > What I see is that there are two characters, one for ndash and one for 
> > mdash, each a single byte long. 0x96 and 0x97.
> 
> >So I tried this: fStr = re.sub(b'\0x96',b'-',fStr)
> 
> >
> 
> >that did nothing in my file. So I tried this: fStr = 
> > re.sub(b'0x97',b'-',fStr)
> 
> >
> 
> >which also did nothing.
> 
> >So, for fun I also tried to just put these wildcards in my re.findall so 
> > I added |Part \0x96|Part \0x97to no avail.
> 
> >
> 
> >Obviously 0x96 and 0x97 are NOT being interpreted in a re.findall or 
> > re.sub as hex byte values of 96 and 97 hexadecimal using my current syntax.
> 
> >
> 
> >So here's my question...if I want to replace all ndash  or mdash values 
> > with regular '-' symbols using re.sub, what is the proper syntax to do so?
> 
> >
> 
> >Thanks!
> 
> >
> 
> 0x96 is a hexadecimal literal for an int. Within a string you need \x96
> 
> (it's \x for 2 hex digits, \u for 4 hex digits, \U for 8 hex digits).




>>> b'0x61' == b'0x61'
True
>>> b'0x96' == b'\x96'
False


- Python and the coding of characters is an unbelievable
mess.
- Unicode a joke.
- I can make Python failing with any valid sequence of
chars I wish.
- There is a difference between "look, my code work with
my chars" and "this code is safely working with any chars".

jmf


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

Re: Fortran

[Marko Rauhamaa]

Steven D'Aprano :

> On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:
>
>> Producing an effective JIT for Python seems like a formidable challenge
>> but not impossible in principle.
>
> Or in practice.
>
> http://pypy.org/

I'm having a hard time finding information on how well it performs wrt
Java, for example. Did PyPy truly find the Philosophers' Stone?


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

Re: New to Python. For in loops curiosity

[Ben Finney]

Leonardo Petry  writes:

> So I am starting with python and I have been working on some simple
> exercises.

You are welcome here. Congratulations on starting with Python!

You may also be interested to know there is also a separate forum
https://mail.python.org/mailman/listinfo/tutor> dedicated to
tutoring beginners in Python.

> Here is something I found curious about python loops
>
> This loop run each character in a string
>
> def avoids(word,letters):
>   flag = True
>   for letter in letters:
>   if(letter in word):
>   flag = False
>   return flag

You should avoid using U+0009 TAB characters for indentation, since they
render inconsistently and can easily result in invisible differences in
changed code. Instead, use four-column indentation with space (U+0020
SPACE) characters.

> The loop below (at the bottom) runs each line of the file
>
> fin = open('wordplay.txt');
> user_input = raw_input('Enter some characters: ')
> count = 0
> for line in fin:
> word = line.strip()
> if(avoids(word, user_input)):
>   count += 1;
>
> This is just too convenient. 

Is that a complaint, or shock at how easy it is? :-)

> Basically my question is: Why is python not treating the contents of
> wordplay.txt as one long string and looping each character?

Because the types of the objects are different; different types define
different behaviour. Indeed, that is almost the definition of what a
type is.

A text string object supports iteration by returning each character
https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str>.

A file object supports iteration by returning each line from the stream
https://docs.python.org/3/library/io.html>.

-- 
 \  “Our products just aren't engineered for security.” —Brian |
  `\ Valentine, senior vice-president of Microsoft Windows |
_o__)development, 2002 |
Ben Finney

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

Re: Fortran

[Ian Kelly]

On Tue, May 13, 2014 at 6:10 PM, Steven D'Aprano
 wrote:
> On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:
>
>> Producing an effective JIT for Python seems like a formidable challenge
>> but not impossible in principle.
>
> Or in practice.
>
> http://pypy.org/
>
> And it's predecessor: http://psyco.sourceforge.net/

Also numba, which is reminiscent of psyco, but with more features and
Python 3 support.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: New to Python. For in loops curiosity

[John Gordon]

In <2f08e970-1334-4e7f-ba84-14869708a...@googlegroups.com> Leonardo Petry 
 writes:

> fin = open('wordplay.txt');
> user_input = raw_input('Enter some characters: ')
> count = 0
> for line in fin:
> word = line.strip()
> if(avoids(word, user_input)):
>   count += 1;

> This is just too convenient. 
> Basically my question is: Why is python not treating the contents of
> wordplay.txt as one long string and looping each character?

> Any comment is greatly appreciate. Thanks

Your code is not treating the contents of wordplay.txt as one long string
because 'for line in fin:' tells it to read line-by-line.

If you want to read the entire contents, use the read() method:

file_content = fin.read()

-- 
John Gordon Imagine what it must be like for a real medical doctor to
gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'.

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

Re: New to Python. For in loops curiosity

[Rustom Mody]

On Wednesday, May 14, 2014 9:08:32 AM UTC+5:30, Leonardo Petry wrote:
> 
> This is just too convenient. 
> 
> Basically my question is: Why is python not treating the contents of 
> wordplay.txt as one long string and looping each character?

Did you mean convenient or inconvenient?

Anyways...

Maybe you want the read method?
https://docs.python.org/2/tutorial/inputoutput.html#methods-of-file-objects

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

Re: New to Python. For in loops curiosity

[Ian Kelly]

On Tue, May 13, 2014 at 9:38 PM, Leonardo Petry
 wrote:
> The loop below (at the bottom) runs each line of the file
>
> fin = open('wordplay.txt');
> user_input = raw_input('Enter some characters: ')
> count = 0
> for line in fin:
> word = line.strip()
> if(avoids(word, user_input)):
> count += 1;
>
> This is just too convenient.
> Basically my question is: Why is python not treating the contents of 
> wordplay.txt as one long string and looping each character?

Because the iterator for file-like objects iterates over lines, not characters.
-- 
https://mail.python.org/mailman/listinfo/python-list

New to Python. For in loops curiosity

[Leonardo Petry]

Hi All,

So I am starting with python and I have been working on some simple exercises.

Here is something I found curious about python loops

This loop run each character in a string

def avoids(word,letters):
flag = True
for letter in letters:
if(letter in word):
flag = False
return flag

The loop below (at the bottom) runs each line of the file

fin = open('wordplay.txt');
user_input = raw_input('Enter some characters: ')
count = 0
for line in fin:
word = line.strip()
if(avoids(word, user_input)):
count += 1;

This is just too convenient. 
Basically my question is: Why is python not treating the contents of 
wordplay.txt as one long string and looping each character?

Any comment is greatly appreciate. Thanks


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

Re: Need help to write data onto an XML file after reading data from another xml file

[Dave Angel]

On 05/13/2014 10:31 AM, varun...@gmail.com wrote:

Hello Users,

I am in dire need of your help. I have been working on this code for quite some 
time and it is making me restless. All I am trying to do is,

1. Read data from an xml file. Source: 
http://sndlib.zib.de/coredata.download.action?objectName=germany50&format=xml&objectType=network

2. The data I'm concerned about is the node ID, co-ordinates, capacity of the 
links, source and destination names.

3. I'm creating a topology with this information and the topology is same as 
the one given in the xml file. But, I'd like to add a few extra parameters and 
demands which I have mentioned in the .py file.

4. This is where I am faltering. I am just not able to create this topology. 
The file has also become really messy as I tried a lot of weird stuff and 
commented it out as it did not work.

5. I'll attach the relevant files and I'd like to write the output onto a new 
xml file.

I'd be glad if any of you could help me out. I'm indebted to you guys. Oh I was 
not aware that I could  attach files. Anyways, here is the link to the files 
I'm working on
https://www.dropbox.com/sh/i8h321y7c9c60vt/AADzDj7oOM8YU76Ww6W4LIPYa

Thanks a lot everyone



Try to include the relevant information in your message.  Many people 
cannot, or will not, follow links.  Further, those links are frequently 
transient (such as your dropbox one), which means the message thread 
becomes historically useless.  So a link to point to a particular 
library is useful and practical, one to your source code is not.


And many readers cannot see attachments or html formatted messages.



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

Re: Everything you did not want to know about Unicode in Python 3

[Ethan Furman]

On 05/13/2014 05:10 PM, Steven D'Aprano wrote:

On Tue, 13 May 2014 10:08:42 -0600, Ian Kelly wrote:


Because Python 3 presents stdin and stdout as text streams however, it
makes them more difficult to use with binary data, which is why Armin
sets up all that extra code to make sure his file objects are binary.


What surprises me is how hard that is. Surely there's a simpler way to
open stdin and stdout in binary mode? If not, there ought to be.


Somebody already posted this:

https://docs.python.org/3/library/sys.html#sys.stdin

which talks about .detach().

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

[OT] Copyright statements and why they can be useful (was: Everything you did not want to know about Unicode in Python 3)

[Ben Finney]

Steven D'Aprano  writes:

> On Tue, 13 May 2014 14:42:51 +, alister wrote:
>
> > You do not need any statements at all, copyright is automaticly
> > assigned to anything you create (at least that is the case in UK
> > Law) although proving the creation date my be difficult.
>
> (1) In my lifetime, that wasn't always the case. Up until the 1970s or 
> thereabouts, you had to explicitly register anything you wanted 
> copyrighted […]

> (2) You don't have to just prove copyright. You also have to *identify* 
> who the work is copyrighted by, and it needs to be an identifiable legal 
> person (actual person or corporation), not necessarily the author. […]

(3) In all jurisdictions where copyright exists, the copyright holder
nominally has monopoly on the work for only a fixed term, starting from
the date of publication. To know when the copyright will expire, it's
essential to know the date from which copyright starts; this is best
done explicitly in the copyright statement.

I say “nominally”, because another alarming and unilateral trend is to
dramatically extend the nominally fixed term, and to strong-arm national
governments with terade deals to maximise the copyright term around the
world.

The effect, as Lawrence Lessig points out:

The meaning of this pattern is absolutely clear to those who pay to
produce it. The meaning is: No one can do to the Disney Corporation
what Walt Disney did to the Brothers Grimm. That though we had a
culture where people could take and build upon what went before,
that's over. There is no such thing as the public domain in the
minds of those who have produced these 11 extensions these last 40
years because now culture is owned.

http://www.oreillynet.com/pub/a/policy/2002/08/15/lessig.html>

Or, less poetically, since the term of copyright is only nominally
fixed, and in practice just keeps getting extended by newly-lobbied
legislation every twenty years or so, the copyright maximalists have
de facto instituted “perpetual copyright on the installment plan”
https://en.wikipedia.org/wiki/Perpetual_copyright>.

Nevertheless, copyright on works created this century will in principle
expire at some date in the future; and to know when that date will be,
we need to know when the copyright began. Hence the need for explicit
copyright statements saying the date of publication.

http://questioncopyright.org/>

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

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

Re: PEP 8 : Maximum line Length :

[Roy Smith]

In article ,
 Ben Finney  wrote:

> Roy Smith  writes:
> 
> > >p = Subprocess.Popen(shlex.split(cmd),
> > > stdout=subprocess.PIPE,
> > > stderr=subprocess.PIPE)
> 
> That is PEP 8 conformant, but I find it hurts maintainability: it is far
> too much indentation. Horizontal space is costly, because so much
> indentation severely limits the length of names etc. that you can use on
> the continuation lines.

It only does that if you limit yourself to 80 character lines.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 : Maximum line Length :

[Gregory Ewing]

Ben Finney wrote:

The 80 character line limit is *not* driven by a limitation of computer
technology; it is driven by a limitation of human cognition. For that
reason, it remains relevant until human cognition in the general reading
population improves.


Another thing: Just because I may have 2048 pixes of
horizontal space available on my monitor, that doesn't
mean I want to devote all of them to displaying a
single source file.

I like to be able to put 2 or 3 source windows side
by side, or have a web browser showing documentation
alongside while I work, etc.

While the limit doesn't have to be exactly 80 chars,
something not too much bigger is a good idea for a
variety of reasons.

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

Re: Everything you did not want to know about Unicode in Python 3

[Steven D'Aprano]

On Tue, 13 May 2014 10:08:42 -0600, Ian Kelly wrote:

> Because Python 3 presents stdin and stdout as text streams however, it
> makes them more difficult to use with binary data, which is why Armin
> sets up all that extra code to make sure his file objects are binary.

What surprises me is how hard that is. Surely there's a simpler way to 
open stdin and stdout in binary mode? If not, there ought to be.




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fortran

[Steven D'Aprano]

On Tue, 13 May 2014 22:57:16 +0300, Marko Rauhamaa wrote:

> Producing an effective JIT for Python seems like a formidable challenge
> but not impossible in principle.

Or in practice.

http://pypy.org/

And it's predecessor: http://psyco.sourceforge.net/





-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: httplib with NETRC authentication

[Chris Angelico]

On Wed, May 14, 2014 at 9:33 AM, pratibha natani  wrote:
> I am trying to establish http connection to a gerrit host using netrc 
> authentication. I have a netrc file created with following entries:
> machine host1.com login name password pass
>
> I did a debug and saw that my netrc file is being read correctly. Also in the 
> connection object(after sending request) a header got created with 
> appropriate credentials:
>  'headers': {'Authorization': 'Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ='}
>
> Still I get 401,Unauthorized in response. Any help would be greatly 
> appreciated!

The obvious question is: What *does* work? Does it work when you use
wget, or some other application? Then go and look at what that sends
for its authentication headers. Tip: It won't be "Authorization".

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

Re: Everything you did not want to know about Unicode in Python 3

[Chris Angelico]

On Wed, May 14, 2014 at 9:53 AM, Steven D'Aprano
 wrote:
> With the current system, all of us here are technically violating
> copyright every time we reply to an email and quote more than a small
> percentage of it.

Oh wow... so when someone quotes heaps of text without trimming, and
adding blank lines, we can complain that it's a copyright violation -
reproducing our work with unauthorized modifications and without
permission...

I never thought of it like that.

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

Re: Exception problem with module

[Steven D'Aprano]

On Tue, 13 May 2014 16:59:46 +, Joseph L. Casale wrote:

> I am working with a module that I am seeing some odd behavior.
> 
> A module.foo builds a custom exception, module.foo.MyError, its done
> right afaict.
> 
> Another module, module.bar imports this and calls
> bar.__setattr__('a_new_name', MyError).

I see that you've solved your immediate problem, but you shouldn't call 
__setattr__ directly. That should actually be written

setattr(bar, 'a_new_name', MyError)

But really, since bar is (apparently) a module, and it is *bar itself* 
setting the attribute, the better way is

a_new_name = MyError

or even 

from module.foo import MyError as a_new_name



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything you did not want to know about Unicode in Python 3

[Steven D'Aprano]

On Tue, 13 May 2014 14:42:51 +, alister wrote:

> On Tue, 13 May 2014 13:51:20 +, Grant Edwards wrote:
> 
>> On 2014-05-13, Steven D'Aprano 
>> wrote:
>>> On Tue, 13 May 2014 07:20:34 -0400, Roy Smith wrote:
>>>
 ASCII *is* all I need.
>>>
>>> You've never needed to copyright something? Copyright © Roy Smith
>>> 2014...
>> 
>> Bah.  You don't need the little copyright symbol at all.  The statement
>> without the symbol has the exact same legal weight.
> 
> 
> You do not need any statements at all, copyright is automaticly assigned
> to anything you create (at least that is the case in UK Law) although
> proving the creation date my be difficult.

(1) In my lifetime, that wasn't always the case. Up until the 1970s or 
thereabouts, you had to explicitly register anything you wanted 
copyrighted, a much more sensible system which weeded out the meaningless 
copyrights on economically worthless content. If we still had that 
system, orphan works would be a lesser problem.

With the current system, all of us here are technically violating 
copyright every time we reply to an email and quote more than a small 
percentage of it. Not to mention all the mirror sites that violate 
copyright by mirroring our posts in their entirety without permission.

(Author's moral rights not to be misquoted or plagiarised are a different 
kettle of fish separate from their ownership rights over the work. That 
should be automatic.)

(2) You don't have to just prove copyright. You also have to *identify* 
who the work is copyrighted by, and it needs to be an identifiable legal 
person (actual person or corporation), not necessarily the author. In the 
absence of a statement otherwise, copyright is assumed to be held by the 
author, but that's not always the case -- it might be a work for hire, or 
copyright might have been transferred to another person or entity. Or the 
author is unidentifiable. Hence the orphan work problem: it's presumed to 
be copyrighted, but since nobody knows who owns the copyright, there's no 
way to get permission to copy that work. It might as well be lost, even 
when the original is sitting right there in front of you mouldering away.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

httplib with NETRC authentication

[pratibha natani]

Hi,

I am trying to establish http connection to a gerrit host using netrc 
authentication. I have a netrc file created with following entries:
machine host1.com login name password pass

I did a debug and saw that my netrc file is being read correctly. Also in the 
connection object(after sending request) a header got created with appropriate 
credentials:
 'headers': {'Authorization': 'Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ='}

Still I get 401,Unauthorized in response. Any help would be greatly appreciated!

  headers = headers or {}
  bare_host = host.partition(':')[0]
  auth = NETRC.authenticators(bare_host)
  if auth:
headers.setdefault('Authorization', 'Basic %s' % (
base64.b64encode('%s:%s' % (auth[0], auth[2]
print "inside auth 0 ", auth[0]
print "inside auth 2 ", auth [2]
  if body:
body = json.JSONEncoder().encode(body)
headers.setdefault('Content-Type', 'application/json')
  conn = httplib.HTTPSConnection(host)
  conn.req_host = host
  conn.req_params = {
  'url': '/a/%s' % path,
  'method': reqtype,
  'headers': headers,
  'body': body,
  }
  conn.request(**conn.req_params)
  print "conn ", conn.__dict__


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

Re: How can this assert() ever trigger?

[Joseph Martinot-Lagarde]

Le 13/05/2014 11:56, Albert van der Horst a écrit :

In article ,
Joseph Martinot-Lagarde   wrote:

Le 10/05/2014 17:24, Albert van der Horst a écrit :

I have the following code for calculating the determinant of
a matrix. It works inasfar that it gives the same result as an
octave program on a same matrix.

/ 

def determinant( mat ):

..

  result = lastr[jx]
  assert(result<>0.)

...

  assert(result<>0.)
  nom *= result   # Compenstate for multiplying a row.

...

  assert(nom<>0.)

..


/-

Now on some matrices the assert triggers, meaning that nom is zero.
How can that ever happen? mon start out as 1. and gets multiplied
with a number that is asserted to be not zero.

Any hints appreciated.

Groetjes Albert


I know it's not the question, but if you want a replacement for octave
did you try numpy (and scipy) ? The determinant would be computer faster
and with less memory than with your function.


I'm using several programming languages in a mix to solve Euler problems.
This is about learning how octave compares to python for a certain kind of
problem as anything.
The determinant program I had lying around, but it was infinite precision
with integer only arithmetic. Then I made a simple modification and got
mad because I didn't understand why it didn't work.

I have used numpy and its det before, but I find it difficult to
remember how to create a matrix in numpy. This is the kind of thing
that is hard to find in the docs. Now I looked it up in my old
programs: you start a matrix with the zeroes() function.

I expect the built in determinant of octave to be on a par with corresponding
python libraries.



---


Groetjes Albert



You can use numpy.zeros(), but you can also use the same list of lists 
that you use for your problem.


Transform a list of lists into a numpy array:
>>> np.asarray([[1, 2],[3, 4]])
array([[1, 2],
   [3, 4]])

Use a numpy function directly on a list of lists (works for must numpy 
functions):

>>> np.linalg.det([[1, 2],[3, 4]])
-2.0004

More info on array creation: 
http://wiki.scipy.org/Tentative_NumPy_Tutorial#head-d3f8e5fe9b903f3c3b2a5c0dfceb60d71602cf93


---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce 
que la protection avast! Antivirus est active.
http://www.avast.com


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

Re: PEP 8 : Maximum line Length :

[Ben Finney]

Steven D'Aprano  writes:

> On Tue, 13 May 2014 04:52:26 -0700, Rustom Mody wrote:
>
> > What this goes to show is that while 80 is ridiculously low by most
> > displays today, 
>
> Not for people who like to has two (or three, or four) windows side-by-
> side. Or multiple views of the same document.

There's also the fact that, while the capacity of monitors to display
pixels has dramatically increased in recent decades, the capacity of
human cognition to scan long lines of text has not increased at all in
that time.

The 80 character line limit is *not* driven by a limitation of computer
technology; it is driven by a limitation of human cognition. For that
reason, it remains relevant until human cognition in the general reading
population improves.

-- 
 \   “Give a man a fish, and you'll feed him for a day; give him a |
  `\religion, and he'll starve to death while praying for a fish.” |
_o__)   —Anonymous |
Ben Finney

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

Re: Why isn't my re.sub replacing the contents of my MS Word file?

[MRAB]

On 2014-05-13 20:01, scottca...@gmail.com wrote:

On Tuesday, May 13, 2014 9:49:12 AM UTC-4, Steven D'Aprano wrote:


You may have missed my follow up post, where I said I had not noticed you
were operating on a binary .doc file.

If you're not willing or able to use a full-blown doc parser, say by
controlling Word or LibreOffice, the other alternative is to do something
quick and dirty that might work most of the time. Open a doc file, or
multiple doc files, in a hex editor and *hopefully* you will be able to
see chunks of human-readable text where you can identify how en-dashes
and similar are stored.


   I created a .doc file and opened it with UltraEdit in binary (Hex) mode. 
What I see is that there are two characters, one for ndash and one for mdash, 
each a single byte long. 0x96 and 0x97.
   So I tried this: fStr = re.sub(b'\0x96',b'-',fStr)

   that did nothing in my file. So I tried this: fStr = 
re.sub(b'0x97',b'-',fStr)

   which also did nothing.
   So, for fun I also tried to just put these wildcards in my re.findall so I 
added |Part \0x96|Part \0x97to no avail.

   Obviously 0x96 and 0x97 are NOT being interpreted in a re.findall or re.sub 
as hex byte values of 96 and 97 hexadecimal using my current syntax.

   So here's my question...if I want to replace all ndash  or mdash values with 
regular '-' symbols using re.sub, what is the proper syntax to do so?

   Thanks!


0x96 is a hexadecimal literal for an int. Within a string you need \x96
(it's \x for 2 hex digits, \u for 4 hex digits, \U for 8 hex digits).
--
https://mail.python.org/mailman/listinfo/python-list

Re: Real-world use of concurrent.futures

[Andrew McLean]

On 08/05/2014 21:44, Ian Kelly wrote:
> On May 8, 2014 12:57 PM, "Andrew McLean"  > wrote:
> > So far so good. However, I thought this would be an opportunity to
> > explore concurrent.futures and to see whether it offered any benefits
> > over the more explicit approach discussed above. The problem I am having
> > is that all the discussions I can find of the use of concurrent.futures
> > show use with toy problems involving just a few tasks. The url
> > downloader in the documentation is typical, it proceeds as follows:
> >
> > 1. Get an instance of concurrent.futuresThreadPoolExecutor
> > 2. Submit a few tasks to the executer
> > 3. Iterate over the results using concurrent.futures.as_completed
> >
> > That's fine, but I suspect that isn't a helpful pattern if I have a very
> > large number of tasks. In my case I could run out of memory if I tried
> > submitting all of the tasks to the executor before processing any of the
> > results.
>
> I thought that ThreadPoolExecutor.map would handle this transparently
> if you passed it a lazy iterable such as a generator.  From my testing
> though, that seems not to be the case; with a generator of 10
> items and a pool of 2 workers, the entire generator was consumed
> before any results were returned.
>
> > I'm guessing what I want to do is, submit tasks in batches of perhaps a
> > few hundred, iterate over the results until most are complete, then
> > submit some more tasks and so on. I'm struggling to see how to do this
> > elegantly without a lot of messy code just there to do "bookkeeping".
> > This can't be an uncommon scenario. Am I missing something, or is this
> > just not a job suitable for futures?
>
> I don't think it needs to be "messy". Something like this should do
> the trick, I think:
>
> from concurrent.futures import *
> from itertools import islice
>
> def batched_pool_runner(f, iterable, pool, batch_size):
>   it = iter(iterable)
>   # Submit the first batch of tasks.
>   futures = set(pool.submit(f, x) for x in islice(it, batch_size))
>   while futures:
> done, futures = wait(futures, return_when=FIRST_COMPLETED)
> # Replenish submitted tasks up to the number that completed.
> futures.update(pool.submit(f, x) for x in islice(it, len(done)))
> yield from done

That worked very nicely, thank you.  I think that would make a good
recipe, whether for the documentation or elsewhere. I suspect I'm not
the only person that would benefit from something to bridge the gap
between a toy example and something practical.

Andrew



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

Re: Fortran

[Marko Rauhamaa]

Alain Ketterlin :

> The real nice thing that makes Julia a different language is the
> optional static typing, which the JIT can use to produce efficient code.
> It's the only meaningful difference with the current state of python.

I'm guessing the two main performance roadblocks for Python are:

 1. The dot notation is a hash table lookup instead of a fixed offset to
a vector.

 2. The creation of a class instance generates a set of trampolines for
all methods. The trampolines are ordinary fields that can be
overridden.

Both features are critical to Python's "sex appeal;" I wouldn't give
them up for performance gains.

Producing an effective JIT for Python seems like a formidable challenge
but not impossible in principle. After all, the developer *could*
provide that static typing information in, like, 99.9% of the code. That
would be feat worthy of a Millennium Technology Prize. It would be like
having the cake and eating it, too.


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

Re: Why isn't my re.sub replacing the contents of my MS Word file?

[scottcabit]

On Tuesday, May 13, 2014 9:49:12 AM UTC-4, Steven D'Aprano wrote:
> 
> You may have missed my follow up post, where I said I had not noticed you 
> were operating on a binary .doc file.
> 
> If you're not willing or able to use a full-blown doc parser, say by 
> controlling Word or LibreOffice, the other alternative is to do something 
> quick and dirty that might work most of the time. Open a doc file, or 
> multiple doc files, in a hex editor and *hopefully* you will be able to 
> see chunks of human-readable text where you can identify how en-dashes 
> and similar are stored.

  I created a .doc file and opened it with UltraEdit in binary (Hex) mode. What 
I see is that there are two characters, one for ndash and one for mdash, each a 
single byte long. 0x96 and 0x97.
  So I tried this: fStr = re.sub(b'\0x96',b'-',fStr)

  that did nothing in my file. So I tried this: fStr = re.sub(b'0x97',b'-',fStr)

  which also did nothing.
  So, for fun I also tried to just put these wildcards in my re.findall so I 
added |Part \0x96|Part \0x97to no avail.

  Obviously 0x96 and 0x97 are NOT being interpreted in a re.findall or re.sub 
as hex byte values of 96 and 97 hexadecimal using my current syntax.

  So here's my question...if I want to replace all ndash  or mdash values with 
regular '-' symbols using re.sub, what is the proper syntax to do so?

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

Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.

[Mark Lawrence]

On 13/05/2014 17:33, Ian Kelly wrote:

On Tue, May 13, 2014 at 5:59 AM, Simon Evans  wrote:

I can see no bs4 folder within the contents.
I can not see any setup.py file either, but this is how I downloaded it.


You do have a setup.py in there, but your Windows explorer is showing
it to you without the .py extension.  Something unusual is happening
with the download/extraction process though and you're missing the
correct folder structure.  If you take a look here, you can see what
you *should* have after unzipping:

http://bazaar.launchpad.net/~leonardr/beautifulsoup/bs4/files

This approach seems to be unproductive though, so I'm going to second
Mark's suggestion to just use pip:

1) Go to pip-installer.org and download the single file get-pip.py
2) Open a command prompt and cd to the folder you downloaded that file into.
3) python get-pip.py
4) pip install beautifulsoup4

And then you should finally be ready to get started.  Good luck!



To be fair Terry Reedy has suggested pip at least twice, I've just given 
another source of data on how to get pip in the first place.


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Fortran

[Alain Ketterlin]

Mark H Harris  writes:

> On 5/12/14 3:44 AM, Alain Ketterlin wrote:

>> When you are doing scientific computation, this overhead is
>> unacceptable, because you'll have zillions of computations to perform.
>
> I'm still trying to sort that out. I have not tested this yet, but
> it looks like Julia is fully dynamic (yes it has types too), and it
> does parallel processing at its core, so the zillions of computations
> are being handled all at once, depending on how many processors|cores
> you have.

The amount of parallelism is a property of the program, not a property
of the language... I hope you don't expect all your julia statements to
execute in parallel.

(And Fortan/C/C++ have leveraged OpenMP and MPI for years. Julia's
distributed arrays and fork-join model may make things a bit easier for
the programmer, but I doubt it will lead to better performance.)

>> Julia provides a way to make things fast: typing. If you provide
>> explicit types, the dynamic typing part obviously disappears, and
>> the overhead is removed.
>
> Julia is dynamic (depending on how far you want to go with that)
> but what makes it fast is the JIT. It is almost accomplishing C/C++
> and FORTRAN speeds (even though dynamic) because it is compiling
> on-the-fly.

JITing by itself has little impact on performance (as unladden-swallow
has shown for python). For the JIT to produce code as fast as a
Fortan/C/C++ compiler would, two conditions must be met: 1) the JIT has
to have as much information about types as the statically-typed language
compilers have, and 2) the time spent by the JIT compiler has to be
negligible compared to the time spent executing the code.

If your program is not statically typed, the code produced by the JIT is
very unlikely to be more efficient than the code that would be executed
by the virtual machine (or interpreter), because the jitted code needs
to do everything the virtual machine does. And the JIT takes time.

[...]
> Yes, and more+  Gnu GMP & MPFR are not new to me, but the wrapper
> and repl are !  I am just realizing the power behind the libraries in
> this context, but I am very impressed with the functionality wrapped
> around the Gnu stuff... the interface is quite nice.

Good. I don't know mathlab enough to see how it compares.

>> Sorry, I was comparing to Fortran, and it's use in scientific computing.
>> Self modifying code is totally irrelevant there.
>
>no, no, no...  there has to be a value add for scientists to move
> away from R or Matlab, or from FORTRAN. Why go to the trouble?
[...]
>Why?, glad you asked.  Enter self modifying code for one. The
> influence of Lisp|Scheme is potentially huge here.

I wouldn't bet a penny on this. (Probably because I have yet to see a
real, convincing application of self-modifying code. I mean something
which is not covered by JITs---GPU shaders, and things like that.)

The real nice thing that makes Julia a different language is the
optional static typing, which the JIT can use to produce efficient code.
It's the only meaningful difference with the current state of python.

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

RE: Exception problem with module

[Joseph L. Casale]

> Best would be to print out what's in a_new_name to see if it really is
> what you think it is. If you think it is what you think it is, have a
> look at its __mro__ (method resolution order, it's an attribute of
> every class), to see what it's really inheriting. That should show you
> what's happening.

Lol,
In a sea of frustration with this, I cant believe I didn't do that. Problem
solved.

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

Re: Exception problem with module

[Chris Angelico]

On Wed, May 14, 2014 at 2:59 AM, Joseph L. Casale
 wrote:
> During handling of the above exception, another exception occurred:
>
>   File "C:/dir/test.py", line 12, in 
> except a_new_name as exc:
> TypeError: catching classes that do not inherit from BaseException is not 
> allowed

Best would be to print out what's in a_new_name to see if it really is
what you think it is. If you think it is what you think it is, have a
look at its __mro__ (method resolution order, it's an attribute of
every class), to see what it's really inheriting. That should show you
what's happening.

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

Exception problem with module

[Joseph L. Casale]

I am working with a module that I am seeing some odd behavior.

A module.foo builds a custom exception, module.foo.MyError, its done right
afaict.

Another module, module.bar imports this and calls bar.__setattr__('a_new_name', 
MyError).

Now, not in all but in some cases when I catch a_new_name, my code raises a new
exception:

During handling of the above exception, another exception occurred:

  File "C:/dir/test.py", line 12, in 
except a_new_name as exc:
TypeError: catching classes that do not inherit from BaseException is not 
allowed

So, I wont suggest the assignment in bar added anything, nor would I do this, 
but
its what I am working with. Why might this happen? MyError subclasses Exception
and calls super passing back args.

This has something to do with the assignment in bar, catching MyError obviously 
works.

Any ideas?
jlc
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything you did not want to know about Unicode in Python 3

[Ian Kelly]

On Tue, May 13, 2014 at 5:19 AM, alister
 wrote:
> I am only an amateur python coder which is why I asked if I am missing
> something
>
> I could not see any reason to be using the shutil module if all that the
> programm is doing is opening a file, reading it & then printing it.
>
> is it python that causes the issue, the shutil module or just the OS not
> liking the data it is being sent?
>
> an explanation of why this approach is taken would be much appreciated.

No, that part is perfectly fine.  This is exactly what the shutil
module is meant for: providing shell-like operations.  Although in
this case the copyfileobj function is quite simple (have yourself a
look at the source -- it just reads from one file and writes to the
other in a loop), in general the Pythonic thing is to avoid
reinventing the wheel.

And since it's so simple, it shouldn't be hard to see that the use of
the shutil module has nothing to do with the Unicode woes here.  The
crux of the issue is that a general-purpose command like cat typically
can't know the encoding of its input and can't assume anything about
it. In fact, there may not even be an encoding; cat can be used with
binary data.  The only non-destructive approach then is to copy the
binary data straight from the source to the destination with no
decoding steps at all, and trust the user to ensure that the
destination will be able to accommodate the source encoding.  Because
Python 3 presents stdin and stdout as text streams however, it makes
them more difficult to use with binary data, which is why Armin sets
up all that extra code to make sure his file objects are binary.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.

[Ian Kelly]

On Tue, May 13, 2014 at 5:59 AM, Simon Evans  wrote:
> I can see no bs4 folder within the contents.
> I can not see any setup.py file either, but this is how I downloaded it.

You do have a setup.py in there, but your Windows explorer is showing
it to you without the .py extension.  Something unusual is happening
with the download/extraction process though and you're missing the
correct folder structure.  If you take a look here, you can see what
you *should* have after unzipping:

http://bazaar.launchpad.net/~leonardr/beautifulsoup/bs4/files

This approach seems to be unproductive though, so I'm going to second
Mark's suggestion to just use pip:

1) Go to pip-installer.org and download the single file get-pip.py
2) Open a command prompt and cd to the folder you downloaded that file into.
3) python get-pip.py
4) pip install beautifulsoup4

And then you should finally be ready to get started.  Good luck!
-- 
https://mail.python.org/mailman/listinfo/python-list

ANN: Intro+Intermediate Python, San Francisco, Jul 30-31, Aug 1

[wesley chun]

Greetings!

I'll be offering another hardcore Python course this summer near the
San Francisco airport. If you're somewhat new to or have some Python
experience under your belt already but want to fill-in the holes,
this course is for you. Why take a real course when you can learn
Python online or by reading books?

Well, my goal isn't to teach Python syntax, which you can from any
teacher, live or online, or from giant books. My job is to create
great Python developers and removing the roadblocks that impede
your path to getting there. This intensive course is based on my
"Core Python" (http://corepython.com) books and is made up of 3
full days complete with lectures and several hands-on coding labs
per day. t's also a great excuse to coming to beautiful Northern
California for a summer vacation!

Groups and development teams are welcome as well as individuals. I do
more private gigs and fewer of these public courses lately, so please
come join if you can... my next public intro/intermediate course may
not be for awhile, so I'm hoping to meet some of you this time around!

Sign up soon... there's a special earlybird rate for the rest of this
month before going up to the regular rate after that. More details and
registration at http://cyberwebconsulting.com as well as in the ad:
http://goo.gl/pyJseQ

I'm no fan of spam, so I'll only send out one last reminder as the
date gets closer... say around the end of June.

Cheers,
-- Wesley
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"A computer never does what you want... only what you tell it."
+wesley chun  : wescpy at gmail :
@wescpy
Python training & consulting : http://CyberwebConsulting.com
"Core Python" books : http://CorePython.com
Python blog: http://wescpy.blogspot.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything you did not want to know about Unicode in Python 3

[Grant Edwards]

On 2014-05-13, alister  wrote:
> On Tue, 13 May 2014 13:51:20 +, Grant Edwards wrote:
>
>> On 2014-05-13, Steven D'Aprano 
>> wrote:
>>> On Tue, 13 May 2014 07:20:34 -0400, Roy Smith wrote:
>>>
 ASCII *is* all I need.
>>>
>>> You've never needed to copyright something? Copyright © Roy Smith
>>> 2014...
>> 
>> Bah.  You don't need the little copyright symbol at all.  The statement
>> without the symbol has the exact same legal weight.
>
> You do not need any statements at all, copyright is automaticly assigned 
> to anything you create (at least that is the case in UK Law)
> although proving the creation date my be difficult.

Yep, it's the same in the US.

-- 
Grant Edwards   grant.b.edwardsYow! Hello.  Just walk
  at   along and try NOT to think
  gmail.comabout your INTESTINES being
   almost FORTY YARDS LONG!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.

[MRAB]

On 2014-05-13 12:59, Simon Evans wrote:

Dear Ian,  and other programmers, thank you for your advice.
I am resending the last message because this twattish cut and paste facility on 
my computer has a knack of chopping off ones original message, I will try to 
convey the right message this time :

I have removed the original Beautiful Soup 4 download, that I had unzipped to 
my Beautiful Soup directory on the C drive.
I downloaded the latest version of Beautiful Soup 4 from the Crummy site.
I unzipped it, and removed the contents of the unzipped directory and placed 
contents in my Beautiful Soup directory, and again had the same output to my 
console re:


Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\Intel Atom>cd "c:\Beautiful Soup"

c:\Beautiful Soup>c:\Python27\python setup.py install

running install
running build
running build_py
error: package directory 'bs4' does not exist


c:\Beautiful Soup>
---
I have made a note of all the contents of the downloaded and unzipped BS4,ie 
the contents of my Beautiful Soup folder on the C drive, which is as follows:
---

running install
running build
running build_py

error: package directory 'bs4' does not existinit
_html5lib
_htmlparser
_lxml
6.1
AUTHORS
conf
COPYING
dammit
demonstration_markup
element
index.rst
Makefile
NEWS
PGK-INFO
README
setup
test_builder_registry
test_docs
test_html5lib
test_htmlparser
text_lxml
test_soup
test_tree
testing
TODO

I can see no bs4 folder within the contents.
  I can not see any setup.py file either, but this is how I downloaded it.
I am only following instructions as suggested.
I do not understand why it is not working.
I hope someone can direct me in the right direction, as I seem to be stuck, and 
I don't think it has much bearing on my fluency or lack of it with Python.



I think I see your problem: you've unpacked everything into a single
folder instead of a folder hierarchy.

(It also looks like you have Explorer configured to hide the file
extensions. That's generally _not_ recommended.)


Try this:

#! python3.4
# -*- coding: utf-8 -*-
from os.path import splitext
import gzip
import tarfile

# The path of the downloaded file.
tar_gz_path = r'C:\beautifulsoup4-4.3.2.tar.gz'

# Unpack the .tar.gz file to a .tar file.
tar_path, ext = splitext(tar_gz_path)

with gzip.open(tar_gz_path, 'rb') as from_file:
with open(tar_path, 'wb') as to_file:
chunk = from_file.read()
to_file.write(chunk)

# Unpack the .tar file to a folder.
folder, ext = splitext(tar_path)

tar = tarfile.open(tar_path)
tar.extractall(folder)
tar.close()

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

Re: Everything you did not want to know about Unicode in Python 3

[alister]

On Tue, 13 May 2014 13:51:20 +, Grant Edwards wrote:

> On 2014-05-13, Steven D'Aprano 
> wrote:
>> On Tue, 13 May 2014 07:20:34 -0400, Roy Smith wrote:
>>
>>> ASCII *is* all I need.
>>
>> You've never needed to copyright something? Copyright © Roy Smith
>> 2014...
> 
> Bah.  You don't need the little copyright symbol at all.  The statement
> without the symbol has the exact same legal weight.


You do not need any statements at all, copyright is automaticly assigned 
to anything you create (at least that is the case in UK Law) although 
proving the creation date my be difficult.



-- 
Depends on how you define "always".  :-)
 -- Larry Wall in <199710211647.jaa17...@wall.org>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything you did not want to know about Unicode in Python 3

[Chris Angelico]

On Wed, May 14, 2014 at 12:30 AM, Rustom Mody  wrote:
> Come to think of it why have anything other than zeros and ones?

Obligatory: http://xkcd.com/257/

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

Need help to write data onto an XML file after reading data from another xml file

[varun7rs]

Hello Users,

I am in dire need of your help. I have been working on this code for quite some 
time and it is making me restless. All I am trying to do is,

1. Read data from an xml file. Source: 
http://sndlib.zib.de/coredata.download.action?objectName=germany50&format=xml&objectType=network

2. The data I'm concerned about is the node ID, co-ordinates, capacity of the 
links, source and destination names.

3. I'm creating a topology with this information and the topology is same as 
the one given in the xml file. But, I'd like to add a few extra parameters and 
demands which I have mentioned in the .py file. 

4. This is where I am faltering. I am just not able to create this topology. 
The file has also become really messy as I tried a lot of weird stuff and 
commented it out as it did not work. 

5. I'll attach the relevant files and I'd like to write the output onto a new 
xml file. 

I'd be glad if any of you could help me out. I'm indebted to you guys. Oh I was 
not aware that I could  attach files. Anyways, here is the link to the files 
I'm working on
https://www.dropbox.com/sh/i8h321y7c9c60vt/AADzDj7oOM8YU76Ww6W4LIPYa

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

Re: Everything you did not want to know about Unicode in Python 3

[Rustom Mody]

On Tuesday, May 13, 2014 7:13:47 PM UTC+5:30, Chris Angelico wrote:
> On Tue, May 13, 2014 at 11:39 PM, Steven D'Aprano
> > Or price something in cents? I suppose the days of the 25¢ steak dinner
> > are long gone, but you might need to sell something for 99¢ a pound...
> 
> 
> $0.99/lb? :)

Dollars Zeros Slashes Question marks Smileys...
Just alphabets is enough I think...

Come to think of it why have anything other than zeros and ones?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything you did not want to know about Unicode in Python 3

[Skip Montanaro]

On Tue, May 13, 2014 at 3:38 AM, Chris Angelico  wrote:
>> Python 2's ambiguity allows me not to answer the tough philosophical
>> questions. I'm not saying it's necessarily a good thing, but it has its
>> benefits.
>
> It's not a good thing. It means that you have the convenience of
> pretending there's no problem, which means you don't notice trouble
> until something happens... and then, in all probability, your app is
> in production and you have no idea why stuff went wrong.

BITD, when I still maintained and developed Musi-Cal (an early online
concert calendar, long since gone), I faced a challenge when I first
started encountering non-ASCII band names and cities. I resisted UTF-8.
After all, if I printed a string containing an "é", it came out looking like



What kind of mess was that???

I tried to ignore it, or assume Latin-1 would cover all the bases (my first
non-ASCII inputs tended to come from Western Europe). If nothing else, at
least "é" was legible.

Needless to say, those approaches didn't work well. After perhaps six
months or a year, I broke down and started converting everything coming in
​ or going out​
to UTF-8 at the boundaries of my system (making educated guesses at
​input
 encodings if necessary). My life got a whole lot easier after that. The
distinction between bytes and text didn't really matter much, certainly not
compared to the mess I had before where strings of unknown data leaked into
my system and its database.

Skip

​P.S. My apologies for the mess this message probably is. Amazing as it may
seem, Gmail in Chrome does a crappy job editing anything other than plain
text. Also, I'm surprised in this day and age that common tools like Gnome
Terminal have little or no encoding support. I wound up having to pop up
urxvt to get an encodings-flexible terminal emulator...​
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why isn't my re.sub replacing the contents of my MS Word file?

[Chris Angelico]

On Tue, May 13, 2014 at 11:49 PM, Steven D'Aprano
 wrote:
>
> This {EN DASH} is an n-dash.
>
> or:
>
> x\x9c\x0b\xc9\xc8,V\xa8v\xf5Spq\x0c\xf6\xa8U\x00r\x12
> \xf3\x14\xf2tS\x12\x8b3\xf4\x00\x82^\x08\xf8
>
>
> (that last one is the text passed through the zlib compressor)

I had to decompress that just to see what "text" you passed through
zlib, given that zlib is a *byte* compressor :) Turns out it's the
braced notation given above, encoded as ASCII/UTF-8.

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

Re: Everything you did not want to know about Unicode in Python 3

[Grant Edwards]

On 2014-05-13, Steven D'Aprano  wrote:
> On Tue, 13 May 2014 07:20:34 -0400, Roy Smith wrote:
>
>> ASCII *is* all I need.
>
> You've never needed to copyright something? Copyright © Roy Smith 2014...

Bah.  You don't need the little copyright symbol at all.  The
statement without the symbol has the exact same legal weight.

-- 
Grant Edwards   grant.b.edwardsYow! World War Three can
  at   be averted by adherence
  gmail.comto a strictly enforced
   dress code!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything you did not want to know about Unicode in Python 3

[Grant Edwards]

On 2014-05-13, Chris Angelico  wrote:
> On Tue, May 13, 2014 at 4:03 PM, Ben Finney  wrote:
>> (It's always a good day to remind people that the rest of the world
>> exists.)
>
> Ironic that this should come up in a discussion on Unicode, given that
> Unicode's fundamental purpose is to welcome that whole rest of the
> world instead of yelling "LALALALALA America is everything" and
> pretending that ASCII, or Latin-1, or something, is all you need.

Well, strictly speaking, it ASCII or Latin-1 _is_ all I need.

I will however admit to the existence of other people who might need
something else...

-- 
Grant Edwards   grant.b.edwardsYow! How many retured
  at   bricklayers from FLORIDA
  gmail.comare out purchasing PENCIL
   SHARPENERS right NOW??
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why isn't my re.sub replacing the contents of my MS Word file?

[Steven D'Aprano]

On Mon, 12 May 2014 10:35:53 -0700, scottcabit wrote:

> On Friday, May 9, 2014 8:12:57 PM UTC-4, Steven D'Aprano wrote:
> 
>> Good:
>> 
>> 
>> 
>> fStr = re.sub(b'‒', b'-', fStr)
>> 
>> 
>   Doesn't work...the document has been verified to contain endash and
>   emdash characters, but this does NOT replace them.

You may have missed my follow up post, where I said I had not noticed you 
were operating on a binary .doc file.

The text content of your doc file might look like:

   This – is an n-dash.


when viewed in Microsoft Word, but that is not the contents on disk. 
Word .doc files are a proprietary, secret binary format. Apart from the 
rest of the document structure and metadata, the text itself could be 
stored any old way. We don't know how. Microsoft surely knows how it is 
stored, but are unlikely to tell. A few open source projects like 
OpenOffice, LibreOffice and Abiword have reverse-engineered the file 
format. Taking a wild guess, I think it could be something like:

This \xe2\x80\x93 is an n-dash.

or possibly:

\x00T\x00h\x00i\x00s\x00  \x13\x00 \x00i\x00s\x00 \x00a
\x00n\x00 \x00n\x00-\x00d\x00a\x00s\x00h\x00.

or:

This {EN DASH} is an n-dash.

or:

x\x9c\x0b\xc9\xc8,V\xa8v\xf5Spq\x0c\xf6\xa8U\x00r\x12
\xf3\x14\xf2tS\x12\x8b3\xf4\x00\x82^\x08\xf8


(that last one is the text passed through the zlib compressor), but 
really I'm just making up vaguely conceivable possibilities.

If you're not willing or able to use a full-blown doc parser, say by 
controlling Word or LibreOffice, the other alternative is to do something 
quick and dirty that might work most of the time. Open a doc file, or 
multiple doc files, in a hex editor and *hopefully* you will be able to 
see chunks of human-readable text where you can identify how en-dashes 
and similar are stored.



-- 
Steven D'Aprano
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 : Maximum line Length :

[Steven D'Aprano]

On Tue, 13 May 2014 04:52:26 -0700, Rustom Mody wrote:

> What this goes to show is that while 80 is ridiculously low by most
> displays today, 

Not for people who like to has two (or three, or four) windows side-by-
side. Or multiple views of the same document.


> it is too high for many web/mailing-list fora.

And smart phones. 


[...]
> PS.
> Last rule of python list: Always listen to Peter Otten.

Yes. Peter is a treasure to the community, not just for his knowledge but 
for his patience and friendliness.


-- 
Steven D'Aprano

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

Re: Everything you did not want to know about Unicode in Python 3

[Chris Angelico]

On Tue, May 13, 2014 at 11:39 PM, Steven D'Aprano
 wrote:
> You've never needed to copyright something? Copyright © Roy Smith 2014...
> I know some people use (c) instead, but that actually has no legal
> standing. (Not that any reasonable judge would invalidate a copyright
> based on a technicality like that, not these days.)

Copyright Chris Angelico 2014. The full word "copyright" has legal
standing. I tend to stick with that in my README files; staying ASCII
makes it that bit safer for random text editors
(*cough*Notepad*cough*) that might otherwise misinterpret it (only a
bit, though [1]).

> Or price something in cents? I suppose the days of the 25¢ steak dinner
> are long gone, but you might need to sell something for 99¢ a pound...

$0.99/lb? :)

ChrisA

[1] https://en.wikipedia.org/wiki/Bush_hid_the_facts
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fortran (Was: The "does Python have variables?" debate)

[Mark Lawrence]

On 13/05/2014 12:21, Chris Angelico wrote:

On Tue, May 13, 2014 at 9:16 PM, Roy Smith  wrote:

Sometimes code is still running for 15 years because it's so wonderful
nobody has been able to come up with anything better.  Sometimes it's
because nobody knows how it works anymore and everybody is afraid to
touch it :-)


And sometimes, both...



Or neither as you don't have the source :)

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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Everything you did not want to know about Unicode in Python 3

[Steven D'Aprano]

On Tue, 13 May 2014 07:20:34 -0400, Roy Smith wrote:

> ASCII *is* all I need.

You've never needed to copyright something? Copyright © Roy Smith 2014... 
I know some people use (c) instead, but that actually has no legal 
standing. (Not that any reasonable judge would invalidate a copyright 
based on a technicality like that, not these days.)

Or price something in cents? I suppose the days of the 25¢ steak dinner 
are long gone, but you might need to sell something for 99¢ a pound... 


> The problem is, it's not all that other people
> need, and I need to interact with those other people.

True, true.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything you did not want to know about Unicode in Python 3

[Chris Angelico]

On Tue, May 13, 2014 at 11:30 PM, Mark Lawrence  wrote:
> On 13/05/2014 09:38, Chris Angelico wrote:
>>
>>
>> It's not a good thing. It means that you have the convenience of
>> pretending there's no problem, which means you don't notice trouble
>> until something happens... and then, in all probability, your app is
>> in production and you have no idea why stuff went wrong.
>>
>
> Unless you're (un)lucky enough to be working on IIRC the 1/3 of major IT
> projects that deliver nothing :)

Been there, done that. At least, most likely so... there is a chance,
albeit slim, that the boss/owner will either discover someone who'll
finish the project for him, or find the time to finish it himself. I
gather he's looking at ripping all my code out and replacing it with
PHP of his own design, which should be fun. On the plus side, that
does mean he can get any idiot straight out of a uni course to do the
work; much easier than finding someone who knows Python, Pike, bash,
and C++. The White King told Alice that cynicism is a disease that can
be cured... but it can also be inflicted, and a promising-looking
N-year project that collapses because the boss starts getting stupid
with code formatting rules and then ends up firing his last remaining
competent employee is a pretty effective means of instilling cynicism.

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

Re: Everything you did not want to know about Unicode in Python 3

[Mark Lawrence]

On 13/05/2014 09:38, Chris Angelico wrote:


It's not a good thing. It means that you have the convenience of
pretending there's no problem, which means you don't notice trouble
until something happens... and then, in all probability, your app is
in production and you have no idea why stuff went wrong.



Unless you're (un)lucky enough to be working on IIRC the 1/3 of major IT 
projects that deliver nothing :)


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.

[Mark Lawrence]

On 13/05/2014 12:59, Simon Evans wrote:

I suggest that you follow the instructions here 
http://stackoverflow.com/questions/4750806/how-to-install-pip-on-windows 
to get pip, then let pip do the work for you as that's what it's 
designed for :)


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: PEP 8 : Maximum line Length :

[Rustom Mody]

On Tuesday, May 13, 2014 2:15:49 PM UTC+5:30, Peter Otten wrote:
> Ganesh Pal wrote:
> > what would be the best way to intent the below line .
> >p = 
> > Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)
> (3) Import names:
> 
> 
> from subprocess import PIPE
> p = subprocess.Popen(shlex.split(cmd), stdout=PIPE, stderr=PIPE)

Am I missing something basic that nobody has suggested the above
technique iterated once more??

from subprocess import Popen, PIPE
p = Popen(shlex.split(cmd), stdout=PIPE, stderr=PIPE)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 : Maximum line Length :

[Tim Chase]

On 2014-05-13 22:26, Ben Finney wrote:
> Changing the name on the first line doesn't entail changing any
> other line::
> 
> proc = Subprocess.Popen(
> shlex.split(cmd),
> stdout=subprocess.PIPE,
> stderr=subprocess.PIPE)
> 
> special_process_map[this_process] = Subprocess.Popen(
> shlex.split(cmd),
> stdout=subprocess.PIPE,
> stderr=subprocess.PIPE)

I second the idea of just putting each-of-many-parameters on its own
line.  Not only that, I also like to tack on trailing commas and put
the closing paren on its own line to make diffs easier to read:

special_process_map[this_process] = Subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
)

so that when I add the inevitable parameter, the diff merely reads
like

  --- tim1.txt2014-05-13 07:44:42.441754319 -0500
  +++ tim2.txt2014-05-13 07:45:35.753755858 -0500
  @@ -2,4 +2,5 @@
   shlex.split(cmd),
   stdout=subprocess.PIPE,
   stderr=subprocess.PIPE,
  +bufsize=1024,
  )

which is quite clear that just one line was added, compared to

  --- ben1.txt2014-05-13 07:44:51.033754566 -0500
  +++ ben2.txt2014-05-13 07:45:46.737756176 -0500
  @@ -1,4 +1,5 @@
   special_process_map[this_process] = Subprocess.Popen(
   shlex.split(cmd),
   stdout=subprocess.PIPE,
  -stderr=subprocess.PIPE)
  +stderr=subprocess.PIPE,
  +bufsize=1024)

which makes me have to think/verify about whether anything else
changed between insertion and deletion of lines.

-tkc





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

Re: PEP 8 : Maximum line Length :

[Ben Finney]

Roy Smith  writes:

> >p = Subprocess.Popen(shlex.split(cmd),
> > stdout=subprocess.PIPE,
> > stderr=subprocess.PIPE)

That is PEP 8 conformant, but I find it hurts maintainability: it is far
too much indentation. Horizontal space is costly, because so much
indentation severely limits the length of names etc. that you can use on
the continuation lines.

Worse, it is also needlessly tying all the continuation lines to the
length of the text before the open paren. What if ‘p’ changes to some
other name?

With the style I've advocated::

p = Subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)

Changing the name on the first line doesn't entail changing any other
line::

proc = Subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)

special_process_map[this_process] = Subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)

Whereas with your suggestion, every line would need to change simply
because the first one did::


special_process_map[this_process] = Subprocess.Popen(shlex.split(cmd),
 stdout=subprocess.PIPE,
 stderr=subprocess.PIPE)

Yes, that's contrived. But I prefer to use a style that doesn't need to
deal with the issue of when the indentation has gone too far for a
single statement.

It's for both those reasons that I recommend avoiding the “align with
open bracket” style, and instead use a standard eight-column indentation
for continuation lines.

-- 
 \  “One bad programmer can easily create two new jobs a year. |
  `\  Hiring more bad programmers will just increase our perceived |
_o__) need for them.” —David Lorge Parnas, 1999-03 |
Ben Finney

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

Re: PEP 8 : Maximum line Length :

[Ben Finney]

Ganesh Pal  writes:

> what would be the best way to intent the below line .

You'd need to define “best” in order to get an objective answer.

So my answer will be based on my preferences, and general rules I've
observed for making code readable.

> Example 1 :
>
>p =
> Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)

(Your example violates PEP 8 also in not having a space after the
commas. I'll fix that in my response.)

Breaking a long line after bracketing syntax is a good way to do it.
Make sure to use sntadard indentation::

Subprocess.Popen(
shlex.split(cmd), stdout=subprocess.PIPE, stderr=subprocess.PIPE)

Alternatively, if the statement line is indented further::

Subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)

> Iam running pylint and it says  the above line is tool long how do I limit
> it to 79 character without violating any rules

* Break after bracketing syntax::

  frobnicate(
  foo, bar, baz)

* Keep all the inside-the-brackets contents at the same indentation
  level (preferably 8 columns, to differentiate from a block of
  statements)

  if worzel:
  fnoop(wibble, wobble, wubble)
  frobnicate(
  foo, bar, baz)
  while True:
  gezunk()

Here's an answer I gave on StackOverflow for this question
http://stackoverflow.com/questions/5931297/how-would-you-properly-break-this-line-to-match-pep8-rules/17246180#17246180>
(http://stackoverflow.com/a/17246180/70157>).

-- 
 \   “If you're a cowboy and you're dragging a guy behind your |
  `\  horse, I bet it would really make you mad if you looked back |
_o__)and the guy was reading a magazine.” —Jack Handey |
Ben Finney

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

Re: PEP 8 : Maximum line Length :

[Roy Smith]

In article ,
 Ganesh Pal  wrote:

> Hi  Team ,
> 
> 
> what would be the best way to intent the below line .
> 
> I have few lines in my program exceeding the allowed maximum line Length of
> 79./80 characters
> 
> Example 1 :
> 
>p = 
> Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)

The problem here is not so much that you've exceeded 80 columns, but that 
there's no logical
structure which gives your eyes (and your brain) hints about how to parse this. 
 I would
start by adding some white space

>p = Subprocess.Popen(shlex.split(cmd), stdout=subprocess.PIPE, 
> stderr=subprocess.PIPE)

now, at least, it's easier to see where each argument stops and the next one 
starts.  But,
I would really break this up into multiple lines

>p = Subprocess.Popen(shlex.split(cmd),
> stdout=subprocess.PIPE,
> stderr=subprocess.PIPE)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.

[Simon Evans]

Dear Ian,  and other programmers, thank you for your advice. 
I am resending the last message because this twattish cut and paste facility on 
my computer has a knack of chopping off ones original message, I will try to 
convey the right message this time :  

I have removed the original Beautiful Soup 4 download, that I had unzipped to 
my Beautiful Soup directory on the C drive. 
I downloaded the latest version of Beautiful Soup 4 from the Crummy site. 
I unzipped it, and removed the contents of the unzipped directory and placed 
contents in my Beautiful Soup directory, and again had the same output to my 
console re: 

 

Microsoft Windows [Version 6.1.7601] 
Copyright (c) 2009 Microsoft Corporation.  All rights reserved. 

C:\Users\Intel Atom>cd "c:\Beautiful Soup" 

c:\Beautiful Soup>c:\Python27\python setup.py install 

running install
running build
running build_py
error: package directory 'bs4' does not exist


c:\Beautiful Soup> 
--- 
I have made a note of all the contents of the downloaded and unzipped BS4,ie 
the contents of my Beautiful Soup folder on the C drive, which is as follows: 
--- 

running install 
running build 
running build_py 

error: package directory 'bs4' does not existinit 
_html5lib 
_htmlparser 
_lxml 
6.1 
AUTHORS 
conf 
COPYING 
dammit 
demonstration_markup 
element 
index.rst 
Makefile 
NEWS 
PGK-INFO 
README 
setup 
test_builder_registry 
test_docs 
test_html5lib 
test_htmlparser 
text_lxml 
test_soup 
test_tree 
testing 
TODO 

 
I can see no bs4 folder within the contents. 
 I can not see any setup.py file either, but this is how I downloaded it. 
I am only following instructions as suggested. 
I do not understand why it is not working. 
I hope someone can direct me in the right direction, as I seem to be stuck, and 
I don't think it has much bearing on my fluency or lack of it with Python. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.

[Simon Evans]

I have removed the original Beautiful Soup 4 download, that I had unzipped to 
my Beautiful Soup directory on the C drive. 
I downloaded the latest version of Beautiful Soup 4 from the Crummy site. 
I unzipped it, and removed the contents of the unzipped directory and placed 
contents in my Beautiful Soup directory, and again had the same output to my 
console re: 

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\Intel Atom>cd "c:\Beautiful Soup"

c:\Beautiful Soup>c:\Python27\python setup.py install

c:\Beautiful Soup>
---
I have made a note of all the contents of the downloaded and unzipped BS4,ie 
the contents of my Beautiful Soup folder on the C drive, which is as follows:
---
running install
running build
running build_py
error: package directory 'bs4' does not existinit
_html5lib
_htmlparser
_lxml
6.1
AUTHORS
conf
COPYING
dammit
demonstration_markup
element
index.rst
Makefile
NEWS
PGK-INFO
README
setup
test_builder_registry
test_docs
test_html5lib
test_htmlparser
text_lxml
test_soup
test_tree
testing
TODO

I can see no bs4 folder within the contents.
 I can not see any setup.py file either, but this is how I downloaded it.
I am only following instructions as suggested.
I do not understand why it is not working.
I hope someone can direct me in the right direction, as I seem to be stuck, and 
I don't think it has much bearing on my fluency or lack of it with Python. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 : Maximum line Length :

[Rustom Mody]

On Tuesday, May 13, 2014 12:37:24 PM UTC+5:30, Ganesh Pal wrote:
> Hi  Team ,
> 
> 
> what would be the best way to intent the below line .
> 
> I have few lines in my program exceeding the allowed maximum line Length of 
> 79./80 characters 
> 
> 
> Example 1 :
> 
> 
>p = 
> Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)


First rule of python-list: Pay careful attention to Peter Otten.

That said...

80-character limit?!

Sheesh! A relic of the days when terminals were ASCII and 80x24

I wrote about this
http://blog.languager.org/2012/10/layout-imperative-in-functional.html

While its mostly haskell oriented, the comments are amusingly related to this
question in any language:

Comment:
  It is kind of ironic that the blog format wraps your wide code examples at 65 
  chars.

What this goes to show is that while 80 is ridiculously low by most displays 
today,
it is too high for many web/mailing-list fora.

Of course a standard helps in removing superfluous variations.

Still... its 2014 and 80-columns is as current and relevant as ASCII.

PS.

Last rule of python list: Always listen to Peter Otten.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fortran (Was: The "does Python have variables?" debate)

[Gene Heskett]

On Tuesday 13 May 2014 03:22:28 Steven D'Aprano did opine
And Gene did reply:
> On Tue, 13 May 2014 02:31:14 -0400, Gene Heskett wrote:
> > People who write buggy self-modifying code aren't paying attention.
> 
> [...]
> 
> > IMO, people who bad-mouth self-modifying code are folks who don't
> > have the patience to do it right, because stable self-modifying code
> > CAN most certainly be done.
> 
> Many things *can* be done. The question is, is it worth the effort to
> do it? The simplest code that meets the functional requirements is
> usually the best.
> 
> > Stable, dead reliable self modifying code CAN be written, I have done
> > it. And that code was still in use at the tv station that I wrote it
> > for 15 years later.
> 
> Yep, and people have written stable, dead reliable unstructured code
> using GOTO and possibly even COMEFROM too. Nevertheless, nobody serious
> uses unstructured code these days. It takes much more effort to get it
> stable and reliable in the first place. Maintenance is ten or a hundred
> times harder and therefore more expensive. Chances are good that the
> software you wrote 15 years ago is now a black box: it damn well better
> work, because no-one knows how it works well enough to debug problems
> or add new functionality.
> 
> And after 15 years, I daresay that includes you.

Actually, 34 years, but I have the advantage of having retained a copy on 
dead tree as well as a broadcast cart with a couple copies of it, on a 
shelf above where I am sitting.  And, should tape machine ballistics 
change, I left an extensive tome on how to adjust it for that.

The 1802 is a somewhat limited beast, but for all the processing it had to 
do on the falling edge of each vertical drive pulse (it drove the raw, 
homemade character generator to lay a new academy leader among other 
things), it had all the data constructed to generate those characters with 
6 dma cycles per video field, and was all done in the middle of line 21 of 
an ntsc field, twiddling its thumbs until the next falling edge of house 
vertical drive.  I also invented a drop frame version of the time code 
with half the error of the official version. Just because I could.

Cheers, Gene
-- 
"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 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything you did not want to know about Unicode in Python 3

[Roy Smith]

In article ,
 Chris Angelico  wrote:

> On Tue, May 13, 2014 at 4:03 PM, Ben Finney  wrote:
> > (It's always a good day to remind people that the rest of the world
> > exists.)
> 
> Ironic that this should come up in a discussion on Unicode, given that
> Unicode's fundamental purpose is to welcome that whole rest of the
> world instead of yelling "LALALALALA America is everything" and
> pretending that ASCII, or Latin-1, or something, is all you need.

ASCII *is* all I need.  The problem is, it's not all that other people 
need, and I need to interact with those other people.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything you did not want to know about Unicode in Python 3

[alister]

On Tue, 13 May 2014 01:18:35 +, Steven D'Aprano wrote:

> On Mon, 12 May 2014 17:47:48 +, alister wrote:
> 
>> On Mon, 12 May 2014 16:19:17 +0100, Mark Lawrence wrote:
>> 
>>> This was *NOT* written by our resident unicode expert
>>> http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/
>>> 
>>> Posted as I thought it would make a rather pleasant change from
>>> interminable threads about names vs values vs variables vs objects.
>> 
>> Surely those example programs are not the pythonoic way to do things or
>> am i missing something?
> 
> Armin Ronacher is an extremely experienced and knowledgeable Python
> developer, and a Python core developer. He might be wrong, but he's not
> *obviously* wrong.
> 
I am only an amateur python coder which is why I asked if I am missing 
something

I could not see any reason to be using the shutil module if all that the 
programm is doing is opening a file, reading it & then printing it.

is it python that causes the issue, the shutil module or just the OS not 
liking the data it is being sent?

an explanation of why this approach is taken would be much appreciated.



-- 
Revenge is a form of nostalgia.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fortran (Was: The "does Python have variables?" debate)

[Chris Angelico]

On Tue, May 13, 2014 at 9:16 PM, Roy Smith  wrote:
> Sometimes code is still running for 15 years because it's so wonderful
> nobody has been able to come up with anything better.  Sometimes it's
> because nobody knows how it works anymore and everybody is afraid to
> touch it :-)

And sometimes, both...

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

Re: Fortran (Was: The "does Python have variables?" debate)

[Roy Smith]

In article <5371c834$0$11109$c3e8...@news.astraweb.com>,
 Steven D'Aprano  wrote:

> And after 15 years, I daresay that includes you.

Sometimes code is still running for 15 years because it's so wonderful 
nobody has been able to come up with anything better.  Sometimes it's 
because nobody knows how it works anymore and everybody is afraid to 
touch it :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: SQLAlchemy - web framework ?

[Roy Smith]

In article ,
 flebber  wrote:

> Roy.that is interesting that you can use mongoengine. 
> 
> Recent google results such as seem to assert there are a lot of inherent risk 
> in swapping out components, though I may be misinterpreting it. 
> http://www.slideshare.net/daikeren/tradeoffs-of-replacing-core-components

I wouldn't take every slideshow I find on the net as gospel.  There is 
risk in doing anything.  The only slide I find of much value in that 
deck is 22, but that's pretty much a requirement anyway.  Most of the 
rest is just fear mongering.

FWIW, we don't use any third-party packages, and we don't use the admin.  
If those things are important to you, then I agree, swapping out the ORM 
will be interesting.  Mostly what we use from django are the middleware 
framework (we write a lot of our own middleware), url parsing, and view 
dispatch.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Simple Function Decorator Sample Snippet

[alister]

On Tue, 13 May 2014 01:04:39 -0500, Mark H Harris wrote:
> Yes, because depending on your interface the code can get mangled (the
> indentation thing breaks).  the quoted paste seems to avoid this mostly
> with the downside that the quote characters need to be striped from the
> py file.  by the way, any suggestions are welcome regarding
> that too...  there doesn't really seem to be a good way to share code on
> the group consistently.

use a news reader rather than Google groups 

BTW documenting decorators is a good idea even if only for your own use. 
it has taken me a long type to groc decorators & see any reason why I 
would use one rather than just modifying my function.
(I finally got it when mucking about with wsgi where I used a couple of 
decorators to prepend & append header & footer files to various other 
functions, reducing code duplication significantly 




-- 
WHO sees a BEACH BUNNY sobbing on a SHAG RUG?!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fortran (Was: The "does Python have variables?" debate)

[Chris Angelico]

On Tue, May 13, 2014 at 8:44 PM, Rustom Mody  wrote:
> On Tuesday, May 13, 2014 3:30:36 PM UTC+5:30, Chris Angelico wrote:
>> Actually, even the file system can do some of this to you. I was
>> checking lsof on one of my Linux systems a little while ago, and found
>> that I had half a dozen old versions of a program, all with the same
>> file name, all deleted. (When you unlink a running binary on Linux,
>> the program keeps running the old version, and then you can put a new
>> version in its place, with the same file name. Any new invocation will
>> pick up the new binary; existing ones keep what they have.) So a
>> program can unlink itself, write out a new version of itself, and
>> happily keep going - letting new invocations take the changed version,
>> safely. Again, not exactly self-modifying code... or is it? Again,
>> tamed by boundaries.
>
> Your lsof example looks like a rather typical case of ugly self-modifying code
> Self-modifying code has many flavours; consider:
>
> $ sudo apt-get upgrade apt-get
>
> relatively harmless but self-modifying nonetheless
>

Heh. Those are going to be exactly the same. (In actual fact, it was a
"sudo make install" that created the situation I described.) The only
difference is that you probably don't have any other instances of
apt-get running, meaning the change takes place for the next run - but
while that's running, you would see the old /usr/bin/apt-get as a
deleted and open file.

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

Re: Fortran (Was: The "does Python have variables?" debate)

[Rustom Mody]

On Tuesday, May 13, 2014 3:30:36 PM UTC+5:30, Chris Angelico wrote:
> Actually, even the file system can do some of this to you. I was
> checking lsof on one of my Linux systems a little while ago, and found
> that I had half a dozen old versions of a program, all with the same
> file name, all deleted. (When you unlink a running binary on Linux,
> the program keeps running the old version, and then you can put a new
> version in its place, with the same file name. Any new invocation will
> pick up the new binary; existing ones keep what they have.) So a
> program can unlink itself, write out a new version of itself, and
> happily keep going - letting new invocations take the changed version,
> safely. Again, not exactly self-modifying code... or is it? Again,
> tamed by boundaries.

Your lsof example looks like a rather typical case of ugly self-modifying code
Self-modifying code has many flavours; consider:

$ sudo apt-get upgrade apt-get

relatively harmless but self-modifying nonetheless

When its more invisible its more dangerous

# apt-get upgrade linux-image

My understanding of Mark Harris' original reference to 'self-modifying' is a 
more
standard, ubiquitous, ugly but indispensable example -- the use of the
interactive interpreter.

I write a function:
def foo()...
   ... recursive use of foo()

I then rename the foo to FOO but forget to rename the internal call
For normal file/module loading one would get a straightforward error message
At the interactive interpreter one gets massive confusion.

Does it mean we stop playing around in the interactive environment?
Hopefully not!
But there are pitfalls and its good to be straight about them.

As far as I can see, recursivity is the foundation of our field;
self-modifying code, self-reference (y-combinator) are just some of its
many faces:
http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fortran (Was: The "does Python have variables?" debate)

[Chris Angelico]

On Tue, May 13, 2014 at 7:34 PM, Steven D'Aprano  wrote:
> On Tue, 13 May 2014 15:56:50 +1000, Chris Angelico wrote:
>
>> On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano 
>> wrote:
>>> Self-modifying code is a nightmare inside the head of a Lovecraftian
>>> horror. There's a reason why almost the only people still using self-
>>> modifying code are virus writers, and the viruses they create are
>>> notorious for being buggy.
>>
>> Hmm... what counts as self-modifying, though?
>
> Code that modifies itself, as opposed to code that modifies other code.

Duh :)

>> When you decorate a
>> function to modify its behaviour (eg add caching around it), all the
>> modification happens at compile time,
>
> Not in Python it doesn't. Functions are created at runtime -- def is a
> statement, and it runs at runtime. But that's actually irrelevant.

Yes, but that's still the "initialization phase" of the code. When I
think of self-modifying code, I think of something that could do this:

def some_func(x):
if x<0:
change_bottom_of_function
x = -x
result = calculate_stuff(x)
return result # becomes "return -result" if change done

Effectively, instead of using a stack or heap entry to record state,
it uses its own code. (And the above example is buggy, too. That's
part of why this is a bad idea - it's not obvious when there are
bugs.)

With a decorated function, the change happens at the time the def is
executed. With the above example, the change happens when the function
is called. That's what I meant by "compile time", although I did pick
a poor term for it. Is there a better word for that? There's three
phases, if you like - compilation, execution of def, and execution of
function.

>> but it's still executing something
>> other than what you see as the bald code.
>
> I don't think so. ... there's no *self-modification* going on.
> You can write obfuscated code with decorators, but you can
> shoot yourself in the foot with just about any tool. Fundamentally,
> decorators are more or less just a way of doing function composition.

Right. I would agree here. It's confusing if it completely changes
itself, but it's not really self-modifying.

>> What about a microkernel that
>> can load altered code from the disk, compile it into memory, and replace
>> portions of itself?
>
> Now we're talking self-modification.

Technically not - that's why I said microkernel. The kernel never
changes *itself*, it just loads other code into memory (and can switch
out submodules). It's not so clear-cut. The program, as a whole, is
changing its own behaviour, but by separating "this bit can change"
from "this bit manages the changes", you tame the self-modification -
just as you say further down.

> But of course there are degrees of
> self-modification. This isn't too bad, because it's relatively simple to
> follow what happens next:
>
> def foo(x):
> global foo  # Change me.
> foo = new_foo
> return bar(x)
>
> This is to self-modifying code what break and continue are to GOTO --
> tamed, trained, on a leash, and pretty safe.

Yeah. It's safe because it's atomic and clean.

>> Or a JIT compiler. As you run something, it gets
>> changed in form to be more streamlined.
>
> I wouldn't call that self-modifying code, because the compiler isn't
> modifying itself. It's modifying the code being run.

Again, technically. But if the compiler is deemed to be part of the
program (it often won't be - V8 with your JavaScript code and PyPy
with your Python code are separate - but it would be possible to
consider them to be the same effective unit), then it's exactly the
same as the microkernel example above: tamed self-modification, with
one piece modifying the other(s).

> But note that JIT compilers are optimizing compilers (there's little
> point, otherwise), and highly optimized code is notorious for being hard
> to debug and containing subtle, hard to find, harder to fix, bugs. Why
> are they hard to debug? Because the code that you read is not necessarily
> the same as the code being run.

Right, and that's exactly where the risk is. Every translation between
you and what's run is a potential source of horribly insidious bugs.
That's why it's absolutely essential to put bounds on the insatiable
ambition for automutability. In the microkernel case, and also with a
similar (but horribly less efficient) structure that I did a couple of
times with DLLs, there's a clear protocol with "this file provides
these public symbols", and that protocol doesn't much change with
reloads. With a JIT compiler, the code should have the exact same
effect before and after the change, and just be faster. And so on. By
clearly delineating what can change and what can't, you divide any
debugging job down to smaller pieces.

Actually, even the file system can do some of this to you. I was
checking lsof on one of my Linux systems a little while ago, and found
that I had half a dozen old versions of a program, all with the same
file

Re: Everything you did not want to know about Unicode in Python 3

[Marko Rauhamaa]

Johannes Bauer :

> The only people who are angered by this now is people who always
> treated encodings sloppily and it "just worked". Well, there's a good
> chance it has worked by pure chance so far. It's a good thing that
> Python does this now more strictly as it gives developers *guarantees*
> about what they can and cannot do with text datatypes without having
> to deal with encoding issues in many places. Just one place: The
> interface where text is read or written, just as it should be.

I'm not angered by text. I'm just wondering if it has any practical use
that is not misuse...

For example, Py3 should not make any pretense that there is a "default"
encoding for strings. Locale's are an abhorrent invention from the early
8-bit days. IOW, you should never input or output text without explicit
serialization.

I get the feeling that Py3 would like to present a world where strings
are first-class I/O objects that can exist in files, in filenames,
inside pipes. You say, "text is read or written." I'm saying text is
never read or written. It only exists as an abstraction (not even
unicode) inside the virtual machine.


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

Re: How can this assert() ever trigger?

[Albert van der Horst]

In article ,
Joseph Martinot-Lagarde   wrote:
>Le 10/05/2014 17:24, Albert van der Horst a écrit :
>> I have the following code for calculating the determinant of
>> a matrix. It works inasfar that it gives the same result as an
>> octave program on a same matrix.
>>
>> / 
>>
>> def determinant( mat ):
..
>>  result = lastr[jx]
>>  assert(result<>0.)
...
>>  assert(result<>0.)
>>  nom *= result   # Compenstate for multiplying a row.
...
>>  assert(nom<>0.)
..
>>
>> /-
>>
>> Now on some matrices the assert triggers, meaning that nom is zero.
>> How can that ever happen? mon start out as 1. and gets multiplied
>> with a number that is asserted to be not zero.
>>
>> Any hints appreciated.
>>
>> Groetjes Albert
>>
>I know it's not the question, but if you want a replacement for octave
>did you try numpy (and scipy) ? The determinant would be computer faster
>and with less memory than with your function.

I'm using several programming languages in a mix to solve Euler problems.
This is about learning how octave compares to python for a certain kind of
problem as anything.
The determinant program I had lying around, but it was infinite precision
with integer only arithmetic. Then I made a simple modification and got
mad because I didn't understand why it didn't work.

I have used numpy and its det before, but I find it difficult to
remember how to create a matrix in numpy. This is the kind of thing
that is hard to find in the docs. Now I looked it up in my old
programs: you start a matrix with the zeroes() function.

I expect the built in determinant of octave to be on a par with corresponding
python libraries.

>
>---

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

Re: Everything you did not want to know about Unicode in Python 3

[Johannes Bauer]

On 13.05.2014 10:25, Marko Rauhamaa wrote:

> Based on my background (network and system programming), I'm a bit
> suspicious of strings, that is, text. For example, is the stuff that
> goes to syslog bytes or text? Does an XML file contain bytes or
> (encoded) text? The answers are not obvious to me. Modern computing is
> full of ASCII-esque binary communication standards and formats.

Traditional Unix programs (syslog for example) are notorious for being
clear, ambiguous and/or ignorant of character encodings altogether. And
this works, unfortunately, for the most time because many encodings
share a common subset. If they wouldn't, the problems would be VERY
apparent and people would be forced to handle the issues not so sloppily.

Which is the route that Py3 chose. Don't be sloppy, make a great
distinction between "text" (which handles naturally as strings) and its
respective encoding.

The only people who are angered by this now is people who always treated
encodings sloppily and it "just worked". Well, there's a good chance it
has worked by pure chance so far. It's a good thing that Python does
this now more strictly as it gives developers *guarantees* about what
they can and cannot do with text datatypes without having to deal with
encoding issues in many places. Just one place: The interface where text
is read or written, just as it should be.

Regards,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 : Maximum line Length :

[alister]

On Tue, 13 May 2014 10:45:49 +0200, Peter Otten wrote:

> Ganesh Pal wrote:
> 
>> Hi  Team ,
>> 
>> 
>> what would be the best way to intent the below line .
>> 
>> I have few lines in my program exceeding the allowed maximum line
>> Length of 79./80 characters
>> 
>> Example 1 :
>> 
>>p =
>> 
> Subprocess.Popen(shlex.split
(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)
>> 
>> 
>> Iam running pylint and it says  the above line is tool long how do I
>> limit it to 79 character without violating any rules
>> 
>> * Module isi_corrupt C: 14,0: Line too long (88/80)
>> W: 19,0: Bad indentation. Found 6 spaces, expected 8
> 
> (1) Newlines are allowed inside an open (, [, or {. So:
> 
> p = subprocess.Popen(
> shlex.split(cmd), stdout=subprocess.PIPE,
> stderr=subprocess.PIPE)
> 
> Other techniques:
> 
> (2) Introduce helper variables:
> 
> cmd = shlex.split(cmd)
> p = subprocess.Popen(cmd, stdout=subprocess.PIPE,
> stderr=subprocess.PIPE)
> 
> (3) Import names:
> 
> from subprocess import PIPE p = subprocess.Popen(shlex.split(cmd),
> stdout=PIPE, stderr=PIPE)
> 
> (4) Use aliases:
> 
> import subprocess as sp p = sp.Popen(shlex.split(cmd), stdout=sp.PIPE,
> stderr=sp.PIPE)

or simply leave it alone
Pep 8 is a guide not a "Set in Stone" rule & even pep 8 does say that the 
80 character limit can be exceeded if breaking the line would make the 
code less readable





-- 
Catastrophic failure of the IDE cable???.
What are you doing to the poor thing, jumping on it?

- Beau Kuiper on linux-kernel
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything you did not want to know about Unicode in Python 3

[Steven D'Aprano]

On Tue, 13 May 2014 12:06:50 +0300, Marko Rauhamaa wrote:

> Chris Angelico :
> 
>> These are problems that Unicode can't solve.
> 
> I actually think the problem has little to do with Unicode. Text is an
> abstract data type just like any class. If I have an object (say, a
> subprocess or a dictionary) in memory, I don't expect the object to have
> any existence independently of the Python virtual machine. I have the
> same feeling about Py3 strings: they only exist inside the Python
> virtual machine.

And you would be correct. When you write them to a device (say, push them 
over a network, or write them to a file) they need to be serialized. If 
you're lucky, you have an API that takes a string and serializes it for 
you, and then all you have to deal with is:

- am I happy with the default encoding?

- if not, what encoding do I want?

Otherwise you ought to have an API that requires bytes, not strings, and 
you have to perform your own serialization by encoding it.

But abstractions leak, and this abstraction leaks because *right now* 
there isn't a single serialization for text strings. There are HUNDREDS, 
and sometimes you don't know which one is being used.


[...]
> What I'm saying is that strings definitely have an important application
> in the human interface. However, I feel strings might be overused in the
> Py3 API. Case in point: are pathnames bytes objects or strings?

Yes. On POSIX systems, file names are sequences of bytes, with a very few 
restrictions. On recent Windows file systems (NTFS I believe?), file 
names are Unicode strings encoded to UTF-16, but with a whole lot of 
other restrictions imposed by the OS.


> The
> linux position is that they are bytes objects. Py3 supports both
> interpretations seemingly throughout:
> 
>open(b"/bin/ls")vsopen("/bin/ls") os.path.join(b"a", b"b")   
>vsos.path.join("a", "b")

Because it has to, otherwise there will be files that are unreachable on 
one platform or another.


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

Re: Everything you did not want to know about Unicode in Python 3

[Johannes Bauer]

On 13.05.2014 10:38, Chris Angelico wrote:

>> Python 2's ambiguity allows me not to answer the tough philosophical
>> questions. I'm not saying it's necessarily a good thing, but it has its
>> benefits.
> 
> It's not a good thing. It means that you have the convenience of
> pretending there's no problem, which means you don't notice trouble
> until something happens... and then, in all probability, your app is
> in production and you have no idea why stuff went wrong.

Exactly. With Py2 "strings" you never know what encoding they are, if
they already have been converted or something like that. And it's very
well possible to mix already converted strings with other, not yet
encoded strings. What a mess!

All these issues are avoided by Py3. There is a very clear distinction
between strings and string representation (data bytes), which is
beautiful. Accidental mixing is not possible. And you have some thing
*guaranteed* for the string type which aren't guaranteed for the bytes
type (for example when doing string manipulation).

Regards,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ctypes does not load .dll and generate windowsError 127

[Chris Angelico]

On Tue, May 13, 2014 at 6:45 PM, Ji Xia  wrote:
> Could anybody help me out? I am trying to use python ctypes and load a .dll
> file. It works on my colleagues’ machine, just does not work on mine
>
> Python on my machine is : python 2.7.6
>
> OS: windows 7
>
> Result is always:
>
>   File "C:\Python27\Lib\ctypes\__init__.py", line 365, in __init__
>
> self._handle = _dlopen(self._name, mode)
>
> WindowsError: [Error 127] The specified procedure could not be found
>
>

It would help to know what DLL you're loading. Are you copying the
exact same DLL file from one computer to the other, or referencing
something that's already there?

It may be that the DLL you name is statically linked to another DLL,
and it's the second one that's causing problems. In that case, even
copying the file across won't solve the problem. Look for a DLL
dependency tree program (you can find them at the other end of a web
search) and see if you have versioning issues.

This isn't actually a Python problem, it's all to do with the loading
of that DLL.

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

Re: Fortran (Was: The "does Python have variables?" debate)

[Steven D'Aprano]

On Tue, 13 May 2014 15:56:50 +1000, Chris Angelico wrote:

> On Tue, May 13, 2014 at 3:48 PM, Steven D'Aprano 
> wrote:
>> Self-modifying code is a nightmare inside the head of a Lovecraftian
>> horror. There's a reason why almost the only people still using self-
>> modifying code are virus writers, and the viruses they create are
>> notorious for being buggy.
> 
> Hmm... what counts as self-modifying, though? 

Code that modifies itself, as opposed to code that modifies other code.


> When you decorate a
> function to modify its behaviour (eg add caching around it), all the
> modification happens at compile time, 

Not in Python it doesn't. Functions are created at runtime -- def is a 
statement, and it runs at runtime. But that's actually irrelevant.


> but it's still executing something
> other than what you see as the bald code. 

I don't think so. Whether I write:

@cache
def function(args):
...


or even the old pre-decorator style:

def function(args):
...

function = cache(function)


there's no *self-modification* going on. The trickiest thing about this 
is that the code for function is now split over two places, cache and 
function itself. But that's not much trickier than:

def cache(x):
...

def function(x):
cache(x)
...

or similar. You can write obfuscated code with decorators, but you can 
shoot yourself in the foot with just about any tool. Fundamentally, 
decorators are more or less just a way of doing function composition.


> What about a microkernel that
> can load altered code from the disk, compile it into memory, and replace
> portions of itself? 

Now we're talking self-modification. But of course there are degrees of 
self-modification. This isn't too bad, because it's relatively simple to 
follow what happens next:

def foo(x):
global foo  # Change me.
foo = new_foo
return bar(x)

This is to self-modifying code what break and continue are to GOTO -- 
tamed, trained, on a leash, and pretty safe.



> I've done that a number of times (not in Python as
> it has little support for it, but in Pike it's easy); is that
> self-modifying code? 

Yes.


> Or a JIT compiler. As you run something, it gets
> changed in form to be more streamlined. 

I wouldn't call that self-modifying code, because the compiler isn't 
modifying itself. It's modifying the code being run.

But note that JIT compilers are optimizing compilers (there's little 
point, otherwise), and highly optimized code is notorious for being hard 
to debug and containing subtle, hard to find, harder to fix, bugs. Why 
are they hard to debug? Because the code that you read is not necessarily 
the same as the code being run.


> None of these is as horrible as
> the loop that fiddles with its own code on the fly, but any of them, if
> buggy, will have the same effect. And all are useful.

Many things are potentially useful, nevertheless we mostly avoid them 
because the cost is greater than the benefit.



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

Re: Everything you did not want to know about Unicode in Python 3

[Chris Angelico]

On Tue, May 13, 2014 at 7:06 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> These are problems that Unicode can't solve.
>
> I actually think the problem has little to do with Unicode. Text is an
> abstract data type just like any class. If I have an object (say, a
> subprocess or a dictionary) in memory, I don't expect the object to have
> any existence independently of the Python virtual machine. I have the
> same feeling about Py3 strings: they only exist inside the Python
> virtual machine.

That's true; the only difference is that text is extremely prevalent.
You can share a dict with another program, or store it in a file, or
whatever, simply by agreeing on an encoding - for instance, JSON. As
long as you and the other program know that this file is JSON encoded,
you can write it and he can read it, and you'll get the right data at
the far end. It's no different; there are encodings that are easy to
handle and have limitations, and there are encodings that are
elaborate and have lots of features (XML comes to mind, although
technically you can't encode a dict in XML).

> Case in point: are pathnames bytes objects or strings? The
> linux position is that they are bytes objects. Py3 supports both
> interpretations seemingly throughout:
>
>open(b"/bin/ls")vsopen("/bin/ls")
>os.path.join(b"a", b"b")vsos.path.join("a", "b")

That's a problem that comes from the underlying file systems. If every
FS in the world worked with Unicode file names, it would be easy.
(Most would encode them onto the platters in UTF-8 or maybe UTF-16;
some might choose to use a PEP 393 or Pike string structure, with the
size_shift being a file mode just like the 'directory' bit; others
might use a limited encoding for legacy reasons, storing uppercased
CP437 on the disk, and returning an error if the desired name didn't
fit.) But since they don't, we have to cope with that. What happens if
you're running on Linux, and you have a mounted drive from an OS/2
share, and inside that, you access an aliased drive that represents a
Windows share, on which you've mounted a remote-backup share? A single
path name could have components parsed by each of those systems, so
what's its encoding? How do you handle that? There's no solution.
(Well, okay. There is a solution: don't do something so stupidly
convoluted. But there's no law against cackling admins making circular
mounts. In fact, I just mounted my own home directory as a
subdirectory under my home directory, via sshfs. I can now encrypt my
own file reads and writes exactly as many times as I choose to. I also
cackled.)

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

ctypes does not load .dll and generate windowsError 127

[Ji Xia]

Hi all,

Could anybody help me out? I am trying to use python ctypes and load a .dll 
file. It works on my colleagues' machine, just does not work on mine

Python on my machine is : python 2.7.6
OS: windows 7

Result is always:
  File "C:\Python27\Lib\ctypes\__init__.py", line 365, in __init__
self._handle = _dlopen(self._name, mode)
WindowsError: [Error 127] The specified procedure could not be found

Does anybody could help me out?

Thanks

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

Re: Everything you did not want to know about Unicode in Python 3

[Marko Rauhamaa]

Chris Angelico :

> These are problems that Unicode can't solve.

I actually think the problem has little to do with Unicode. Text is an
abstract data type just like any class. If I have an object (say, a
subprocess or a dictionary) in memory, I don't expect the object to have
any existence independently of the Python virtual machine. I have the
same feeling about Py3 strings: they only exist inside the Python
virtual machine.

An abstract object like a subprocess or dictionary justifies its
existence through its behaviour (its quacking). Now, do strings quack or
are they silent? I guess if you are writing a word processor they might
quack to you. Otherwise, they are just an esoteric storage format.

What I'm saying is that strings definitely have an important application
in the human interface. However, I feel strings might be overused in the
Py3 API. Case in point: are pathnames bytes objects or strings? The
linux position is that they are bytes objects. Py3 supports both
interpretations seemingly throughout:

   open(b"/bin/ls")vsopen("/bin/ls")
   os.path.join(b"a", b"b")vsos.path.join("a", "b")


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

Re: PEP 8 : Maximum line Length :

[Peter Otten]

Ganesh Pal wrote:

> Hi  Team ,
> 
> 
> what would be the best way to intent the below line .
> 
> I have few lines in my program exceeding the allowed maximum line Length
> of 79./80 characters
> 
> Example 1 :
> 
>p =
> 
Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)
> 
> 
> Iam running pylint and it says  the above line is tool long how do I limit
> it to 79 character without violating any rules
> 
> * Module isi_corrupt
> C: 14,0: Line too long (88/80)
> W: 19,0: Bad indentation. Found 6 spaces, expected 8

(1) Newlines are allowed inside an open (, [, or {. So:

p = subprocess.Popen(
shlex.split(cmd),
stdout=subprocess.PIPE,
stderr=subprocess.PIPE)

Other techniques:

(2) Introduce helper variables:

cmd = shlex.split(cmd)
p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

(3) Import names:

from subprocess import PIPE
p = subprocess.Popen(shlex.split(cmd), stdout=PIPE, stderr=PIPE)

(4) Use aliases:

import subprocess as sp
p = sp.Popen(shlex.split(cmd), stdout=sp.PIPE, stderr=sp.PIPE)


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

Re: Everything you did not want to know about Unicode in Python 3

[Chris Angelico]

On Tue, May 13, 2014 at 6:25 PM, Marko Rauhamaa  wrote:
> Johannes Bauer :
>
>> Having dealt with the UTF-8 problems on Python2 I can safely say that
>> I never, never ever want to go back to that freaky hell. If I deal
>> with strings, I want to be able to sanely manipulate them and I want
>> to be sure that after manipulation they're still valid strings.
>> Manipulating the bytes representation of unicode data just doesn't
>> work.
>
> Based on my background (network and system programming), I'm a bit
> suspicious of strings, that is, text. For example, is the stuff that
> goes to syslog bytes or text? Does an XML file contain bytes or
> (encoded) text? The answers are not obvious to me. Modern computing is
> full of ASCII-esque binary communication standards and formats.

These are problems that Unicode can't solve. In theory, XML should
contain text in a known encoding (defaulting to UTF-8). With syslog,
it's problematic - I don't remember what it's meant to be, but I know
there are issues. Same with other log files.

> Python 2's ambiguity allows me not to answer the tough philosophical
> questions. I'm not saying it's necessarily a good thing, but it has its
> benefits.

It's not a good thing. It means that you have the convenience of
pretending there's no problem, which means you don't notice trouble
until something happens... and then, in all probability, your app is
in production and you have no idea why stuff went wrong.

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

Re: Everything you did not want to know about Unicode in Python 3

[Marko Rauhamaa]

Johannes Bauer :

> Having dealt with the UTF-8 problems on Python2 I can safely say that
> I never, never ever want to go back to that freaky hell. If I deal
> with strings, I want to be able to sanely manipulate them and I want
> to be sure that after manipulation they're still valid strings.
> Manipulating the bytes representation of unicode data just doesn't
> work.

Based on my background (network and system programming), I'm a bit
suspicious of strings, that is, text. For example, is the stuff that
goes to syslog bytes or text? Does an XML file contain bytes or
(encoded) text? The answers are not obvious to me. Modern computing is
full of ASCII-esque binary communication standards and formats.

Python 2's ambiguity allows me not to answer the tough philosophical
questions. I'm not saying it's necessarily a good thing, but it has its
benefits.


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

Re: Everything you did not want to know about Unicode in Python 3

[Johannes Bauer]

On 13.05.2014 03:18, Steven D'Aprano wrote:

> Armin Ronacher is an extremely experienced and knowledgeable Python 
> developer, and a Python core developer. He might be wrong, but he's not 
> *obviously* wrong.

He's correct about file name encodings. Which can be fixed really easily
wihtout messing everything up (sys.argv binary variant, open accepting
binary filenames). But that he suggests that Go would be superior:

> Which uses an even simpler model than Python 2: everything is a byte string. 
> The assumed encoding is UTF-8. End of the story.

Is just a horrible idea. An obviously horrible idea, too.

Having dealt with the UTF-8 problems on Python2 I can safely say that I
never, never ever want to go back to that freaky hell. If I deal with
strings, I want to be able to sanely manipulate them and I want to be
sure that after manipulation they're still valid strings. Manipulating
the bytes representation of unicode data just doesn't work.

And I'm very very glad that some people felt the same way and
implemented a sane, consistent way of dealing with Unicode in Python3.
It's one of the reasons why I switched to Py3 very early and I love it.

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa 
-- 
https://mail.python.org/mailman/listinfo/python-list

ANN: verynice 0.3 - a nice(1) like utility for throttling processes

[garabik-news-2005-05]

verynice is a nice(1)-like command line utility for unix systems to
throttle long running processes beyond what can be achieved by nice(1),
by repeatedly suspending and resuming the process.

Author:
Radovan Garabík

URL:
http://kassiopeia.juls.savba.sk/~garabik/software/verynice/

License:
GPL (v3)

-- 
 ---
| Radovan Garabík http://kassiopeia.juls.savba.sk/~garabik/ |
| __..--^^^--..__garabik @ kassiopeia.juls.savba.sk |
 ---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything you did not want to know about Unicode in Python 3

[gregor]

Am 13 May 2014 01:18:35 GMT
schrieb Steven D'Aprano :

> 
> - have a simple way to write bytes to stdout and stderr.

there is the underlying binary buffer:

https://docs.python.org/3/library/sys.html#sys.stdin

greg

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

Re: Fortran (Was: The "does Python have variables?" debate)

[Steven D'Aprano]

On Tue, 13 May 2014 02:31:14 -0400, Gene Heskett wrote:

> People who write buggy self-modifying code aren't paying attention.
[...]
> IMO, people who bad-mouth self-modifying code are folks who don't have
> the patience to do it right, because stable self-modifying code CAN most
> certainly be done.

Many things *can* be done. The question is, is it worth the effort to do 
it? The simplest code that meets the functional requirements is usually 
the best.



> Stable, dead reliable self modifying code CAN be written, I have done
> it. And that code was still in use at the tv station that I wrote it
> for 15 years later.  

Yep, and people have written stable, dead reliable unstructured code 
using GOTO and possibly even COMEFROM too. Nevertheless, nobody serious 
uses unstructured code these days. It takes much more effort to get it 
stable and reliable in the first place. Maintenance is ten or a hundred 
times harder and therefore more expensive. Chances are good that the 
software you wrote 15 years ago is now a black box: it damn well better 
work, because no-one knows how it works well enough to debug problems or 
add new functionality.

And after 15 years, I daresay that includes you.


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

Re: Why isn't my re.sub replacing the contents of my MS Word file?

[Dave Angel]

On 05/12/2014 01:35 PM, scottca...@gmail.com wrote:

On Friday, May 9, 2014 8:12:57 PM UTC-4, Steven D'Aprano wrote:


Good:



 # Untested

 fStr = re.sub(b'&#x(201[2-5])|(2E3[AB])|(00[2A]D)', b'-', fStr)


   Still doesn't work.

   Guess whatever the code is for endash and mdash are not the ones I am 
using



More likely, your MSWord document isn't a simple text file.  Some 
encodings don't resemble ASCII or Unicode in the least.


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

PEP 8 : Maximum line Length :

[Ganesh Pal]

Hi  Team ,


what would be the best way to intent the below line .

I have few lines in my program exceeding the allowed maximum line Length of
79./80 characters

Example 1 :

   p =
Subprocess.Popen(shlex.split(cmd),stdout=subprocess.PIPE,stderr=subprocess.PIPE)


Iam running pylint and it says  the above line is tool long how do I limit
it to 79 character without violating any rules

* Module isi_corrupt
C: 14,0: Line too long (88/80)
W: 19,0: Bad indentation. Found 6 spaces, expected 8


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

Twisted 14.0.0 Release Announcement

[HawkOwl]

On behalf of Twisted Matrix Laboratories, I am honoured to announce the release 
of Twisted 14.0! It has been a long road to get here, but we’ve done it! 

The highlights of this release are:

- Twisted Positioning (`twisted.positioning`) makes its entry into Twisted! It 
comes ready to talk with common GPS devices, and will supersede 
`twisted.protocols.gps`.

- A wealth of SSL/TLS improvements, including ECDHE support, TLS Service 
Identity (with service_identity on PyPI), a stronger default set of ciphers, 
and strengthening against attacks such as CRIME. A Twisted Web server with 
pyOpenSSL 0.14 is capable of getting an A in Qualys SSL Labs tests out of the 
box, and A+ with small application modifications. Twisted Agent can also now do 
HTTPS hostname verification.

- Python 3 improvements, including the ability for `pip install` to install all 
ported modules.

- Twisted Pair’s TUN/TAP support has been overhauled, with documentation and 
full test coverage.

- Significant documentation improvements, including more API documentation for 
Twisted Mail & Twisted Names, narrative documentation for Twisted Names, and a 
migration to Sphinx for building Twisted narrative docs.

- Support is dropped for pyOpenSSL older than 0.10 and Windows XP.

You can find the downloads at  (or 
alternatively ) .

Many thanks to everyone who had a part in this release - we’ve got some big 
things landed, and if it weren’t for the support of developers (both core and 
occasional), the Twisted Software Foundation, or people giving feedback and 
filing bugs, we’d have never got it done.

Twisted Regards,
HawkOwl


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
https://mail.python.org/mailman/listinfo/python-list