[Python-Dev] [AST] Procedure for AST Branch patches

2005-03-20 Thread Nick Coghlan
What's the current situation with providing fixes for AST branch problems?
There's a simple one in parsenumber in Python/ast.c relating to int/long 
unification and octal literals. The fix is just a direct copy of the relevant 
code from parsenumber in the old compile.c.

Fixing it means the only failures left in test_grammar are those relating to 
generator expressions.

I've put a patch on SF (1166879) and assigned it to Jeremy with group AST.
Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Patch review: all webbrowser.py related patches up to 2005-03-20

2005-03-20 Thread rodsenra
1144816 webbrowser.Netscape.open bug fix
-
1077979 Simple webbrowser fix for netscape -remote
-

 1144816 and 1077979 are the the same patch, as documented
  in a comment for 1144816  by Oleg Broytmann.

 The wrong behaviour was reported to happen in Mozilla (unspecified
 version),  Netscape 7.2 and Mozilla-firefox (unspecified version).

 I could not reproduce the problem  neither with Mozilla 1.7.2 nor
 with Firefox 1.0.1. Nevertheless, applying the patch does not break
 current functionality and might fix bugs in older browsers.

 I recommend applying 1077979, and closing 1144816.


954628  Replacement for webbrowser.py which has problems.
-

 There is no patch attached, but the whole file was uploaded. Twice!
 There is already a comment by Oleg Broytmann telling the person
 to re-submit it in as a proper patch.

 There are multiple changes in it, perhaps multiples patches.
 Each addresing  a single change.
 Some of the proposed changes are declared untested.

 Some changes are controversial, like using a new environment variable
 PYTHONBROWSER prior to checking BROWSER.
 There are no references to this being discussed in python-dev.
 IMO this adds unecessary complexity, if the user is not satisfied with
 the BROWSER settings is easier and better to reconfigured it than
 to create a new  variable.

 I recommend closing 954628.


728278  Multiple webbrowser.py bug fixes / improvements
--

 Against the [http://python.org/patches/  Patch Submission Guidelines]
 this entry has uploaded both the whole file and .tgz, but no patch file.

 The  large numbers of changes make it difficult to review.

 All the changes were documented to the top of the file,
 I don't believe they  belong there. At least that is not complaint
 to the first rule in  http://www.python.org/patches/style.html

 There are several OS X specific corrections that I'm unable to
 reproduce/validate, since I have no access to that platform.

 The modules was renamed to wingwebbrowser.py and the test case was built
 using this name. I believe this is inadequate, the original module name
 should be kept.

 There are three categories of changes: bug fixes, internal changes and
 interface changes.
 IMO it would be better to break this patch in at least three, matching
 these types of changes. Bug fixes would have a higher priority, less
 chance to break backward compatibility and more chance to be
 incorporated earlier.

 It should be applied before 1077979, otherwise that fix would be reversed.

 In spite of the formatting comments above, there are *valuable* changes
 in the submitted file.

 This is a nice candidate to be tackled in a Python Bug Day, since it
 functionality involves a broad range of platforms and user browsers
 preferences. Moreover, thourough test cases are hard to be cooked.

 I recommend keeping it open until somebody reshaped it properly
 and then applying it.


754022  Enhanced webbrowser.py
--

 This patch is properly formatted.

 I would change 'return 1' for 'return True', since this
 targets Py 2.4.x or above.

 It address some of the issues already addressed in entry 728278,
 since it proposes less changes and it is properly formatted I
 recommend applying it before 728278.


1166780  Fix _tryorder in webbrowser.py
---

This is my own patch.

At the present time (Py2.4) documentation says:

Under Unix, if the environment variable BROWSER exists,
it is interpreted to override the platform default list of
browsers,...

(extract from Python-2.4/Doc/html/lib/module-webbrowser.html)

But, when the environment variable BROWSER is messed up,
there is no reason not to try the other detected browser alternatives.

In this patch, if the BROWSER variable is Ok, than it
is respected. Otherwise, the previously detected browsers are tryied
out as if BROWSER variable never existed.

This does not break backward compatibility and adds
more chance for webbrowser.open() to succeed.

This patch was made against CVS head 2005-03-20, and
aims to 2.5, but can safely be apllied to any 2.4.x bug
fix release.

--

best regards,
Rod Senra

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Re: Change 'env var BROWSER override' semantics in webbrowser.py

2005-03-20 Thread rodsenra
 On Friday 18 March 2005 17:44, Reinhold Birkenfeld wrote:
   Additionally, there are several patches on SF that pertain to
   webbrowser.py; perhaps you can review some of them...

By all means. Done!


 Given the time I haven't been able to devote to the webbrowser module, a
 consolidated set of reviews would be very helpful.

 Patch reviews should be written in the tracker, as always, and a summary
 of all the webbrowser-related patches in a single email to python-dev.

Thank you. That was valuable information.

best regards,
Rod Senra

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Change 'env var BROWSER override' semantics in webbrowser.py

2005-03-20 Thread rodsenra
 Rodrigo Dias Arruda Senra wrote:
 I propose a small change in webbrowse.py module.

 I think I'm generally in favour of such a change.


Thanks. I'm glad to know!

 - please don't post patches to python-dev,


Sorry. I'm aware of that. For clarification's sake,
I was not _posting_ a patch to the mailing list.
My intention was to *discuss* the patch, and since it was
so small, I found easier to copy it than to explain it.

Since nobody opposed to the idea, I already have submitted
a patch to the tracker (1166780  Fix _tryorder in webbrowser.py).

 - please accompany your change with a documentation patch.

Indeed. Already available in sf.

 I would be willing to waive the test case requirement here as
 unimplementable.

That is a relief in this particular case wink.

Thank you for all your advice.

best regards,
Rod Senra


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [AST] Procedure for AST Branch patches

2005-03-20 Thread Brett C.
Nick Coghlan wrote:
What's the current situation with providing fixes for AST branch problems?
Make sure AST is used in the subject line; e.g., [AST] at the beginning. 
Unfortunately the AST group is only available for patches; not listed for bug 
reports (don't know why; can this be fixed?).

Other than that, just assign it to me since I will most likely be doing AST 
work in the near future.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [AST] Procedure for AST Branch patches

2005-03-20 Thread Tim Peters
[Brett C.]
 Make sure AST is used in the subject line; e.g., [AST] at the beginning.
 Unfortunately the AST group is only available for patches; not listed for bug
 reports (don't know why; can this be fixed?).

Your wish is my command:  there's an AST group in Python's bug tracker
now.  FYI, each tracker has a distinct set of metadata choices, and
nothing shows up in any of 'em by magic.

 Other than that, just assign it to me since I will most likely be doing AST
 work in the near future.

Unfortunately, auto-assign keys off Category instead of Group metadata.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Re: Change 'env var BROWSER override' semantics in webbrowser.py

2005-03-20 Thread Oleg Broytmann
On Sun, Mar 20, 2005 at 11:40:27AM -0300, [EMAIL PROTECTED] wrote:
 Perhaps you could focus in 728278. It addresses some of the issues you
 have addressed in 754022, but it is not properly formatted.

   I started to look at it yesterday, but it's so big and does so many
things at once... it requires a lot of time...

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


RE: [Python-Dev] [AST] Procedure for AST Branch patches

2005-03-20 Thread Grant Olson
 

 Make sure AST is used in the subject line; e.g., [AST] at 
 the beginning. 
 Unfortunately the AST group is only available for patches; 
 not listed for bug reports (don't know why; can this be fixed?).
 
 Other than that, just assign it to me since I will most 
 likely be doing AST work in the near future.
 


Brett,

I sent a few outstanding ones your way.  I hate to complain again, I know
everyone involved are volunteers, etc, etc; but it'd be really nice if
someone could take a look at '[ 742621 ] ast-branch: msvc project sync'.
The patch is almost two years old now, has been updated for VC7.1 and still
hasn't been checked in.  Without this, any Windows developers who check out
the ast-branch will experience a broken build.

-Grant

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [AST] Procedure for AST Branch patches

2005-03-20 Thread Brett C.
Grant Olson wrote:
 


Make sure AST is used in the subject line; e.g., [AST] at 
the beginning. 
Unfortunately the AST group is only available for patches; 
not listed for bug reports (don't know why; can this be fixed?).

Other than that, just assign it to me since I will most 
likely be doing AST work in the near future.


Brett,
I sent a few outstanding ones your way.  I hate to complain again, I know
everyone involved are volunteers, etc, etc; but it'd be really nice if
someone could take a look at '[ 742621 ] ast-branch: msvc project sync'.
The patch is almost two years old now, has been updated for VC7.1 and still
hasn't been checked in.  Without this, any Windows developers who check out
the ast-branch will experience a broken build.
The problem is that I don't have access to a Windows machine so there is no way 
to verify the patch myself.  I will try to get someone here to verify the 
patch, but I am not comfortable doing a blind commit.  If one other person 
could verify that the patch is good I will apply it.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Re: [Csv] Example workaround classes for using Unicode with csv module...

2005-03-20 Thread Andrew McNamara
I added UnicodeReader and UnicodeWriter example classes to the csv module
docs just now.  They mention problems with ASCII NUL characters (which I
vaguely remember - NUL-terminated strings are used internally, right?).  Do
NULs still present a problem?  I saw nothing in the log messages that
mentioned ascii or nul so I presume it is.

That's right - it still uses null terminated strings internally, and the
various special characters (quotechar, escapechar, etc) use null to mean
not specified. Fixing this would cause much upheaval.

Here's what I added.  Let me know if you think it needs any corrections,
especially if there's a better way to word as long as you avoid encodings
like utf-16 that use NULs.  Can that just be as long as you avoid
multi-byte encodings other than utf-8?  

I think only utf-8 provides the guarantees needed for this to work -
specifically, multi-byte characters need to have the high bit set
(otherwise a delimiter or other special character appearing within a
multi-byte character would upset the parsing), while at the same time
having single byte characters for the characters with special meaning
to the parser: note also that none of the special characters (quotechar,
delimiter, escapechar, etc) can be a multi-byte sequence.

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Draft PEP to make file objects support non-blocking mode.

2005-03-20 Thread Donovan Baarda
On Fri, 2005-03-18 at 20:41 -0500, James Y Knight wrote:
 On Mar 18, 2005, at 8:19 PM, Greg Ward wrote:
  Is having to use fcntl and os really so awful?  At least it requires
  the programmer to prove he knows what he's doing putting this file
  into non-blocking mode, and that he really wants to do it.  ;-)

Consider the following. This is pretty much the only way you can use
popen2 reliably without knowing specific behaviours of the executed
command;

import os,fnctl,select

def process_data(cmd,data):
  child_in, child_out = os.popen2(cmd)
  child_in = child_in.fileno()# /
  flags = fcntl.fcntl(child_in, fcntl.F_GETFL)# |1)
  fcntl.fcntl(child_in, fcntl.F_SETFL, flags | os.O_NONBLOCK) # \
  child_out = child_out.fileno()  # /
  flags = fcntl.fcntl(child_out, fcntl.F_GETFL)   # |2)
  fcntl.fcntl(child_out, fcntl.F_SETFL, flags | os.O_NONBLOCK)# \
  ans = 
  li = [child_out]
  lo = [child_in]
  while li or lo:
i,o,e = select.select(li,lo,[]) # 3
if i:
  buf = os.read(child_out,2048) # 4
  if buf:
ans += buf
  else:
li=[]
if o:
  if data:
count=os.write(child_in,data[:2048])   # 4
data = data[count:]
  else:
lo=[]
 return ans

For 1) and 2), note that popen2 returns file objects, but as they cannot
be reliably used as file objects, we ignore them and grab their
fileno(). Why does popen2 return file objects if they cannot reliably be
used? The flags get/set using fnctl is arcane stuff for what is pretty
much essential operations after a popen2. These could be replaced by;

 child_in.setblocking(False)
 child_out.setblocking(False)

For 3), select() can operate on file objects directly. However, since
you cannot reliably read/write file objects in non-blocking mode, we use
the fileno's. Why can select operate with file objects if file objects
cannot be reliably read/written?

For 4), we are using the os.read/write methods to operate on the
fileno's. Under the proposed PEP we could use the file objects
read/write methods instead.

I guess the thing that annoys me the most is the asymmetry of popen2 and
select using file objects, but needing to use the os.read/write and
fileno()'s for reading and writing.

 I'd tend to agree. :) Moreover, I don't think fread/fwrite are 
 guaranteed to work as you would expect with non-blocking file 
 descriptors. So, providing a setblocking() call to files would require 
 calling read/write instead of fread/fwrite in all the file methods, at 
 least when in non-blocking mode. I don't think that's a good idea.

Hmm.. I assumed file.read() and file.write() were implemented using
read/write from their observed behaviour. The documentation of
fread/fwrite doesn't mention the behaviour in non-blocking mode at all.
The observed behaviour suggests that fread/fwrite are implemented using
read/write and hence get the same behaviour. The documentation implies
that the behaviour in non-blocking mode will reflect the behaviour of
read/write, with EAGAIN errors reported via ferror() indicating empty
non-blocking reads/writes.

If the behaviour of fread/fwrite is indeed indeterminate under
non-blocking mode, then yes, file objects in non-blocking mode would
have to use read/write instead of fread/fwrite. However, I don't think
this is required.

I know this PEP is kinda insignificant and minor. It doesn't save much,
but it doesn't change much, and makes things a bit cleaner.

-- 
Donovan Baarda [EMAIL PROTECTED]
http://minkirri.apana.org.au/~abo/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Draft PEP to make file objects support non-blocking mode.

2005-03-20 Thread Greg Ewing
On 18 March 2005, Donovan Baarda said:

Many Python library methods and classes like select.select(), os.popen2(),
and subprocess.Popen() return and/or operate on builtin file objects.
However even simple applications of these methods and classes require the
files to be in non-blocking mode.
I don't agree with that. There's no need to use non-blocking
I/O when using select(), and in fact things are less confusing
if you don't.
The read method's current behaviour needs to be documented, so its actual
behaviour can be used to differentiate between an empty non-blocking read,
and EOF.  This means recording that IOError(EAGAIN) is raised for an empty
non-blocking read.
Isn't that unix-specific? The file object is supposed to
provide a more or less platform-independent interface, I
thought.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] docstring before function declaration

2005-03-20 Thread Nicholas Jacobson
IIRC, Guido once mentioned that he regretted not
setting function docstrings to come before the
function declaration line, instead of after.

i.e.

This describes class Bar.
class Bar:
...

Or with a decorator:

This describes class Bar.
@classmethod
class Bar:
...

Versus the current method:

class Bar:
This describes class Bar.
def foo:
...

where the docstring looks like it refers to foo, not
Bar.

I think that commenting the function before its
declaration, at the same tabbed point, increases the
code's readability.

What do you think about making this change at some
point (e.g. Python 3000)?  Or if not, then having the
option to toggle to this layout?

Thanks,

--Nick Jacobson




__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com