date:20140515

On Thursday, May 15, 2014 4:55:42 PM UTC+5:30, Simon Evans wrote:
 Dear Programmers,
 
 As anticipated, it has not been to long before I have encountered further 
 
 difficulty. At the top of page 16 of 'Getting Started with Beautiful Soup it 
 
 gives code to be input, whether to the Python or Windows command prompt I am 
 not 
 
 sure, but both seem to be resistant to it. I quote the response to the code 
 below, 

It was because I thought I saw such a mixup in your earlier posts that
I suggested you start with the python tutorial :-)
 Looking at the bottom of page 16, there is more code for the inputting of, 
 that 
 
 
 
 again does not take to the Windows Command Prompt or the Python command 
 prompt,
 
 re:  import urllib2
 
  from bs4 import BeautifulSoup

You probably need the above line
And you need to preceded the other lines at the python (not shell) prompt

On the whole it may be a good idea to put aside the book and just follow the 
quick start http://www.crummy.com/software/BeautifulSoup/bs4/doc/#quick-start

at the python prompt

 
  url = http://www.packtpub.com/books;
 
  page = urllib2.urlopen(url)
 
  soup_packtpage = BeautifulSoup(page)
 
 
 
 returns to the Windows Command prompt:- 
 
 --
 
 import urllib2
 
 Traceback (most recent call last):
 
   File stdin, line1, in module
 
 ImportError: No module named 'urllib2'
 
 
 
 
 
 --
 
 returns to the Python command prompt :- 
 
 --
 
  import urllib2
 
  from bs4 import BeautifulSoup
 
  url = http://www.packtpub.com/books;
 
  page = urllib2.urlopen(url)
 
 Traceback (most recent call last):
 
 File C\Python27\lib\urllib2.py,line 127, in urlopen
 
   return_opener.open(url, data, timeout)
 
 File C:\Python27\lib\urllib2.py,line 410, in open
 
 response = meth(req, response)
 
 File C:\Pyton27\lib\urllib2.py, oine 523, in http_response
 
 'http', request, response, code, msg, hdrs)
 
 FileC:\Python27\lib\urllib2.py, line 448, in error
 
 return self._call_chain(*args)
 
 File C:/Python27/lib/urllib2.py,line 382, in _call_chain
 
 result = func(*args)
 
 File C:\Python27\lib\urllib2.py, line 531, in http_error_default
 
 raise HTTPError(req.get_full_url(), code, masg, hdrs, fp)
 
 urllib2.HTTPError: HTTP Error 403: Forbidden
 
 -
 
 Anway I hope you can tell me what is amiss, there is no point in my 
 proceeding 
 
 
 
 with the book (about 111 pages all told) until I find out why it won't take. 
 
 I realise I have been told to learn python in order to make things less 
 painful, 
 
 
 
 but I don't see why code written in the book does not take. 
 
 Thank you for reading.
 
 
 
 
 
 
 
 
 
 
 
 I thought I might as well include, so's you might be able to see where things 
 are 
 
 
 
 going astray. The Windows command prompt :-

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

Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Johannes Bauer

On 15.05.2014 04:43, Ben Finney wrote:
 Rustom Mody rustompm...@gmail.com writes:
 
 Until then may we relegate '79' to quaint historical curiosities
 
 Not until the general capacity of human cognition advances to make
 longer lines easier to read.

I find it surprising how you can make such a claim about the whole of
humanity (!) without even feeling the need to have a pro forma study to
back it up. Also, not everything that applies to prose also equally
applies to code.

Personally I find overly narrow code (80 cols) to be much *harder* to
read than code that is 100 cols wide. Keep in mind that even if the
break is at 100 cols, lines will rarely exceed that limit. And if they
do to *understand* the code, the further down the line it is the less
important are the details usually.

I don't know why anyone would force a display issue onto everyone. It
imples the arrogant stance that every human being has the exact way of
reading and writing code. Everyone can configure her editor to what she
wants (including line breaks and such).

If people were to force pixel sizes of editor fonts, everyone would
immediately recognize what a stupid idea this would be. Even though I
could claim that the vertical formatting is all messed up when you don't
display my code with the correct font size! Ridiculous, right?

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 hidbv3$om2$1...@speranza.aioe.org
-- 
https://mail.python.org/mailman/listinfo/python-list

struct.unpack: why 's' fmt char convert to bytestring

2014-05-15 Thread GuoChao

The Python documentation gives this same example: record = b'raymond   
\x32\x12\x08\x01\x08'
 name, serialnum, school, gradelevel = unpack('10sHHb', record)
but get different results as to 's', don't know why this change in Python 3?  
need extra work to encode... name
 'raymond   '  # for 2.7 name
 b'raymond   '  # for 3.3  -- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 : Maximum line Length :

Johannes Bauer dfnsonfsdu...@gmx.de:

 I don't know why anyone would force a display issue onto everyone.

Well, if I have to work with your code, you are forcing your style on
me.

 It imples the arrogant stance that every human being has the exact way
 of reading and writing code. Everyone can configure her editor to what
 she wants (including line breaks and such).

That's a good point: why aren't we just exchanging AST's and configuring
the editor to display them in our preferred format?

Well, we're not there yet.

Objective readability is not the main issue here, IMO. It's the screen
estate. I know the idea of windows is fast disappearing from modern
(mobile) computing; you have apps instead that commandeer the whole
screen. Personally, I find that a big step backwards. I want to be able
to subdivide the screen for many windows that represent different
contexts and tasks.


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

Re: PEP 8 : Maximum line Length :

On Thu, May 15, 2014 at 10:32 PM, Johannes Bauer dfnsonfsdu...@gmx.de wrote:
 Personally I find overly narrow code (80 cols) to be much *harder* to
 read than code that is 100 cols wide. Keep in mind that even if the
 break is at 100 cols, lines will rarely exceed that limit. And if they
 do to *understand* the code, the further down the line it is the less
 important are the details usually.

The limit of human readability is generally given to be somewhere in
the range of 60-120. It's not a single specific value that's exactly
the same for everyone; personally, I like my lines of code to be a bit
longer than 80, and will happily go to 90-100, but in the interests of
interoperability, it's helpful to standardize on one common value -
especially for large shared codebases.

You're arguing against the specific value of 80, but 100 is still
pretty close to that. There are two key boundaries: the point at which
your eye can no longer comfortably read the text, and the point at
which you need to scroll horizontally. The latter of course depends on
your screen, but it's an EXTREMELY important barrier; the former is
the soft boundary, as you won't instantly know when you're over it.
(The two can be in either order, of course. I could easily read 90
char lines, but if I'm in a standard 80x24-25 terminal window, that's
going to scroll.) Both boundaries are almost certainly exceeded by a
500-character line; if you're doing your code like that, you obviously
do not want anyone reading it. [1] Whether you cut it off at 70, 80,
100, or some other figure, you still want to put some kind of limit on
it.

ChrisA

[1] That doesn't mean never do this. I've sometimes had code with
insanely long lines - for instance, an auto-generated list of names -
and it wasn't meant to be human-readable. Breaking it onto multiple
lines would have complicated matters unnecessarily, and if you wanted
to read the code, you should be reading the other file anyway.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 : Maximum line Length :

On Thu, May 15, 2014 at 11:07 PM, Marko Rauhamaa ma...@pacujo.net wrote:
 I know the idea of windows is fast disappearing from modern
 (mobile) computing; you have apps instead that commandeer the whole
 screen. Personally, I find that a big step backwards. I want to be able
 to subdivide the screen for many windows that represent different
 contexts and tasks.

Duh! :)

I'm currently working on Sikorsky (all my computers have names, of
course), with six Xfce workspaces. On those, my text editor (SciTE)
and MUD client (Gypsum) are set to Always on visible workspace;
everything else is whereever I choose to put it (VMs on workspace 2,
most of my primary activity on workspace 3, Alice: Madness Returns on
workspace 6, etc). Each workspace is subdivided into approximately
five million terminal windows, because that's what I do everything
with :) One web browser window, or maybe two; occasional other stuff;
but mainly, lots and lots of terminals. I can't imagine trying to get
any serious work done without loading up multiple consoles, some of
them SSH'd to other boxes, and being able to copy and paste between
them.

The Windows 8 / Unity / GNOME 3 model annoys me greatly. Can't get
work done like that.

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

Re: PEP 8 : Maximum line Length :

2014-05-15 Thread alister

On Thu, 15 May 2014 23:31:44 +1000, Chris Angelico wrote:
 The Windows 8 / Unity / GNOME 3 model annoys me greatly. Can't get work
 done like that.
 
 ChrisA
Windows 8/ Unity/ Gnome 3 are great on tablets (at least they look like 
they should be the only one I can confirm is Win 8) but lousy on a full 
pc with keyboard (Mouse optional)

I am with you  use either LXDE or XFCE or run level 3 on all of my 
systems.





-- 
Q: What do you call 50 Microsoft products at the bottom of the ocean?
A: A darned good start. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 : Maximum line Length :

On Thu, May 15, 2014 at 11:38 PM, alister
alister.nospam.w...@ntlworld.com wrote:
 On Thu, 15 May 2014 23:31:44 +1000, Chris Angelico wrote:
 The Windows 8 / Unity / GNOME 3 model annoys me greatly. Can't get work
 done like that.

 ChrisA
 Windows 8/ Unity/ Gnome 3 are great on tablets (at least they look like
 they should be the only one I can confirm is Win 8) but lousy on a full
 pc with keyboard (Mouse optional)

 I am with you  use either LXDE or XFCE or run level 3 on all of my
 systems.

Sorry, I should clarify that I'm talking about desktop systems here. I
have no idea how good those UIs are on actual tablets; my beef with
them is that putting a tablet UI on a desktop is just as much a bad
idea as putting a desktop UI on a tablet. When I have a 1920x1080
display on a screen that's about a meter wide, running a single
application is seldom what I want to do.

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

Re: struct.unpack: why 's' fmt char convert to bytestring

2014-05-15 Thread Dave Angel


On 05/15/2014 08:34 AM, GuoChao wrote:

The Python documentation gives this same example: record = b'raymond   
\x32\x12\x08\x01\x08'

name, serialnum, school, gradelevel = unpack('10sHHb', record)

but get different results as to 's', don't know why this change in Python 3?  need extra 
work to encode... name

'raymond   '  # for 2.7 name
b'raymond   '  # for 3.3




Please start a new thread, don't just change the subject and hope to 
hijack this existing thread on Fortran.


But you also need a problem statement.  What is it you're having trouble 
with?  Do you have some code that works differently in 3.3 and you want 
to know how to fix it?  If so, show what you've tried, what resulted, 
and what you expected instead.


Please post in text form.  This is a text list, and many people cannot 
see your html at all.  Others see it as improperly wrapped, which 
thoroughly masks what you're trying to do.  Even when I show it as html, 
it doesn't make sense.  Perhaps you're trying to retype the stuff, 
rather than copy/pasting it from your terminal window.


I could comment on individual portions of your query, but hopefully when 
you get one that's better organized, that won't be necessary.



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

Re: PEP 8 : Maximum line Length :

On Thursday, May 15, 2014 6:37:54 PM UTC+5:30, Marko Rauhamaa wrote:
 Johannes Bauer :
 
 
  I don't know why anyone would force a display issue onto everyone.
 
 
 Well, if I have to work with your code, you are forcing your style on
 me.
 
 
  It imples the arrogant stance that every human being has the exact way
  of reading and writing code. Everyone can configure her editor to what
  she wants (including line breaks and such).
 
 
 That's a good point: why aren't we just exchanging AST's and configuring
 the editor to display them in our preferred format?
 
 Well, we're not there yet.

Yes, regarding programmers using plain-text instead of hypertext
at http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html

I wrote:

And yet programmers continue to be decades behind all other users of computers. 
 We continue to use flat text for our programs when all others have moved on.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Roy Smith

In article 78ac407a-c429-4a7a-93c9-5d83e0f09...@googlegroups.com,
 Rustom Mody rustompm...@gmail.com wrote:

 And yet programmers continue to be decades behind all other users of 
 computers.  We continue to use flat text for our programs when all others 
 have moved on.

It's not like we haven't tried.  There have been a few attempts at using 
richer media to program (graphical UML editors, for example).  They've 
all pretty much been failures.

There *are* some places where non-text programming has won.  The biggest 
example would be GUI builders.  Nobody programs screen and window 
layouts by typing textual descriptions.  They push boxes around in a GUI 
builder.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 : Maximum line Length :

On Thursday, May 15, 2014 6:57:26 PM UTC+5:30, Chris Angelico wrote:
 The limit of human readability is generally given to be somewhere in
 the range of 60-120. It's not a single specific value that's exactly
 the same for everyone; personally, I like my lines of code to be a bit
 longer than 80, and will happily go to 90-100, but in the interests of
 interoperability, it's helpful to standardize on one common value -
 especially for large shared codebases.
 
 You're arguing against the specific value of 80, but 100 is still
 pretty close to that. There are two key boundaries: the point at which
 your eye can no longer comfortably read the text, and the point at
 which you need to scroll horizontally. The latter of course depends on
 your screen, but it's an EXTREMELY important barrier; the former is
 the soft boundary, as you won't instantly know when you're over it.
 

Thanks Chris for some sanity

As far as I can see the votaries of the mystical 79 have yet to explain
how/where it appeared from

JFTR the OP asked how to shorten a line and the shortest so far is what I 
suggested
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 : Maximum line Length :

On Thu, May 15, 2014 at 11:58 PM, Roy Smith r...@panix.com wrote:
 There *are* some places where non-text programming has won.  The biggest
 example would be GUI builders.  Nobody programs screen and window
 layouts by typing textual descriptions.  They push boxes around in a GUI
 builder.

Hi, I'm Nobody, and I like warm hugs!

My GUI building is entirely by typing textual descriptions. Yes, there
are some good builders, but I do my layouts on a basis of rules rather
than strict pixel positions. Rules and bag-based layouts mean there's
no problem with something getting too big and messing up your layout.

Is it really helpful to drag objects into a nearly-invisible Vertical
Box container? Pushing boxes around is great when you attach
everything directly to the window, but that gets messed up pretty
quickly by a user's themes, font sizes, etc (not to mention a change
of platform). Explicitly putting things into their boxes, grids,
tables, etc means it's always right.

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

Re: PEP 8 : Maximum line Length :

Rustom Mody rustompm...@gmail.com:

 We continue to use flat text for our programs when all others have
 moved on.

My more moderate and immediate point is, why should the physical
encoding of the program be also the presentation format?

A definitive Python source file could be binary, XML, .py, .ast,
whatever, and that would also be the file fed to the Python
compiler/interpreter. However, your editor could choose freely how to
present it to you.

IOW, shouldn't PEP8 be redundant?


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

Re: PEP 8 : Maximum line Length :

On Thursday, May 15, 2014 7:28:01 PM UTC+5:30, Roy Smith wrote:
 
  Rustom Mody wrote:
 
 
 
  And yet programmers continue to be decades behind all other users of 
  computers.  We continue to use flat text for our programs when all others 
  have moved on.
 
 
 
 It's not like we haven't tried.  There have been a few attempts at using 
 richer media to program (graphical UML editors, for example).  They've 
 all pretty much been failures.
 

In Fifth Discipline, Peter Senge starts by dilating on the length of time 
between
1903 when the Wright brothers first flew and 1935 when the DC-3 ushered in 
commercial air travel.

Five things were needed for that transition from pioneering to commercial:

| They were: the variable-pitch propeller, retractable landing gear, a type of 
| lightweight molded body construction called monocque, radial air-cooled 
| engine, and wing flaps. To succeed, the DC-3 needed all five; four were not 
| enough. One year earlier, the Boeing 247 was introduced with all of them 
except 
| wing flaps. Lacking wing flaps, Boeing's engineers found that the plane was 
| unstable on take-off and landing and had to downsize the engine.

So maybe you are just being pessimistic when in fact we are in the (equivalent 
of)
that 30 year period?

Two more examples:
Dijkstra pointed out that it typically takes an idea a hundred years from 
discovery 
to mainstream. Think Cantor inventing set theory in 1880s, modern math entering
schools in 1970s.

A more extreme example: Europeans learnt first of Hindu-Arabic numerals in 
around
1000 AD. IT took a good 500 years to give up on Roman numerals

 
 
 There *are* some places where non-text programming has won.  The biggest 
 example would be GUI builders.  Nobody programs screen and window 
 layouts by typing textual descriptions.  They push boxes around in a GUI 
 builder.

And yet you routinely find people on this list recommending writing python to 
using
a GUI-builder.
On the one hand I am tempted to say Sheesh!!
On the other, maybe the builders are still too half-assed... Dunno

[BTW is there any equivalent for html?]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 : Maximum line Length :

2014-05-15 Thread wxjmfauth

Le mardi 13 mai 2014 10:45:49 UTC+2, Peter Otten a écrit :
 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)

=

One another trick is to drop spaces around keywords

 9and 12345or 99if 'a'in'a' else or 77
12345

and pray, the tools from those who are wasting their time in
writing code analyzers or syntax colorizers or doc strings
collectors or ... are finally working. Depending of the tools
the interpretation may vary, but definitely all are producing
erroneous results.

jmf

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

Re: PEP 8 : Maximum line Length :

On Fri, May 16, 2014 at 12:12 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 A definitive Python source file could be binary, XML, .py, .ast,
 whatever, and that would also be the file fed to the Python
 compiler/interpreter. However, your editor could choose freely how to
 present it to you.

 IOW, shouldn't PEP8 be redundant?

I believe the Python interpreter happily accepts a zip file, which in
theory could be edited directly by a competent text editor. But that
has nothing to do with PEP 8. Compare a classic compiled language like
C - you have the bit you edit (the C source code) and the definitive
version that's fed to the program loader (the compiled binary). Style
guides apply to the edited version, not to the executed version.

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

Re: PEP 8 : Maximum line Length :

Rustom Mody rustompm...@gmail.com:

 And yet you routinely find people on this list recommending writing
 python to using a GUI-builder. On the one hand I am tempted to say
 Sheesh!! On the other, maybe the builders are still too
 half-assed... Dunno

That's like diagnosing cancer without invasive procedures, lab tests and
interviews: the doctor should be able to look at how pale you look and
if your skin has any funny bulges.

Thing is, programs and even text documents and spreadsheets have a lot
more abstract structure, dynamics and dependencies than the visible
façade. Block diagrams and graphics can be great presentation tools, but
nothing beats text in concise, explicit expressiveness.

An everyday example: a word processor displays the word hello with
hel in boldface and lo in italics. You put the cursor between the
l's and type a letter. Should it be in boldface or italics?

Who of you hasn't sworn at a Web editor that gets the formatting all
messed up when you have typed a backspace in the wrong place?


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

Re: PEP 8 : Maximum line Length :

On Fri, May 16, 2014 at 12:17 AM,  wxjmfa...@gmail.com wrote:
 One another trick is to drop spaces around keywords

 9and 12345or 99if 'a'in'a' else or 77
 12345

 and pray, the tools from those who are wasting their time in
 writing code analyzers or syntax colorizers or doc strings
 collectors or ... are finally working. Depending of the tools
 the interpretation may vary, but definitely all are producing
 erroneous results.

Yes. Another very effective way to get your code below 80 characters
is to shorten all names to a single letter. Since you don't need to
restrict yourself to monocase Roman letters (as I had to in my
earliest programming days, in BASIC), it's actually quite practical to
uniquely name everything in a single character; you could save
enormous amounts of horizontal space. Then, aggressively import as
to do the same with remote symbols (you might need two characters for
those), and you'll be able to write everything in just a few tight
symbols!

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

Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Skip Montanaro

On Thu, May 15, 2014 at 9:29 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 Who of you hasn't sworn at a Web editor that gets the formatting all
 messed up when you have typed a backspace in the wrong place?

My current pet peeve is the Gmail composition pane. What a load of
crap (especially in rich text mode).

You set the font to Sans Serif, start typing. Everything is in
Courier. Select All, switch everything to Sans Serif, and it redraw
the text, still in Courier, but in a different version of Courier.
Switch back to plain text mode. It has not-too-helpfully inserted line
breaks everywhere the rich text editor surrounded text with div
tags. Go back and delete all of them. Edit your text. Proofread your
text. Switch back to rich text so you can insert the image you wanted
to display. Hit Send.

Haven't we had WYSIWYG editors for about 40 years?

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

Re: PEP 8 : Maximum line Length :

Chris Angelico ros...@gmail.com:

 I believe the Python interpreter happily accepts a zip file, which in
 theory could be edited directly by a competent text editor. But that
 has nothing to do with PEP 8. Compare a classic compiled language like
 C - you have the bit you edit (the C source code) and the definitive
 version that's fed to the program loader (the compiled binary). Style
 guides apply to the edited version, not to the executed version.

My point applies to C as well. Shouldn't the .c file contain an AST?
Only when you open the file in your text editor, it makes it look like
you wrote it yourself in your favorite style?

You and I could have opened the same C file. Only you see:

   #include stdio.h

   int   ++
   main ( int argc,  | My first C program |
  char *const argv[] )   ++
   {
   (void) printf( Hello world\n );

   return(0);
   }

while I see:

   #include stdio.h

   /* My first C program */
   int main(int argc, char *const argv[]) {
 printf(Hello world\n);
 return 0;
   }


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

Re: PEP 8 : Maximum line Length :

On Fri, May 16, 2014 at 12:29 AM, Marko Rauhamaa ma...@pacujo.net wrote:
An everyday example: a word processor displays the word hello with
hel in boldface and lo in italics. You put the cursor between the
l's and type a letter. Should it be in boldface or italics?

Impossible to say, and one of the perpetual annoyances. Here's a web
site that I host:

http://gilbertandsullivan.org.au/index.php?option=com_contentview=articleid=92:2001-patiencecatid=30:patienceItemid=102

(Tiny URL: http://tinyurl.com/pphpkuk )

Why is Lt Duke of Dunstable different from all the other character
names? (By the way, I just picked an article at random from the
archive, and the first random pick had an example of what I'm talking
about. It's fairly prevalent on that site.) Now, if this were
hand-written HTML2, this sort of thing wouldn't happen; and, even
better, if the structure and formatting were properly separated (as in
my proposed web site redesign), they'd not only be guaranteed
consistent within a page, but also *across* pages.

Tagged text works well. In HTML pages, that means literal
anglebrackettags; in programming, that's all our various
notations and things. I wouldn't want to write code by writing a bunch
of words and then marking This word is an assignment target, this one
is an object that you should find a method on, this one is the method
name, and these ones are the arguments. I want to put = . ( ) to mark
those. More efficient... MUCH more reliable. And, bonus: it's all
text.

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

Re: struct.unpack: why 's' fmt char convert to bytestring

2014-05-15 Thread MRAB


On 2014-05-15 13:34, GuoChao wrote:

T https://docs.python.org/2.7/library/struct.htmlhe Python
documentation gives this same example:


record  =  b'raymond\x32\x12\x08\x01\x08'
name,  serialnum,  school,  gradelevel  =  unpack('10sHHb',  record)


but get different results as to 's', don't know why this change in
Python 3?  need extra work to encode...


name
'raymond   '  #for  2.7  https://docs.python.org/2.7/library/struct.html



name
b'raymond   '  #for  _3.3  https://docs.python.org/3.3/library/struct.html_



They are actually the same result; they are both bytestrings (a string
of bytes).

In Python 2, the 'str' class is for bytestrings and the 'unicode' class
is for Unicode strings, so 'abc' (or b'abc') is a bytestring and u'abc'
is a Unicode string.

In Python 3, the 'bytes' class is for bytestrings and the 'str' class
is for Unicode strings, so b'abc' is a bytestring and 'abc' is a
Unicode string.

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

Re: PEP 8 : Maximum line Length :

On Fri, May 16, 2014 at 12:36 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 You and I could have opened the same C file. Only you see:

#include stdio.h

int   ++
main ( int argc,  | My first C program |
   char *const argv[] )   ++
{
(void) printf( Hello world\n );

return(0);
}

 while I see:

#include stdio.h

/* My first C program */
int main(int argc, char *const argv[]) {
  printf(Hello world\n);
  return 0;
}

Well no, for two reasons. Firstly, I think the first one looks
disgusting, so even if I had that feature, I wouldn't use it like that
:)

But more importantly: You can already do that sort of thing, and it's
a bad idea. Maybe there aren't any text editors that can do it, but
you can use source control that way. (I'm going to use git as my
example, as I don't know how it's done in hg or any other; but I'm
sure it won't be hard.) You just tell git that these files (probably
files matching glob *.c) are to be reformatted, and provide two
commands: one that cleans a file prior to it going into source
control, and one that smudges it at the other end. So you could
simply write a code reformatter and register it as your smudge
command, and (in the interests of readable diffs) have some
standardized reformatter as the clean command. Voila! You now can
check out my code with your formatting.

Which brings me to the second reason for not doing this. That
clean/smudge operation *destroys information*. Once you enforce code
formatting like that, you violate PEP 8's rule zero: sometimes, it's
better to break the rules. Sometimes, your nice code reformatting
operation will actually make the program worse... and there'll be no
way for you to get back from that.

Not to mention that any reformatting that inserts or deletes lines is
a pain for debugging. Line 42 on your screen and Line 42 in the
traceback won't be the same thing any more. If I run your code and
give you an exception trace, you'll have to check out my version of
the code to be able to understand anything. Theoretically that could
be solved (eg you absolutely always run the checked-in version - of
course, that assumes that everyone's smudge and clean will perfectly
recreate the exact same output), but even with editor support, where
you'd move the cursor around and the line number would go berserk
(press down-arrow three times and the line number goes 5, 6, 6, 10),
it would be a pain.

Code is a text file. So is music (I use GNU LilyPond, and everything
works like code). So is data, in many many cases. So is configuration,
often, although some programs prefer to work with an opaque format.
About the only thing that really definitely shouldn't be massaged into
text is actual 2D images. Can you turn this into a few lines of code?

https://lh3.googleusercontent.com/-_8upQkJcvjE/UhTJlDzW3ZI/BU8/QvExuUq47dI/s512/DSCF7600.JPG

Pretty much everything else, though, works better as plain text.

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

Re: PEP 8 : Maximum line Length :

2014-05-15 Thread wxjmfauth

Le jeudi 15 mai 2014 16:27:16 UTC+2, Chris Angelico a écrit :
 On Fri, May 16, 2014 at 12:17 AM,  wxjmfa...@gmail.com wrote:
 
  One another trick is to drop spaces around keywords
 
 
 
  9and 12345or 99if 'a'in'a' else or 77
 
  12345
 
 
 
  and pray, the tools from those who are wasting their time in
 
  writing code analyzers or syntax colorizers or doc strings
 
  collectors or ... are finally working. Depending of the tools
 
  the interpretation may vary, but definitely all are producing
 
  erroneous results.
 
 
 
 Yes. Another very effective way to get your code below 80 characters
 
 is to shorten all names to a single letter. Since you don't need to
 
 restrict yourself to monocase Roman letters (as I had to in my
 
 earliest programming days, in BASIC), it's actually quite practical to
 
 uniquely name everything in a single character; you could save
 
 enormous amounts of horizontal space. Then, aggressively import as
 
 to do the same with remote symbols (you might need two characters for
 
 those), and you'll be able to write everything in just a few tight

=

 1or 0
1


Short, but still a bug.

1

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

Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Mark Lawrence


On 15/05/2014 14:58, Roy Smith wrote:

In article 78ac407a-c429-4a7a-93c9-5d83e0f09...@googlegroups.com,
  Rustom Mody rustompm...@gmail.com wrote:


And yet programmers continue to be decades behind all other users of
computers.  We continue to use flat text for our programs when all others
have moved on.


It's not like we haven't tried.  There have been a few attempts at using
richer media to program (graphical UML editors, for example).  They've
all pretty much been failures.



This http://sourceforge.net/projects/doublesvsoop/ was project of the 
month just a little while ago, so it's obviously overcome all of the 
known obstacles, in exactly the same way that all previous silver 
bullets have done.  At least I think it's the kind of thing that you're 
talking about.


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

2014-05-15 Thread alister

On Thu, 15 May 2014 23:44:34 +1000, Chris Angelico wrote:

 On Thu, May 15, 2014 at 11:38 PM, alister
 alister.nospam.w...@ntlworld.com wrote:
 On Thu, 15 May 2014 23:31:44 +1000, Chris Angelico wrote:
 The Windows 8 / Unity / GNOME 3 model annoys me greatly. Can't get
 work done like that.

 ChrisA
 Windows 8/ Unity/ Gnome 3 are great on tablets (at least they look like
 they should be the only one I can confirm is Win 8) but lousy on a full
 pc with keyboard (Mouse optional)

 I am with you  use either LXDE or XFCE or run level 3 on all of my
 systems.
 
 Sorry, I should clarify that I'm talking about desktop systems here. I
 have no idea how good those UIs are on actual tablets; my beef with them
 is that putting a tablet UI on a desktop is just as much a bad idea as
 putting a desktop UI on a tablet. When I have a 1920x1080 display on a
 screen that's about a meter wide, running a single application is seldom
 what I want to do.
 
 ChrisA

i think i was actually agreeing with you :-)



-- 
Afternoon very favorable for romance.  Try a single person for a change.
-- 
https://mail.python.org/mailman/listinfo/python-list

Directory Caching, suggestions and comments?

2014-05-15 Thread Benjamin Schollnick

Folks,

I am going to be using this code as part of a web system, and I would love
any feedback, comments and criticism.

Just as a side note, I'm not completely PEP 8.  I know that, I use a
slightly laxer setting in pylint, but I'm working my way up to it...

I am using scandir from benhoyt to speed up the directory listings, and
data collection.

The module is here as well,
https://dl.dropboxusercontent.com/u/241415/misc/directory_caching_v1.py

I had considered using OrderedDicts, but I really didn't see how that would
help the system.

I'm not completely happy with the return_sort_* functions, since they
return two different tuples, one goal was to try to keep everything in the
dictionary, but I couldn't think of a better method.

So any suggestions are welcome.

 - Benjamin



Directory Caching system.

Used to cache  speed up directory listing.

Preqs -

Scandir - https://github.com/benhoyt/scandir

scandir is a module which provides a generator version of
os.listdir() that also exposes the extra file information the
operating system returns when you iterate a directory.

Generally 2-3 (or more) times faster than the standard library.
(It's quite noticeable!)

import os
import os.path
import re
from stat import ST_MODE, ST_INO, ST_DEV, ST_NLINK, ST_UID, ST_GID, \
ST_SIZE, ST_ATIME, ST_MTIME, ST_CTIME

import time
import scandir

plugin_name = dir_cache

#
class   CachedDirectory(object):

For example:

To be added shortly.


def __init__(self):
self.files_to_ignore = ['.ds_store', '.htaccess']
self.root_path = None
# This is the path in the OS that is being examined
#(e.g. /Volumes/Users/username/)
self.directory_cache = {}


def _scan_directory_list(self, scan_directory):

Scan the directory scan_directory, and save it to the
self.directory_cache dictionary.

Low Level function, intended to be used by the populate
function.

scan_directory = os.path.abspath(scan_directory)
directories = {}
files = {}
self.directory_cache[scan_directory.strip().lower()] = {}
self.directory_cache[scan_directory.strip().lower()][number_dirs]
= 0

self.directory_cache[scan_directory.strip().lower()][number_files] = 0
for x in scandir.scandir(scan_directory):
st = x.lstat()
data = {}
data[fq_filename] = os.path.realpath(scan_directory).lower()
+ \
os.sep+x.name.strip().lower()
data[parentdirectory] = os.sep.join(\
os.path.split(scan_directory)[0:-1])
data[st_mode] = st[ST_MODE]
data[st_inode] = st[ST_INO]
data[st_dev] = st[ST_DEV]
data[st_nlink] = st[ST_NLINK]
data[st_uid] = st[ST_UID]
data[st_gid] = st[ST_GID]
data[compressed] = st[ST_SIZE]
data[st_size] = st[ST_SIZE]   #10
data[st_atime] = st[ST_ATIME] #11
data[raw_st_mtime] = st[ST_MTIME] #12
data[st_mtime] = time.asctime(time.localtime(st[ST_MTIME]))
data[st_ctime] = st[ST_CTIME]
if not x.name.strip().lower() in self.files_to_ignore:
if x.is_dir():
self.directory_cache[scan_directory.strip().lower()]\
[number_dirs] += 1
data[archivefilename] = 
data[filename] = 
data[directoryname] = x.name.strip().lower()
data[dot_extension] = .dir
data[file_extension] = dir
directories[x.name.lower().strip()] = True
self._scan_directory_list(data[fq_filename])
data[number_files] = self.directory_cache\
[data[fq_filename]][number_files]
data[number_dirs] = self.directory_cache\
[data[fq_filename]][number_dirs]
directories[x.name.lower().strip()] = data
else:
self.directory_cache[scan_directory.strip().lower()]\
[number_files] += 1
data[archivefilename] = 
data[filename] = x.name.strip().lower()
data[directoryname] = scan_directory
data[dot_extension] = os.path.splitext\
(x.name)[1].lower()
data[file_extension] = os.path.splitext\
(x.name)[1][1:].lower()
files[x.name.lower().strip()] = data
self.directory_cache[scan_directory.strip().lower()][files] =
files
self.directory_cache[scan_directory.strip().lower()]\
[dirs] = directories
self.directory_cache[scan_directory.strip().lower()]\

Re: Directory Caching, suggestions and comments?

On Fri, May 16, 2014 at 5:34 AM, Benjamin Schollnick
benja...@schollnick.net wrote:
 Just as a side note, I'm not completely PEP 8.  I know that, I use a
 slightly laxer setting in pylint, but I'm working my way up to it...

 I am using scandir from benhoyt to speed up the directory listings, and data
 collection.

First comment: You're running headlong into the two hardest problems
in computing - cache invalidation, and naming things. (And off-by-one
errors.)

More specifically, and leaving aside the naming issue as you're aware
of it, you have to cope with all sorts of messes of stale cache data.
For instance, you stat a directory and depend on its mtime - you can't
depend on that always being up-to-date, AND you can't rely on the
clock not shifting. (What happens, for instance, if the server's
onboard clock gains time at a notable rate, and a firewall
misconfiguration is blocking NTP - and then you fix the firewall and
the clock suddenly jumps backward by a few hours? Yep. Happened to me.
Well, I think the clock jumped maybe half an hour, but it could easily
have been a lot more.)

What platform are you running this on? On all my Linux systems, the
file system caches stat() info for me. That has never been a problem,
because the FS knows when it needs to update/flush that cache. All I
need to know is that having spare RAM means performance improves :) I
can do a sudo find / -name ... and it chugs and chugs, and then I do
it again and it's fast. Windows, not so nice, but I'd still look at OS
or FS caching where possible. (Other platforms I don't personally use,
so I don't know whether or not they have good caching.)

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

Re: Bug in Decimal??

2014-05-15 Thread pleasedontspam

On Sunday, May 4, 2014 6:53:06 AM UTC-4, Mark Dickinson wrote:

 I had a quick look: this isn't a bug - it's just the result of propagation of
 
 the error in partial to final.
 
 
 
 In more detail: we've got a working precision of 2016 significant figures.  
 For
 
 any small x, we have (1 + x) / (1 - x) = 1 + 2x + 2x^2 + 2x^3 +   For your
 
 value of x, `Decimal('1e-1007'), we've got enough precision to store
 
 1 + 2x + 2x^2 exactly, but that's all.
 
 
 
 So partial has an absolute error of around 2x^3, or 2e-3021.
 
 
 
 And since the derivative of the natural log function is almost exactly 1 at 
 the
 
 point we're interested in, we expect the absolute error in the output to be
 
 close to 2e-3021, too.
 

Please take a deeper look at my second post. Try the same but this time set the 
precision to 4000, 8000 or whatever you need to convince yourself there's no 
error propagation, yet there's a 4 in the middle that shouldn't be there. See 
for yourself!

I've tested on all platforms I know of and confirmed it. The wrong digit occurs 
in the middle of the number. Propagation error would have a bad digit near the 
end, and garbage after that. Here there's a perfect sequence of numbers, but 
with one single digit changed in the middle of the number.
No error propagation in a series expansion can do that.

I generated a table of 1000 numbers, one correctly generated and one with 
mpdecimal. Then I did a diff of both files and it's horrible. The difference is 
all over the place, sometimes as high as digit 500 (out of 2000). Almost every 
result has the bad digit somewhere. The bad digit moves around a lot, from 
about position 500 to 2000. All other digits are correct, and in a 2000 digit 
sequence is hard to spot the difference (I used the visual diff tool that comes 
with TortoiseSVN or TortoiseGit). I think there's a bad pointer or something 
that's rounding the wrong digit.
You cannot possibly have 1999 correct digits and only 1 changed on every number 
if it was propagation error.

I'll follow up directly with the author of mpdecimal, as this is somewhat 
serious on a language that's so widely used as python.

But please test it and confirm, am I seeing ghost digits?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bug in Decimal??

2014-05-15 Thread Mark H Harris


On 5/15/14 3:45 PM, pleasedonts...@isp.com wrote:

Please take a deeper look at my second post. Try the same but this time
set the precision to 4000, 8000 or whatever you need to convince yourself
there's no error propagation, yet there's a 4 in the middle that shouldn't



be there. See for yourself!
I've tested on all platforms I know of and confirmed it. The wrong digit
occurs in the middle of the number. Propagation error would have a bad digit
near the end, and garbage after that. Here there's a perfect sequence of
numbers, but with one single digit changed in the middle of the number.
No error propagation in a series expansion can do that.

I generated a table of 1000 numbers, one correctly generated and one with
mpdecimal. Then I did a diff of both files and it's horrible. The difference
is all over the place, sometimes as high as digit 500 (out of 2000). Almost
every result has the bad digit somewhere. The bad digit moves around a lot,
from about position 500 to 2000. All other digits are correct, and in a 2000
digit sequence is hard to spot the difference (I used the visual diff tool
that comes with TortoiseSVN or TortoiseGit). I think there's a bad pointer
or something that's rounding the wrong digit.
You cannot possibly have 1999 correct digits and only 1 changed on every
number if it was propagation error.



I'll follow up directly with the author of mpdecimal, as this is somewhat
serious on a language that's so widely used as python.

But please test it and confirm, am I seeing ghost digits?



I don't believe it. I've been running converging series to hudreds of 
thousands of decimal places (not only on different platforms, but on 
different BigFloat systmes, Jullia, BC, Decimal with pdeclib) and I'm 
not seeing the 'middle of the number' error you are talking about. I ran 
π to over 100,000+ digits and compared between BC and Python Decimal 
with pilib pdeclib and both compared correct;  also compared correct to 
the on-line standard.  S... not sure ...


I can work on this some this weekend (comparing between Julia BigFloat 
and Python Decimal with pdeclib and see. I'm very skeptical at this point.


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

Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Terry Reedy


On 5/15/2014 10:42 AM, Chris Angelico wrote:


Impossible to say, and one of the perpetual annoyances. Here's a web
site that I host:

http://gilbertandsullivan.org.au/index.php?option=com_contentview=articleid=92:2001-patiencecatid=30:patienceItemid=102

(Tiny URL: http://tinyurl.com/pphpkuk )

Why is Lt Duke of Dunstable different from all the other character
names?


For me, Windows FF, it is not different that I can see.


--
Terry Jan Reedy

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

Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Terry Reedy


On 5/15/2014 9:58 AM, Rustom Mody wrote:


As far as I can see the votaries of the mystical 79 have yet to explain
how/where it appeared from


As has been explained before, and is implied in the PEP, 79 = 80 - 1.
80 chars - 1 character width cursor leaves 79 non-cursor characters. 
When enter is hit, the cursor replaced with \n. So you can think of 79 
as 79 visible + \n = 80.


PEP 8 says The limits are chosen to avoid wrapping in editors with the 
window width set to 80, and goes on about dynamic wrapping or not. To 
put is another way, all 80 char terminals work with 79 visible chars. 
Some but not all work with 80 visible, and some work with 80 on all 
lines except the last.


I admit that this would have been clearer when most everyone reading it 
would have had some experience with 80 char sceens (including DOS). 
Still, did you really not notice that 79 = 80 - 1?


--
Terry Jan Reedy

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

Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Ben Finney

Johannes Bauer dfnsonfsdu...@gmx.de writes:

On 15.05.2014 04:43, Ben Finney wrote:
Rustom Mody rustompm...@gmail.com writes:

Until then may we relegate '79' to quaint historical curiosities

Not until the general capacity of human cognition advances to make
longer lines easier to read.

I find it surprising how you can make such a claim about the whole of
humanity (!) without even feeling the need to have a pro forma study
to back it up.

This is an informal discussion forum. Merely because I don't produce
citations every time I mention a fact doesn't imply that I'm not basing
my assertions on fact.

Here is one such study
URL:http://www.psychology.nottingham.ac.uk/staff/mxh/Papers/Dyson%20%20Haselgrove%20%282001%29.pdf.
But there is plenty of room for uninformed diverity of opinion
URL:http://skeptics.stackexchange.com/questions/5625/are-shorter-lines-easier-to-read.

The point is less about hard evidence about *precise* limits; I make no
claim about the superiority of 80 columns or 93 columns or 55 columns or
whatever.

Rather, the point is rather that human cognition *does* have limits, and
those limits are at the basis of limits we choose to impose on text
layout.

Those who claim “terminals just magically happened to be 80 columns wide
and we were slaves to that limit” have it completely backward: the
limits were imposed *onto* the terminals by human makers, based on their
understanding of the cognitive limits of the humans reading from them.

Those limits are with us still, and to my knowledge have not improved
with recent human generations.

Also, not everything that applies to prose also equally applies to
code.

If you're going to counter evidence of general human reading cognition
by making special claims about code, that would need to be backed up
with specific evidence.

Personally I find overly narrow code (80 cols) to be much *harder* to
read than code that is 100 cols wide.

I counter your anecdote with my own: I find 80 columns to be quite long,
and prefer code to be no more than around 60 columns. So what do we
learn? That attempts to generalise from personal anecdote doesn't get us
anywhere useful.

--
\“I took a course in speed waiting. Now I can wait an hour in |
`\ only ten minutes.” —Steven Wright |
_o__) |
Ben Finney

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

Re: PEP 8 : Maximum line Length :

2014-05-15 Thread MRAB


On 2014-05-15 22:50, Terry Reedy wrote:

On 5/15/2014 10:42 AM, Chris Angelico wrote:


Impossible to say, and one of the perpetual annoyances. Here's a web
site that I host:

http://gilbertandsullivan.org.au/index.php?option=com_contentview=articleid=92:2001-patiencecatid=30:patienceItemid=102

(Tiny URL: http://tinyurl.com/pphpkuk )

Why is Lt Duke of Dunstable different from all the other character
names?


For me, Windows FF, it is not different that I can see.


For me, with Firefox on Windows, it's slightly bolder, but that's
probably because its colour is specified, unlike the others.
--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 : Maximum line Length :

On Friday, May 16, 2014 3:51:27 AM UTC+5:30, Terry Reedy wrote:
 On 5/15/2014 9:58 AM, Rustom Mody wrote:
 
 
  As far as I can see the votaries of the mystical 79 have yet to explain
  how/where it appeared from
 
 
 
 As has been explained before, and is implied in the PEP, 79 = 80 - 1.
 80 chars - 1 character width cursor leaves 79 non-cursor characters. 
 When enter is hit, the cursor replaced with \n. So you can think of 79 
 as 79 visible + \n = 80.
 
 
 
 PEP 8 says The limits are chosen to avoid wrapping in editors with the 
 window width set to 80, and goes on about dynamic wrapping or not. To 
 put is another way, all 80 char terminals work with 79 visible chars. 
 Some but not all work with 80 visible, and some work with 80 on all 
 lines except the last.
 
 
 
 I admit that this would have been clearer when most everyone reading it 
 would have had some experience with 80 char sceens (including DOS). 
 Still, did you really not notice that 79 = 80 - 1?

The claim being made is that 79/80 is a fundamental, cognitive limit and has 
no relation to technological changes.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Ben Finney

Rustom Mody rustompm...@gmail.com writes:

 The claim being made is that 79/80 is a fundamental, cognitive limit
 and has no relation to technological changes.

Who has made that claim, and where? You appear to be attacking a straw
man.

Rather, I've claimed that the conventional lime length limit is *based
in* the real cognitive limits of human reading comprehension — and that
technologies have been designed with corresponding limitations.

Nowhere have I claimed 79 or 80 are somehow fundamental or encoded in
human cognition, and I have seen no-one else claim that. Please try to
work within your own cognitive limits and read what people write for
comprehension.

-- 
 \  “As soon as we abandon our own reason, and are content to rely |
  `\   upon authority, there is no end to our troubles.” —Bertrand |
_o__)Russell, _Unpopular Essays_, 1950 |
Ben Finney

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

Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Steven D'Aprano

On Thu, 15 May 2014 16:07:54 +0300, Marko Rauhamaa wrote:

 Johannes Bauer dfnsonfsdu...@gmx.de:
 
 I don't know why anyone would force a display issue onto everyone.
 
 Well, if I have to work with your code, you are forcing your style on
 me.

+1


 It imples the arrogant stance that every human being has the exact way
 of reading and writing code. Everyone can configure her editor to what
 she wants (including line breaks and such).
 
 That's a good point: why aren't we just exchanging AST's and configuring
 the editor to display them in our preferred format?

Oh, I hope not. Sometimes information is carried by the layout. For 
example, if I write a class:

class Spam:

def foo(self): ...
def bar(self): ...
def baz(self): ...

def foobar(self): ...


then without me saying anything, the reader should realise that foo, bar 
and baz, but not foobar, go together in a weak sense. If it were a strong 
sense, foobar ought to go into a separate class.

A real example: writing getters and setters for property. Particularly if 
they are one or two line methods, I'll usually run them together with no 
separating blank lines to emphasize that they belong together.

ASTs often don't include comments, so that's a problem.


 Well, we're not there yet.
 
 Objective readability is not the main issue here, IMO. It's the screen
 estate. I know the idea of windows is fast disappearing from modern
 (mobile) computing; you have apps instead that commandeer the whole
 screen. Personally, I find that a big step backwards.

Yes. In my opinion, mobile computing is a huge step backwards for 
personal control of your own hardware, usability, and power. In my 
opinion, people will look back at the first decade of the 21st century as 
the golden age of personal computing.



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

Re: Directory Caching, suggestions and comments?

2014-05-15 Thread Cameron Simpson


On 15May2014 15:34, Benjamin Schollnick benja...@schollnick.net wrote:

I am going to be using this code as part of a web system, and I would love
any feedback, comments and criticism. [...]
I am using scandir from benhoyt to speed up the directory listings, and
data collection. [...]
I had considered using OrderedDicts, but I really didn't see how that would
help the system.

I'm not completely happy with the return_sort_* functions, since they
return two different tuples, one goal was to try to keep everything in the
dictionary, but I couldn't think of a better method.

So any suggestions are welcome.


Firstly, I'm with ChrisA on the whole: let the filesystem/OS do the stat 
caching. It _is_ actually slower to rely on this than an in-memory cache such 
as yours, but at least it is reliable because you will then have exactly the 
same file info state as any other user of the OS. Stale caches are a usability 
PITA for the end user; witness the continued presence of Shift-Reload in most 
browsers because browser (and proxy) caches get stale.


His remark about relying on the mtime of a directory is correct also, and not 
just because of clock changes. On UNIX, the mtime of a directory changes _only_ 
when a filename is added/removed from the directory. To the point, it will not 
change if a file in the directory is just modified, and therefore your cache 
will become stale (and stay stale) in that circumstance.


Of course, you wouldn't even be bothering with scandir if you were not 
concerned about relying of the filesystem/OS. So, it is your call about 
remembering this stuff. I would include a real-time staleness in addition to 
the mtime check, eg if the mtime is updated _or_ the system time says it is 
more than N seconds since the last directory scan, with N being smallish.


Most of my other remarks have to do with style and implementation.


Preqs -
   Scandir - https://github.com/benhoyt/scandir
   scandir is a module which provides a generator version of
   os.listdir() that also exposes the extra file information the
   operating system returns when you iterate a directory.


Personally, my habit is to use os.listdir() and accept the memory cost for two 
reasons: it is simple and the list is stable. If you iterate over a directory 
(eg via the C library readdir() facility) to my mind there is scope for the 
directory changing underneath you. A bit like iterating over a dictionary which 
is in active use by other code. Using os.listdir() minimises that window.


So I'd be going:

  names = list(scandir(directory_path))

to get a snapshot, and then working with that list.


from stat import ST_MODE, ST_INO, ST_DEV, ST_NLINK, ST_UID, ST_GID, \
   ST_SIZE, ST_ATIME, ST_MTIME, ST_CTIME


You don't need these. os.lstat() and os.stat() return stat objects, and they 
have convenient .st_mtime etc attributes. So all your:


  data[st_nlink] = st[ST_NLINK]

stuff can become:

  data[st_nlink] = st.st_nlink

I'd also be making your data object just an object, and assigning directory 
to an attribute on it, thus:


  data.st_nlink = st.st_nlink

Much more readable.

You could also avoid the entire issue of manually copying each st.st_blah 
attribute by just going:


  data.st = st

Then just reach for data.st.st_mtime (or whatever) as needed.  Short, quick, 
avoids needing to worry about optional stat fields - just keep the original 
stat result.




import time
import scandir

plugin_name = dir_cache

#
class   CachedDirectory(object):
   
   For example:

   To be added shortly.


It is _well_ work sketching this part out. Since this is just a cache, an 
example should be quite short.


I find it enormously convenient to sketch some of the use cases here - it helps 
keep the required method names nicely defined.  i.e.  sketch a little code that 
you need to write, then write methods to support the code. You get a much 
better match that way. I often revisit classes when I use them, because I write 
some code using the class and think that was very painful, how would I _like_ 
to have been able to use this?



   
   def __init__(self):
   self.files_to_ignore = ['.ds_store', '.htaccess']
   self.root_path = None


You don't seem to use .root_path?


   # This is the path in the OS that is being examined
   #(e.g. /Volumes/Users/username/)
   self.directory_cache = {}


This is a CachedDirectory class. I would have just called this .cache - it will 
make all the code using it less wordy, and hopefully more readable. Unless 
there may be caches of other stuff too. This is almost entirely a matter of 
personal style though.



   def _scan_directory_list(self, scan_directory):
   
   Scan the directory scan_directory, and save it to the
   self.directory_cache dictionary.

   Low Level function, intended to be used by the populate
function.
   
   scan_directory =

Re: PEP 8 : Maximum line Length :

2014-05-15 Thread Steven D'Aprano

On Thu, 15 May 2014 06:58:53 -0700, Rustom Mody wrote:

 As far as I can see the votaries of the mystical 79 have yet to explain
 how/where it appeared from

You're either trolling, or haven't been reading this thread in any 
detail. That's already been explained, repeatedly both in this thread and 
many times over the years: 79 is one less than 80, which is the standard 
width of many editors, which in turn comes from old dedicated terminals.

Given your use of deliberately provocative terms like votaries and 
mystical, I would say you're trolling.

On the chance that you are asking an honest question, there's nothing 
mystical or magical about the number 79, or 80. 80 is a de facto 
standard. Had history turned out a bit different, that standard might 
have been 90 characters, or 70. Less likely (because people 
psychologically have a preference for multiples of ten over random 
numbers) it could have been 65, or 93, or any number somewhere in that 
range of 60 to 100 or thereabouts.

But once a standard is established, even an arbitrary standard like 80 
columns -- but not *entirely* arbitrary -- there is value in sticking to 
it *just because it is the standard*. There's nothing mystical about 
driving on the left hand side of the road (on the right hand side for 
Americans), but whatever choice everyone else has made, you really ought 
to do the same. Following the same standard simply makes interoperability 
easier and reduces friction.

But as I said, 80 isn't *entirely* arbitrary. 8 characters would be too 
few; 800 would be too many. Approximately 60 to 100 characters or 
thereabouts is the Goldilocks zone of not too few, not too many for 
most texts.

Think of it this way: every time the reader has to scroll horizontally, 
consider that as a page fault (it's an order of magnitude slower than 
scanning with the eyes). Every time a single logical expression has to be 
split over two lines, that's also a page fault. Every time you read a 
line of complicated code that does too much, that's also a page fault. We 
want to minimize the number of page faults.

A limit of 60 characters would minimize the number of horizontal 
scrolling page faults (hardly anyone has their editor to display fewer 
than 60 characters!), but increase the number of expression-splitting 
page faults. A limit of 120 characters would reduce the number of 
expression-splitting page faults, but increase the number of horizontal-
scrolling faults, and encourage people to write long lines of complicated 
code that does too much. Somewhere in between is a range that minimizes 
the number of page faults, hence maximizes readability.

There's unlikely to be One True Best Answer to maximize readability at 
N characters, because maximum readability is dependent on the context. 
One can only hope to get close to maximum readability for a range of 
typical text, including code. That's likely to be around 80 characters, 
which fits nicely with the historical standard. Reducing that to 80-1=79 
means you're protected from off-by-one errors in either your counting 
or your editor.



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

Re: PEP 8 : Maximum line Length :

On Friday, May 16, 2014 5:51:21 AM UTC+5:30, Ben Finney wrote:
 
 
 Rather, I've claimed that the conventional lime length limit is *based
 in* the real cognitive limits of human reading comprehension -- and that
 technologies have been designed with corresponding limitations.
 
 
 Nowhere have I claimed 79 or 80 are somehow fundamental or encoded in
 human cognition, and I have seen no-one else claim that. Please try to
 work within your own cognitive limits and read what people write for
 comprehension.
 

You said this:

 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. 

And you answered:

 Until then may we relegate '79' to quaint historical curiosities...??

with

 Not until the general capacity of human cognition advances to make
 longer lines easier to read.
-- 
https://mail.python.org/mailman/listinfo/python-list

IndexError: pop from empty list

2014-05-15 Thread chris

Any ideas about what this might mean?

Running Debian Wheezy on a RaspBerry Pi and collecting data on a dispatch 
thread that is reading input on the serial port (connected to xbee series 1).

It happens every few days but it really chokes the program.

Thanks for any tips,
ChrisJ




Exception in thread Thread-2:
Traceback (most recent call last):
  File /usr/lib/python2.7/threading.py, line 552, in __bootstrap_inner
self.run()
  File /usr/local/lib/python2.7/dist-packages/xbee/base.py, line 95, in run
self._callback(self.wait_read_frame())
  File /usr/local/lib/python2.7/dist-packages/xbee/base.py, line 400, in 
wait_read_frame
return self._split_response(frame.data)
  File /usr/local/lib/python2.7/dist-packages/xbee/base.py, line 288, in 
_split_response
info[parse_rule[0]] = parse_rule[1](self, info)
  File /usr/local/lib/python2.7/dist-packages/xbee/ieee.py, line 117, in 
lambda
lambda xbee,original: xbee._parse_samples(original['samples'])
  File /usr/local/lib/python2.7/dist-packages/xbee/base.py, line 357, in 
_parse_samples
digital_data_set = (sample_bytes.pop(0)  8 | sample_bytes.pop(0))
IndexError: pop from empty list


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

Re: IndexError: pop from empty list

2014-05-15 Thread Gary Herron


On 05/15/2014 09:36 PM, ch...@freeranger.com wrote:

Any ideas about what this might mean?

Running Debian Wheezy on a RaspBerry Pi and collecting data on a dispatch 
thread that is reading input on the serial port (connected to xbee series 1).

It happens every few days but it really chokes the program.

Thanks for any tips,
ChrisJ




Exception in thread Thread-2:
Traceback (most recent call last):
   File /usr/lib/python2.7/threading.py, line 552, in __bootstrap_inner
 self.run()
   File /usr/local/lib/python2.7/dist-packages/xbee/base.py, line 95, in run
 self._callback(self.wait_read_frame())
   File /usr/local/lib/python2.7/dist-packages/xbee/base.py, line 400, in 
wait_read_frame
 return self._split_response(frame.data)
   File /usr/local/lib/python2.7/dist-packages/xbee/base.py, line 288, in 
_split_response
 info[parse_rule[0]] = parse_rule[1](self, info)
   File /usr/local/lib/python2.7/dist-packages/xbee/ieee.py, line 117, in 
lambda
 lambda xbee,original: xbee._parse_samples(original['samples'])
   File /usr/local/lib/python2.7/dist-packages/xbee/base.py, line 357, in 
_parse_samples
 digital_data_set = (sample_bytes.pop(0)  8 | sample_bytes.pop(0))
IndexError: pop from empty list


The error means that sample_bytes is an empty list so calling pop is an 
error.


Or were you asking something deeper, like *why*  sample_bytes is an 
empty list?


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

Re: socket client and server in one application?

2014-05-15 Thread chris

Thank you all.

The 2 threaded in/out sockets are working great.  I'm receiving input on the 
xbee/serial port  in the dispatch thread.  For each receipt I send the xbee 
data through a socket connected to node-red.  Node-red is collecting the data, 
parsing it and sending it along to other end points; mainly to carbon/graphite 
for charting.

Then I've got some injection nodes in node-red that can send signals back to 
the python script.  The python script has a socket server in the main loop that 
waits for a specialized command which, when received, sends a command back out 
the serial/xbee port to instruct a device to turn on/off.

Generally it works great but I'm tuning it to optimize the amount of data I'm 
managing.  The xbees are set to send 4 data points every .5 seconds.  I only 
have 5 xbee radios in my setup but I think that means the little raspi is 
collecting up to 40 data points every second.

On the node-red, it breaks each data set into 4 discreet entries and sends 
those to the carbon/graphite charting app.

I'm thinking of including some signal averaging into the python receiver to 
smooth out the various signals I'm tracking.

Again, thank you all for your help,
Chris.



On Monday, May 5, 2014 4:05:22 PM UTC-7, Chris Angelico wrote:
 On Tue, May 6, 2014 at 8:37 AM,  ch...@freeranger.com wrote:
 
  I'm using a dispatch method to receive and occasionally send data through a 
  serial port on a Raspberry Pi.  I think the dispatch method is essentially 
  a threaded approach, right?
 
 
 
  Now to receive serial data and send via socket, then occasionally receive 
  some socket based input and send out on the same serial port.  It's 
  combining the client and server socket code into a single app (so I can 
  have a single connection to the serial port) that has me confused.  I don't 
  see any discussion of that anywhere.
 
 
 
 
 
 Threads would be easy. As I understand it, you have two bidirectional
 
 connections, and you're simply linking them? Sounds like a very simple
 
 proxy/tunnel. You don't need to multiplex, so all you need is two
 
 threads: one reading from the socket and writing to the serial port,
 
 and one reading from the serial port and writing to the socket. The
 
 code would look something like this:
 
 
 
 serial_port = open(...)
 
 tcp_socket = socket.create_connection(...)
 
 # initialize them both, do whatever setup is needed
 
 
 
 def socket_to_serial():
 
 while True:
 
 data = tcp_socket.recv(4096)
 
 serial_port.write(data)
 
 
 
 Thread.Thread(target=socket_to_serial).start()
 
 
 
 while True:
 
 data = serial_port.read(4096)
 
 tcp_socket.send(data)
 
 
 
 
 
 Two simple loops, running concurrently. Pretty straight-forward as
 
 threads. Both of them will fall idle in their read/recv calls, so
 
 threading works very nicely here.
 
 
 
 ChrisA

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

Re: IndexError: pop from empty list

2014-05-15 Thread chris

No, that was pretty much what I was looking for.  If anyone has an answer to 
the deeper question, that would be icing on the cake.

What is interesting is that usually the traceback shows the line of code that I 
invoke which, deep inside a library I'm using, has generated an error.  In this 
case I don't know which of my commands has spawned the error.

I can experiment, I suppose, with putting a try/catch around suspected lines of 
code...

Thanks,
Chris.


On Thursday, May 15, 2014 9:48:00 PM UTC-7, Gary Herron wrote:
 On 05/15/2014 09:36 PM, ch...@freeranger.com wrote:
 
  Any ideas about what this might mean?
 
 
 
  Running Debian Wheezy on a RaspBerry Pi and collecting data on a dispatch 
  thread that is reading input on the serial port (connected to xbee series 
  1).
 
 
 
  It happens every few days but it really chokes the program.
 
 
 
  Thanks for any tips,
 
  ChrisJ
 
 
 
 
 
 
 
 
 
  Exception in thread Thread-2:
 
  Traceback (most recent call last):
 
 File /usr/lib/python2.7/threading.py, line 552, in __bootstrap_inner
 
   self.run()
 
 File /usr/local/lib/python2.7/dist-packages/xbee/base.py, line 95, in 
  run
 
   self._callback(self.wait_read_frame())
 
 File /usr/local/lib/python2.7/dist-packages/xbee/base.py, line 400, in 
  wait_read_frame
 
   return self._split_response(frame.data)
 
 File /usr/local/lib/python2.7/dist-packages/xbee/base.py, line 288, in 
  _split_response
 
   info[parse_rule[0]] = parse_rule[1](self, info)
 
 File /usr/local/lib/python2.7/dist-packages/xbee/ieee.py, line 117, in 
  lambda
 
   lambda xbee,original: xbee._parse_samples(original['samples'])
 
 File /usr/local/lib/python2.7/dist-packages/xbee/base.py, line 357, in 
  _parse_samples
 
   digital_data_set = (sample_bytes.pop(0)  8 | sample_bytes.pop(0))
 
  IndexError: pop from empty list
 
 
 
 The error means that sample_bytes is an empty list so calling pop is an 
 
 error.
 
 
 
 Or were you asking something deeper, like *why*  sample_bytes is an 
 
 empty list?
 
 
 
 Gary Herron
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue21507] set and frozenset constructor should use operator.length_hint to guess the size of the iterator


Serhiy Storchaka added the comment:

I agree with Josh's arguments. Similar idea was already proposed and rejected 
(issue17338).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21507
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21509] json.load fails to read UTF-8 file with (BOM) Byte Order Marks


Serhiy Storchaka added the comment:

Currently json.load/loads don't support binary input. See issue17909 and 
issue19837.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21509
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21507] set and frozenset constructor should use operator.length_hint to guess the size of the iterator


STINNER Victor added the comment:

I think the argument against using PyObject_LengthHint for the general 
iterable case is that for inputs other than sets or dicts, the assumption is 
that significant deduplication will occur.

Oh... I'm dumb :) Sorry.

Another option for frozenset only: we may adjust the internal size when the 
frozenset is created from an iterator.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21507
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21027] difflib new cli interface


STINNER Victor added the comment:

 After more thought, I think this should remain in tools as a demo.

I disagree, I like the command line interface. It's very useful on Windows for 
example. It's also useful on UNIX embedded devices where Python is installed, 
but only a few UNIX tools.

If you are not convinced, please see this amazing talk of David Beazley at 
Pycon 2014:
http://pyvideo.org/video/2645/discovering-python

The patch only adds a few lines to difflib.py.

IMO difflib CLI is even more useful than tarfile CLI ;-)

It's not like no other Python module has a CLI. Modules with a CLI of Python 
3.5:

aifc
base64
calendar
cgi
code
compileall
cProfile
dis
doctest
filecmp
fileinput
formatter
ftplib
getopt
gzip
imaplib
imghdr
inspect
locale
mailcap
mimetypes
modulefinder
netrc
nntplib
pdb
pickle
pickletools
platform
poplib
pprint
profile
pstats
pyclbr
py_compile
pydoc
quopri
random
runpy
shlex
site
smtpd
smtplib
sndhdr
sre_constants
symbol
symtable
sysconfig
tabnanny
tarfile
telnetlib
textwrap
timeit
tokenize
token
trace
turtle
uu
webbrowser
zipfile

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21027
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19837] Wire protocol encoding for the JSON module


Changes by STINNER Victor victor.stin...@gmail.com:


--
nosy: +haypo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19837
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17909] Autodetecting JSON encoding


Changes by STINNER Victor victor.stin...@gmail.com:


--
nosy: +haypo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17909
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13916] disallow the surrogatepass handler for non utf-* encodings


Serhiy Storchaka added the comment:

This issue was mainly resolved in issue12892. The surrogatepass error handler 
now works with UTF-16* and UTF-32* encodings. But for other encodings it 
behaves as for UTF-8 (preserve old behavior). Should we change the behavior for 
non-UTF encodings end raise an exception (as for strict)?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13916
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19186] expat symbols should be namespaced in pyexpat again

2014-05-15 Thread Peter Kruse


Peter Kruse added the comment:

Fascinating, you are right, very good, thanks for your time and looking into 
this.

Peter

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19186
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15809] 2.7 IDLE console uses incorrect encoding.


Serhiy Storchaka added the comment:

Alternative solution is to force UTF-8 in IDLE console. But I think this will 
be more surprising, especially for Windows users.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15809
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13916] disallow the surrogatepass handler for non utf-* encodings


Serhiy Storchaka added the comment:

Here is a patch which disallows the surrogatepass handler for non-utf 
encodings. Please test it on Windows.

--
type: behavior - enhancement
versions: +Python 3.5 -Python 3.1, Python 3.2, Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13916
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13916] disallow the surrogatepass handler for non utf-* encodings


STINNER Victor added the comment:

Serhiy Storchaka wrote:
 Here is a patch

I don't see your patch.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13916
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13916] disallow the surrogatepass handler for non utf-* encodings


Serhiy Storchaka added the comment:

Oh, sorry.

--
keywords: +patch
Added file: http://bugs.python.org/file35257/surrogatepass_non_utf.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13916
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13916] disallow the surrogatepass handler for non utf-* encodings

2014-05-15 Thread Martin v . Löwis


Martin v. Löwis added the comment:

LGTM

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13916
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21510] fma documentation should provide better example.

2014-05-15 Thread Mark Dickinson


Changes by Mark Dickinson dicki...@gmail.com:


--
nosy: +mark.dickinson, skrah

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21510
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21510] fma documentation should provide better example.

2014-05-15 Thread Mark Dickinson


Mark Dickinson added the comment:

I wouldn't want to drop the simple example: I suspect that many of those 
looking at fma won't have the first idea what it does, and that first example 
shows clearly that it's a fused multiply-add.

But +1 for an example that demonstrates the single rounding, either in the 
online docs or the docstring (or both).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21510
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13916] disallow the surrogatepass handler for non utf-* encodings


Roundup Robot added the comment:

New changeset 5e98a50e0f55 by Serhiy Storchaka in branch 'default':
Issue #13916: Disallowed the surrogatepass error handler for non UTF-*
http://hg.python.org/cpython/rev/5e98a50e0f55

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13916
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21510] fma documentation should provide better example.

2014-05-15 Thread Jayanth Koushik


Jayanth Koushik added the comment:

@Mark: I agree. And perhaps it is also worth mentioning (on an unrelated note), 
that the decimal fma is not based on the internal cmath fma (it could not be) 
and unlike the cmath fma, it is no faster than an unfused multiply-add.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21510
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13916] disallow the surrogatepass handler for non utf-* encodings


Changes by Serhiy Storchaka storch...@gmail.com:


--
assignee:  - serhiy.storchaka
resolution:  - fixed
stage:  - resolved
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13916
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17909] Autodetecting JSON encoding


Serhiy Storchaka added the comment:

All dependencies for this issue are resolved now.

Here is updated patch, synchronized with tip.

--
Added file: http://bugs.python.org/file35258/json_detect_encoding_2.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17909
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21487] Assorted ipaddress performance improvements


Antoine Pitrou added the comment:

I find logical operations on negative numbers confusing in Python, so I'd 
rather stick with the first implementation.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21487
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17909] Autodetecting JSON encoding


Changes by Serhiy Storchaka storch...@gmail.com:


Removed file: http://bugs.python.org/file30133/json_detect_encoding.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17909
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21486] optimize v4 v6 netmask parsing


Serhiy Storchaka added the comment:

What I want to say, the patch LGTM, but after committing issue14373 we should 
simplify the code by using functools.lru_cache().

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21486
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21486] optimize v4 v6 netmask parsing


Antoine Pitrou added the comment:

Actually, using lru_cache(maxsize=None) would enable a simple infinite cache 
like in the patch. But it's not like a lot of code would be saved.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21486
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13916] disallow the surrogatepass handler for non utf-* encodings


STINNER Victor added the comment:

It makes sense to restrict surrogatepass to UTF-* encodings. UTF-8, UTF-16 and 
UTF-32 encoders reject surrogate characters, but not UTF-7. Is it a bug? I'm 
asking because PyCodec_SurrogatePassErrors() doesn't support UTF-7.

IMO your change is important enough to be mentionned in What's new Python 3.5 
document, and maybe also in the documentation of the codecs module.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13916
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13916] disallow the surrogatepass handler for non utf-* encodings


STINNER Victor added the comment:

Windows buildbots are unhappy.

http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/8355/steps/test/logs/stdio

==
ERROR: test_surrogatepass_handler (test.test_codecs.CP65001Test)
--
Traceback (most recent call last):
  File 
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_codecs.py,
 line 883, in test_surrogatepass_handler
self.assertEqual(abc\ud800def.encode(cp65001, surrogatepass),
UnicodeEncodeError: 'CP_UTF8' codec can't encode character '\ud800' in position 
3: invalid character

==
FAIL: test_encode (test.test_codecs.CP65001Test)
--
Traceback (most recent call last):
  File 
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_codecs.py,
 line 818, in test_encode
encoded = text.encode('cp65001', errors)
UnicodeEncodeError: 'CP_UTF8' codec can't encode character '\udc80' in position 
0: invalid character

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_codecs.py,
 line 821, in test_encode
'errors=%r: %s' % (text, errors, err))
AssertionError: Unable to encode '\udc80' to cp65001 with 
errors='surrogatepass': 'CP_UTF8' codec can't encode character '\udc80' in 
position 0: invalid character

==
FAIL: test_cp1252 (test.test_codecs.CodePageTest)
--
Traceback (most recent call last):
  File 
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_codecs.py,
 line 2849, in test_cp1252
(b'[\x98]', 'surrogatepass', None),
  File 
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_codecs.py,
 line 2781, in check_decode
codecs.code_page_decode, cp, raw, errors, True)
AssertionError: UnicodeDecodeError not raised by code_page_decode

--
resolution: fixed - 
status: closed - open

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13916
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13916] disallow the surrogatepass handler for non utf-* encodings


Serhiy Storchaka added the comment:

Here is a patch, which adds support for cp65001 and fixes test_cp1252. Please 
test it on Windows Vista.

Lone surrogates are not illegal in UTF-7 (see RFC 1642), so error handler is 
not called and explicit support of UTF-7 is not needed.

Could you please help with documenting this change in What's new Python 3.5 
document? I don't think this change is worth special mentioning in codecs 
documentation, it is already documented that surrogatepass is supported only 
for utf-8, utf-16* and utf-32*.

--
Added file: http://bugs.python.org/file35259/surrogatepass_cp_utf8.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13916
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21508] C API PyArg_ParseTuple doc is innacurate

2014-05-15 Thread Steve


Steve added the comment:

I would prefer the function to return bool.  But what I prefer is irrelevant, 
what counts is accuracy and clarity.  And to this end, the return type and the 
comment have to match.

For a int return value, the document should mention a condition relative to an 
integer value (e.g.: ==0, !=0, ==-1, 0, ==42, etc).

In this particular case, to minimize the changes, success should be defined as 
!=0 and failure ==0.

Although there is a bigger problem that I mentioned in that the Python C API 
uses two different return value standards: in most places, ==0 is success, in 
this case (and some other places) ==0 is a failure.

As for implementation constraints I don't see how making the documentation 
accurate affects that in any way.  If ever the implementation is expanded, the 
documentation will need to change.  The only alternative is to make the doc 
vague or simply wrong.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21508
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13916] disallow the surrogatepass handler for non utf-* encodings


STINNER Victor added the comment:

 Here is a patch, which adds support for cp65001

The name of the encoding is cp65001, not something like cp-utf8.

And there is no alias like cp_65001, there is only cp65001.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13916
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17909] Autodetecting JSON encoding

2014-05-15 Thread Chris Rebert


Chris Rebert added the comment:

You'll need to also update the Character Encodings subsection of the json 
docs.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17909
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13916] disallow the surrogatepass handler for non utf-* encodings


Serhiy Storchaka added the comment:

But an exception reports about CP_UTF8.

--
title: disallow the surrogatepass handler for non  utf-* encodings - 
disallow the surrogatepass handler for non utf-* encodings

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13916
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21511] Thinko in Lib/quopri.py

2014-05-15 Thread Paul Sokolovsky


New submission from Paul Sokolovsky:

Lib/quopri.py for version 3.3..3.5-tip contains following code:

ESCAPE = b'='
...
line = input.readline()
if not line: break
i, n = 0, len(line)
if n  0 and line[n-1:n] == b'\n':
...
elif i+1  n and line[i+1] == ESCAPE:


So, ESCAPE is defined as bytes, we see that line is read as bytes, and 
characters are accessed using idiom like line[n-1:n], but then it uses 
line[i+1], which returns int and thus will never be equal to ESCAPE.

I'm not sure what exact semantic condition that branch represents, for me it 
looks like == sequence to be decoded as =. But I don't see such encoding 
variant in http://en.wikipedia.org/wiki/Quoted-printable . Either way, 
replacing that condition with and False, still passes test_quopri.py

--
components: Library (Lib)
messages: 218618
nosy: pfalcon
priority: normal
severity: normal
status: open
title: Thinko in Lib/quopri.py
type: behavior
versions: Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21511
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21512] time module becomes None after raise SystemExit

2014-05-15 Thread Ryder Lewis


New submission from Ryder Lewis:

I'm not sure if this is a bug or expected behavior, but basically what I want 
to do is log the timestamp when an application exits. Sample script to 
illustrate the issue:

 try.py 
import time

class A():
def __init__(self):
print(Initializing A. The time is {}.format(time.time()))

def __del__(self):
if time is None:
print(time is None!)
else:
print(Deleting A. The time is {}.format(time.time()))

a = A()
raise SystemExit()

=

When running this script multiple times, there are 3 possible outcomes:

 outcome #1 (happens about 25% of my trial runs, what I would expect is 
correct behavior) 
Initializing A. The time is 1400175810.4806361
Deleting A. The time is 1400175810.483156

 outcome #2 (happens about 50% of my trial runs) 
Initializing A. The time is 1400175814.1646852
time is None!

 outcome #3 (happens about 25% of my trial runs) 
Initializing A. The time is 1400175809.6802816
Exception ignored in: bound method A.__del__ of __main__.A object at 
0x7fb125eab5f8
Traceback (most recent call last):
  File ./try.py, line 12, in __del__
TypeError: 'NoneType' object is not callable

--
components: Interpreter Core
messages: 218619
nosy: ryder.lewis
priority: normal
severity: normal
status: open
title: time module becomes None after raise SystemExit
type: behavior
versions: Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21512
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21512] time module becomes None after raise SystemExit

2014-05-15 Thread Ezio Melotti


Changes by Ezio Melotti ezio.melo...@gmail.com:


--
nosy: +benjamin.peterson, pitrou
resolution:  - not a bug
status: open - pending

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21512
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21512] time module becomes None after raise SystemExit


Antoine Pitrou added the comment:

Well, let's call it a limitation rather than a bug.
When creating a global variable (such as a in your example), that variable is 
kept alive at least as long as the module containing it. However, modules 
usually live until very late in the interpreter shutdown process, *especially* 
the __main__ module. So, by the time a gets garbage-collected, other globals 
or modules may already have been wiped.

Unfortunately, I don't think there's much we can do to improve this. The answer 
to your specific problem is to use the atexit module instead, since an atexit 
callback is guaranteed to be called with a normal execution environment, before 
it starts being garbage-collected.

--
status: pending - open

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21512
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21512] time module becomes None after raise SystemExit


Changes by Antoine Pitrou pit...@free.fr:


--
resolution: not a bug - wont fix
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21512
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21486] optimize v4 v6 netmask parsing


Roundup Robot added the comment:

New changeset 2158614e1607 by Antoine Pitrou in branch 'default':
Issue #21486: Optimize parsing of netmasks in ipaddress.IPv4Network and 
ipaddress.IPv6Network.
http://hg.python.org/cpython/rev/2158614e1607

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21486
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21487] Assorted ipaddress performance improvements


Roundup Robot added the comment:

New changeset 2711677cf874 by Antoine Pitrou in branch 'default':
Issue #21487: Optimize ipaddress.summarize_address_range() and 
ipaddress.{IPv4Network,IPv6Network}.subnets().
http://hg.python.org/cpython/rev/2711677cf874

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21487
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15809] 2.7 IDLE console uses incorrect encoding.

2014-05-15 Thread Terry J. Reedy


Terry J. Reedy added the comment:

Idle 3.x has Martin's patch, except that the 'if' clause is merely commented 
out rather than removed. (Perhaps someone wanted to test the removal first.  It 
should now be deleted.)

My 2.7 Idle has Default Source Encoding ... [x] None. Since there is nothing 
for this in either config-main.def, I presume it is the default -- at least for 
Windows. But Martin says it is not relevant.

'Surprising' suggests that you think or know that doing the same in 2.7 might 
introduce other discrepancies from console behavior. I am reluctant to do that, 
though it is possible that it might make Idle *better* than the console.

I would definitely be reluctant to do something more wide-ranging than your 
patch without extensive tests, and even that patch should have some tests, some 
of which pass now and continue to pass, and other that fail now and pass with 
the patch.

Irdb said As a Windows user, currently I can't print u'йцук' in interactive 
mode and get an Unsupported characters in input error because my default 
system encoding (cp1256) can't encode Russian.)

Idle 2.7
 u'йцук'
Unsupported characters in input

Console 2.7
 u''
u''
 u''[0] == '?'
True

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15809
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20826] Faster implementation to collapse consecutive ip-networks


Roundup Robot added the comment:

New changeset 8867874a2b7d by Antoine Pitrou in branch 'default':
Issue #20826: Optimize ipaddress.collapse_addresses().
http://hg.python.org/cpython/rev/8867874a2b7d

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20826
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20826] Faster implementation to collapse consecutive ip-networks


Antoine Pitrou added the comment:

I've now committed this. exhuma, if you have any further observations or 
results, don't hesitate to post them!

--
resolution:  - fixed
stage: patch review - commit review
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20826
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21487] Assorted ipaddress performance improvements


Changes by Antoine Pitrou pit...@free.fr:


--
resolution:  - fixed
stage: patch review - resolved
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21487
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21486] optimize v4 v6 netmask parsing


Changes by Antoine Pitrou pit...@free.fr:


--
resolution:  - fixed
stage: patch review - resolved
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21486
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15809] 2.7 IDLE console uses incorrect encoding.

2014-05-15 Thread Martin v . Löwis


Changes by Martin v. Löwis mar...@v.loewis.de:


--
nosy:  -loewis

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15809
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21364] Documentation Recommends Broken Pattern


Roundup Robot added the comment:

New changeset 4621bb82ceec by Antoine Pitrou in branch '3.4':
Issue #21364: remove recommendation of broken pattern.
http://hg.python.org/cpython/rev/4621bb82ceec

New changeset dbf728f9a2f0 by Antoine Pitrou in branch 'default':
Issue #21364: remove recommendation of broken pattern.
http://hg.python.org/cpython/rev/dbf728f9a2f0

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21364
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21364] Documentation Recommends Broken Pattern


Antoine Pitrou added the comment:

Thanks for the report, Armin. I've removed that recommendation and changed the 
surrounding wording to insist that standard streams are always text streams.

--
resolution:  - fixed
stage:  - resolved
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21364
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21364] Documentation Recommends Broken Pattern

2014-05-15 Thread Armin Ronacher


Armin Ronacher added the comment:

To avoid further problems may I also recommend documenting how exactly people 
are supposed to wrap sys.stdout and so forth.  Clearly putting a StringIO there 
is insufficient as StringIO does not have a buffer.

Something like this maybe?

import io
buf = io.BytesIO()
sys.stdout = io.TextIOWrapper(buf,
encoding='utf-8',
errors='strict', # or surrogate-escape as this is the default for stdout 
now? not sure
line_buffering=True
)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21364
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21364] Documentation Recommends Broken Pattern


Antoine Pitrou added the comment:

 To avoid further problems may I also recommend documenting how exactly
 people are supposed to wrap sys.stdout and so forth.  Clearly putting
 a StringIO there is insufficient as StringIO does not have a buffer.

I would like to know of some situations where you want to write some
code that accesses standard streams as binary *and* don't control the
application setup (i.e. library code rather than application code). It
seems to me that a library should take the binary streams as parameters
rather than force the use of stdin/stdout.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21364
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21513] speed up some ipaddress properties