Re: [Python-Dev] Exception Reorg PEP revised yet again

2005-08-12 Thread Thomas Heller 
Brett Cannon <[EMAIL PROTECTED]> writes:

> On 8/10/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> > > Then I don't follow what you mean by "moved under os".
>> >
>> > In other words, to get the exception, do ``from os import
>> > WindowsError``.  Unfortunately we don't have a generic win module to
>> > put it under.  Maybe in the platform module instead?
>> 
>> -1 on either.  The WindowsError exception needs to in the main exception
>> tree.  It occurs in too many different modules and applications.  That
>> is a good reason for being in the main tree.
>> 
>
> Where is it used so much?  In the stdlib, grepping for WindowsError
> recursively in Lib in 2.4 turns up only one module raising it
> (subprocess) and only two modules with a total of three places of
> catching it (ntpath once, urllib twice).  In Module, there are no
> hits.
>

I don't know how you've been grepping, but the Python api functions to
raise WindowsErrors are named like PyErr_SetFromWindowsErr() or so.

Typically, WindowsErrors are raised when Win32 API functions fail.
In the core extension modules, I find at least mmapmodule.c,
posixmodule.c, _subprocess.c, and _winreg.c raising them.  It may be a
bit hidden, because the docs for _winreg mention only EnvironmentError,
but they are wrong:

C:\>py
Python 2.5a0 (#60, Jul  4 2005, 19:53:27) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import _winreg
>>> _winreg.OpenKey(_winreg.HKEY_CLASSES_ROOT, "blah")
Traceback (most recent call last):
  File "", line 1, in ?
WindowsError: [Errno 2] Das System kann die angegebene Datei nicht finden
>>>

>> If the name bugs you, I would support renaming it to PlatformError or
>> somesuch.  That would make it free for use with Mac errors and Linux
>> errors.  Also, it wouldn't tie a language feature to the name of an
>> MS product.
>> 
>
> I can compromise to this if others prefer this alternative.  Anybody
> else have an opinion?

Win32 has the FormatError() api to convert error codes into descriptions
- these descriptions are very useful, as are the error codes when you
catch errors in client code.

I would say as long as the Python core contains win32 specific modules
like _winreg WindowsError should stay.  For the name, I have no
preference but I see no need to change it.

Thomas

PS: For ctypes, it doesn't matter if WindowsError stays or not.  No
problem to invent my own WindowsError if it goes away.

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

Re: [Python-Dev] Terminology for PEP 343

2005-08-12 Thread Christos Georgiou 
"Michael Hudson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>
> Guard?  Monitor?  Don't really like either of these.
>

I know I am late, but since guard means something else, 'sentinel' (in the 
line of __enter__ and __exit__ interpretation) could be an alternative. 
Tongue in cheek. 


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

[Python-Dev] dev listinfo page (was: Re: Python + Ping)

2005-08-12 Thread David Wilson 
Hello,

Would it perhaps be an idea, given the number of users posting to the 
dev list, to put a rather obvious warning on the listinfo page:

http://mail.python.org/mailman/listinfo/python-dev

Something like


 Do not post general Python questions to this list! For help
 with Python please see the Python help page!




David.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] plans for 2.4.2 and 2.5a1

2005-08-12 Thread Michael Hudson 
Anthony Baxter <[EMAIL PROTECTED]> writes:

> So I'm currently planning for a 2.4.2 sometime around mid September. I figure 
> we cut a release candidate either on the 7th or 14th, and a final a week 
> later. 

Cool.  I'm not sure how many outstanding bugs should be fixed before
2.4.2.  Some stuff to do with files with PEP 263 style declarations?
(Walter?  I've lost track of these).

I think I should probably just check my fix for "PyXxx_Check(x) trusts
x->ob_type->tp_mro" (http://python.org/sf/1153075) in to both
branches, unless someone can think of a good reason not to (Armin?).
(The whole area could do with some work, really, but that's another
story).

> In addition, I'd like to suggest we think about a first alpha of 2.5 sometime 
> during March 2006, with a final release sometime around May-June. This would 
> mean (assuming people are happy with this) we need to make a list of what's 
> still outstanding for 2.5. There's a bunch of accepted PEPs that are waiting 
> for code. Once that's done, there will be a final 2.4.3 sometime after or 
> close to the 2.5 final release.

I have some outstanding patches:

1) My PEP 343 implementation (http://python.org/sf/1235943).  Needs
   reviewing, but docs are in another patch.  I also recently realized
   that my patch is incomplete, we should accept stuff like this:

  with cm as (a,b,c): ...

   where cm.__enter__ returns a 3-sequence.  My patch just allows a
   NAME after the 'as' pseudo-keyword (if anyone else wants to fix
   this, be my guest :)

2) The new-style exceptions patch (http://python.org/sf/1104669).
   This mostly needs documentation, but could also do with
   review/testing.

3) "explicit sign variable for longs" (http://python.org/sf/119).
   This is a user-invisible patch, really, so I'm not so concerned
   about it (I'd like to follow it up by emitting DeprecationWarnings
   on ob_size abuse in 2.6 and disallowing it in 2.7 -- or maybe we
   could even emit DeprecationWarnings in 2.5 already).

4) "__slots__ for subclasses of variable length types"
   (http://python.org/sf/1173475) -- this is very pie-in-the-sky and
   in fact the attached patch is completely broken, but I think work
   in this area would still be a good thing.  Review the others before
   looking at this one, please :)

... then there's the ast-branch, of course ...

Is there a 2.5 release PEP yet?

Cheers,
mwh

-- 
  If i don't understand lisp, it would be wise to not bray about
  how lisp is stupid or otherwise criticize, because my stupidity
  would be archived and open for all in the know to see.
-- Xah, comp.lang.lisp
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] plans for 2.4.2 and 2.5a1

2005-08-12 Thread Walter Dörwald 
Michael Hudson wrote:

> Anthony Baxter <[EMAIL PROTECTED]> writes:
> 
>>So I'm currently planning for a 2.4.2 sometime around mid September. I figure 
>>we cut a release candidate either on the 7th or 14th, and a final a week 
>>later. 
> 
> Cool.  I'm not sure how many outstanding bugs should be fixed before
> 2.4.2.  Some stuff to do with files with PEP 263 style declarations?
> (Walter?  I've lost track of these).

True, there's a whole bunch of them (mostly duplicates):

Bug #1076985: Incorrect behaviour of StreamReader.readline leads to 
crash (fixed)
Bug #1089395: segfault/assert in tokenizer (fixed)
Bug #1098990: codec readline() splits lines apart (fixed)
Bug #1163244: Syntax error on large file with MBCS encoding (open)
Bug #1175396: codecs.readline sometimes removes newline chars (open)
Bug #1178484: Erroneous line number error in Py2.4.1 (open)
Bug #1200686: SyntaxError raised on win32 for correct files (open, 
probably duplicate)
Bug #1211639: parser tells invalid syntax with correct code (duplicate)
Bug #1218930: Parser chokes on big files (duplicate)
Bug #1225059: Line endings problem with Python 2.4.1 cause imports to 
fail (duplicate)
Bug #1241507: StreamReader broken for byte string to byte string codecs 
(fixed)
Bug #1251631: Python 2.4.1 crashes when importing the attached script 
(open, probably duplicate)
Patch #1101726: Patch for potential buffer overrun in tokenizer.c (applied)

Most of them are fixed. #1178484 is waiting for a final OK.

Bye,
Walter Dörwald
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] plans for 2.4.2 and 2.5a1

2005-08-12 Thread Barry Warsaw 
On Thu, 2005-08-11 at 20:51, Anthony Baxter wrote:
> So I'm currently planning for a 2.4.2 sometime around mid September. I figure 
> we cut a release candidate either on the 7th or 14th, and a final a week 
> later. 

Cool.  I'd like to commit the patches in this bug report:

https://sourceforge.net/tracker/index.php?func=detail&aid=900092&group_id=5470&atid=105470

which fixes a long standing hotshot bug.  Any objections?

-Barry



signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] set.remove feature/bug

2005-08-12 Thread Paolino 
I can't contact sourceforge bug tracker sorry.

set.remove is trying to freeze sets when they are used as keys.No matter 
  if an __hash__ method is defined.

This is incoherent with Set.remove and dict.__delete__ & co.

If this is a feature ,then I ask strongly to keep sets module in the 
stdlib for ever.

Or if there is a workaround, please tell me here because python-list 
didn't help.

class H(set):
def __hash__(self):return id(self)
s=H()

f=set()
f.add(s)
f.remove(s) #  this fails

Regards Paolino
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] set.remove feature/bug

2005-08-12 Thread Raymond Hettinger 
[Paolino]
> I can't contact sourceforge bug tracker sorry.

I've added a bug report for you:
   www.python.org/sf/1257731


> set.remove is trying to freeze sets when they are used as keys.No
matter
>   if an __hash__ method is defined.

Will fix.  Feel free to email me off-list with any questions.



Raymond

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

Re: [Python-Dev] plans for 2.4.2 and 2.5a1

2005-08-12 Thread Christos Georgiou 
"Michael Hudson" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Anthony Baxter <[EMAIL PROTECTED]> writes:
>
>> So I'm currently planning for a 2.4.2 sometime around mid September. I 
>> figure
>> we cut a release candidate either on the 7th or 14th, and a final a week
>> later.
>
> Cool.  I'm not sure how many outstanding bugs should be fixed before
> 2.4.2.  Some stuff to do with files with PEP 263 style declarations?
> (Walter?  I've lost track of these).

This is a serious issue (spurious syntax errors).

One bug about files with encoding declarations is www.python.org/sf/1163244 
.  So far, it seems that source files having a size of f*n+x (for some small 
indeterminate value of x, and f is a power of 2 like 512 or 1024) 
occasionally fail to compile with spurious syntax errors.  (I once had a 
file show up the line with the "syntax error", and the reported line was 
comprised half from the failing line and half from the line 
above --unfortunately I kept the file for examination in a USB key that some 
colleague formatted).  The syntax errors disappear if the coding declaration 
is removed or if some blank lines are inserted before the failing line.

I think this occurs only on Windows, so it should be something to do with 
line endings and buffering.

At the moment I'm trying to create a minimal file that when imported fails 
with 2.4.1 .  I'll update the case as soon as I have one, but I wanted to 
draw some attention in python-dev in case it rings a bell. 


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

Re: [Python-Dev] plans for 2.4.2 and 2.5a1

2005-08-12 Thread Christos Georgiou 
> At the moment I'm trying to create a minimal file that when imported fails
> with 2.4.1 .  I'll update the case as soon as I have one, but I wanted to
> draw some attention in python-dev in case it rings a bell.

Please ignore my previous message --through gmane I saw only mwh's message, 
and after sending my reply, I got Walter's message. 


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

Re: [Python-Dev] plans for 2.4.2 and 2.5a1

2005-08-12 Thread Josiah Carlson 
For 2.5a1...

Some exposure of _PyLong_AsByteArray() and _PyLong_FromByteArray() to
Python. There was a discussion about this almost a year ago
(http://python.org/sf/1023290), and no mechanism (struct format code
addition, binascii.tolong/fromlong, long.tostring/fromstring, ...)
actually made it into Python 2.4 .  At this point, I'd be happy to get
/any/ mechanism, with a preference to struct and/or binascii (I'd put
them in both, if only because different groups of people people may look
for them in both places, and people who use one tend to like to use that
one for as much as possible, and because the code additions in both are
minor).

 - Josiah


Anthony Baxter <[EMAIL PROTECTED]> wrote:
> 
> So I'm currently planning for a 2.4.2 sometime around mid September. I figure 
> we cut a release candidate either on the 7th or 14th, and a final a week 
> later. 
> 
> In addition, I'd like to suggest we think about a first alpha of 2.5 sometime 
> during March 2006, with a final release sometime around May-June. This would 
> mean (assuming people are happy with this) we need to make a list of what's 
> still outstanding for 2.5. There's a bunch of accepted PEPs that are waiting 
> for code. Once that's done, there will be a final 2.4.3 sometime after or 
> close to the 2.5 final release.
> 
> Anthony
> -- 
> Anthony Baxter <[EMAIL PROTECTED]>
> It's never too late to have a happy childhood.
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/jcarlson%40uci.edu

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

Re: [Python-Dev] Exception Reorg PEP revised yet again

2005-08-12 Thread Brett Cannon 
On 8/12/05, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Brett Cannon <[EMAIL PROTECTED]> writes:
> 
> > On 8/10/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >> > > Then I don't follow what you mean by "moved under os".
> >> >
> >> > In other words, to get the exception, do ``from os import
> >> > WindowsError``.  Unfortunately we don't have a generic win module to
> >> > put it under.  Maybe in the platform module instead?
> >>
> >> -1 on either.  The WindowsError exception needs to in the main exception
> >> tree.  It occurs in too many different modules and applications.  That
> >> is a good reason for being in the main tree.
> >>
> >
> > Where is it used so much?  In the stdlib, grepping for WindowsError
> > recursively in Lib in 2.4 turns up only one module raising it
> > (subprocess) and only two modules with a total of three places of
> > catching it (ntpath once, urllib twice).  In Module, there are no
> > hits.
> >
> 
> I don't know how you've been grepping, but the Python api functions to
> raise WindowsErrors are named like PyErr_SetFromWindowsErr() or so.
> 

Forgot to add that to the grep statement after I discovered that.

> Typically, WindowsErrors are raised when Win32 API functions fail.
> In the core extension modules, I find at least mmapmodule.c,
> posixmodule.c, _subprocess.c, and _winreg.c raising them.  It may be a
> bit hidden, because the docs for _winreg mention only EnvironmentError,
> but they are wrong:
> 
> C:\>py
> Python 2.5a0 (#60, Jul  4 2005, 19:53:27) [MSC v.1310 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import _winreg
> >>> _winreg.OpenKey(_winreg.HKEY_CLASSES_ROOT, "blah")
> Traceback (most recent call last):
>   File "", line 1, in ?
> WindowsError: [Errno 2] Das System kann die angegebene Datei nicht finden
> >>>
> 
> >> If the name bugs you, I would support renaming it to PlatformError or
> >> somesuch.  That would make it free for use with Mac errors and Linux
> >> errors.  Also, it wouldn't tie a language feature to the name of an
> >> MS product.
> >>
> >
> > I can compromise to this if others prefer this alternative.  Anybody
> > else have an opinion?
> 
> Win32 has the FormatError() api to convert error codes into descriptions
> - these descriptions are very useful, as are the error codes when you
> catch errors in client code.
> 
> I would say as long as the Python core contains win32 specific modules
> like _winreg WindowsError should stay.  For the name, I have no
> preference but I see no need to change it.
> 

OK, then it will just stay as-is.

People can expect an updated PEP sometime this weekend.

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

Re: [Python-Dev] plans for 2.4.2 and 2.5a1

2005-08-12 Thread Raymond Hettinger 
[Josiah]
> At this point, I'd be happy to get
> /any/ mechanism, with a preference to struct and/or binascii 

Assign 1023290 to me and I'll get it done in the next month or so.


Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] plans for 2.4.2 and 2.5a1

2005-08-12 Thread Martin v. Löwis 
Anthony Baxter wrote:
> So I'm currently planning for a 2.4.2 sometime around mid September. I figure 
> we cut a release candidate either on the 7th or 14th, and a final a week 
> later. 

I'm returning only on Sep 12 from vacation, so the Windows binaries of a
release candidate would have to wait until that Monday; the 14th would
suit me better. Unfortunately, I'm likely also travelling on 19..23,
so the final release would have to wait until Sep 24 or so.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Hosting svn.python.org

2005-08-12 Thread skip 

martin> Log Message:
martin> Add wush.net hosting.
...
martin> +  * Greg Stein suggested http://www.wush.net/subversion.php. 
...

I will enthusiastically cast my vote for tummy.com, Sean Reifschneider's
company.  Mojam leases a server there (Mojam & Musi-Cal websites running
CentOS 4, Apache+mod_perl, Python, Mason, MySQLdb, Mailman, etc).  Their
service has been absolutely awesome.  Sean is one of the python.org
webmasters to boot, so he knows our culture very well already.

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] new PEP type: Process

2005-08-12 Thread David Goodger 
Barry Warsaw and I, the PEP editors, have been discussing the need for a new PEP
type lately.  Martin von Löwis' PEP 347 was a prime example of a PEP that didn't
fit into the existing Standards Track and Informational categories.  We agreed
upon a new "Process" PEP type.  For more information, please see PEP 1
(http://www.python.org/peps/pep-0001.html) -- the type of which has also been
changed to Process.

Other good examples of Process PEPs are the release schedule PEPs, and I
understand there may be a new one soon.

(Please cc: any PEP-related mail to [EMAIL PROTECTED])

-- 
David Goodger 



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] xml.parsers.expat no userdata in callback functions

2005-08-12 Thread Kristian Benoit 
In the C version of expat, handlers receive a void *userdata, but it is
not the case in the python version.

This means one cant parse multiple files at the same time using the same
handlers. You cant pass the context current context to the handler, you must
base your code on global variables which is not so nice.

Thanks

Please leave the cc in the mail header as I'm not subscribed to the
list.

Kristian

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

[Python-Dev] Extension to dl module to allow passing strings from native function

2005-08-12 Thread Senko Rasic 
Hi all,

recently I've tried to use dl module functionality to interface with
external C function.
(It was a quick hack so I didn't want to write wrapper code). To my
dismay I learned that
call method doesn't allow passing data by reference (since strings are
immutable in
python) - but passing pointers around and modifying caller's data is
used all the time
in C, so that makes dl practically useless.

I've hacked the method to allow mutable data, by allocating temporary
buffers for
all string arguments passed to it, calling the c function, and then
constructing new
strings from the data in those buffers and returning them in a tuple
together with function
return code.

Combined with pack/unpack from struct module, this allows passing any structure
to and from the external C function, so, imho, it's a useful thing to
have. To my knowledge,
this functionality can't be achieved in pure python programs, and
there's no alternative
dynamic loader module that can do it.

More info with examples:
   http://ptlo.blogspot.com/2005/08/pyinvoke.html
Source:
   http://software.senko.net/pub/python-dl2.tgz

(the tarball contains setup.py and my dlmodule.c version, for experimenting
without patching the official module, and patch made against (fairly recent) cvs
version of dlmodule.c)

Thoughts, comments? Could this be put in standard module, does it make
sense, etc?

Regards,
Senko

-- 
Senko Rasic 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] new PEP type: Process

2005-08-12 Thread Aahz 
On Fri, Aug 12, 2005, David Goodger wrote:
>
> Barry Warsaw and I, the PEP editors, have been discussing the
> need for a new PEP type lately.  Martin von L?wis' PEP 347 was
> a prime example of a PEP that didn't fit into the existing
> Standards Track and Informational categories.  We agreed upon a
> new "Process" PEP type.  For more information, please see PEP 1
> (http://www.python.org/peps/pep-0001.html) -- the type of which has
> also been changed to Process.

Go ahead and make PEP 6 a Process PEP.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

The way to build large Python applications is to componentize and
loosely-couple the hell out of everything.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com