Re: [Python-Dev] PEP 385: the eol-type issue

2009-08-07 Thread M.-A. Lemburg
Neil Hodgson wrote:
> M.-A. Lemburg:
> 
>> ... and because of this, the feature is already available if
>> you use codecs.open() instead of the built-in open():
> 
>So should I not add an issue for the basic open because codecs.open
> should be used for this case?

Like Antoine mentioned: Using codecs.open() and .readline()
is about 20-30 times slower than open().

This is mainly due to the fact that the codec's .readline()
method is implemented in pure Python and does its own
buffering.

IMHO, it would be a lot better to add full Unicode support
for line breaks to the io layer. Given that the code for the
complicated handling of the CRLF combination is already there,
it's not difficult to add support for the remaing line break
characters.

The implementation could reuse the Bloom filter approach
used in unicodeobject.c to make this very fast.

BTW: I'm not sure why the io layer records the line endings
it has seen. This makes processing more complicated for no
apparent reason. In the few cases where you might need this
(I don't see any), you could just as well scan the lines
in a quick loop using Python.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 07 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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] Tkinter has many files

2009-08-07 Thread Michael Foord

Terry Reedy wrote:

cool-RR wrote:

Hello python-dev!

I'm a Python programmer, but this is the first time I'm posting on 
python-dev, and I am not familiar at all with how the Python 
implementation works -- so this post may be way off.


I've recently released a Python application, PythonTurtle 
, which is packaged using py2exe and 
InnoSetup. Due to the fact that my program needs to give the user a 
full Python shell, I've made py2exe package the entire Python 
standard library with my application.


I really think you you just make you app sit on top of a standard 
Python installation. The current Windows installers work well. Just 
decide which versions you are willing to support. The usually reasons 
for bundling, to control the versions of multiple 3rd-party libraries, 
do not seen to apply.


Actually on Windows a very common reason for bundling with py2exe is to 
not be dependent (or require) an installed version of Python. For a 
standalone teaching tool this seems reasonable.


Michael



___
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/fuzzyman%40voidspace.org.uk 




--
http://www.ironpythoninaction.com/

___
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] (try-except) conditional expression similar to (if-else) conditional (PEP 308)

2009-08-07 Thread Jeff McAninch

Should be legal, right?, since syntax would be
   except  if 

Dino Viehland wrote:

On option 1 is this legal then?

x = float(string) except float('nan') if some_check() else float('inf') if 
ValueError

  
Thinking more about the syntax options: if P.J.'s "if" Option is used, 
it should also be optional.

That is, I would want this to also be legal,
  except 
to trap any exception when robustness is more important than catching a 
specific exception.


What would be the typical next step in trying to put this forward?  A 
draft PEP?


--
==
Jeffrey E. McAninch, PhD
Physicist, X-2-IFD
Los Alamos National Laboratory
Phone: 505-667-0374
Email: mcani...@lanl.gov
==

___
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] (try-except) conditional expression similar to (if-else) conditional (PEP 308)

2009-08-07 Thread Kristján Valur Jónsson
Unless I am very much mistaken, this is the approach Ruby takes.
Everything is an expression.  For example, the value of a block is the value of
The last expression in the block.

I've never understood the need to have a distinction betwen statements and 
expressions, not when expressions can have side effects.  It's like that 
differentce between procedures and functions in pascal that only serves to 
confuse

K
> -Original Message-
> From: python-dev-bounces+kristjan=ccpgames@python.org
> [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf
> Of Xavier Morel
> Sent: 6. ágúst 2009 10:25
> To: python-dev@python.org
> Subject: Re: [Python-Dev] (try-except) conditional expression similar
> to (if-else) conditional (PEP 308)


> Wouldn't it be smarter to fix the issue once and for all by looking
> into making Python's compound statements (or even all statements
> without restrictions) expressions that can return values in the first
> place? Now I don't know if it's actually possible, but if it is the
> problem becomes solved not just for try:except: (and twice so for
> if:else:) but also for while:, for: (though that one's already served
> pretty well by comprehensions) and with:.
> 

___
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] (try-except) conditional expression similar to (if-else) conditional (PEP 308)

2009-08-07 Thread MRAB

Jeff McAninch wrote:

Should be legal, right?, since syntax would be
   except  if 

Dino Viehland wrote:

On option 1 is this legal then?

x = float(string) except float('nan') if some_check() else 
float('inf') if ValueError


  
Thinking more about the syntax options: if P.J.'s "if" Option is used, 
it should also be optional.

That is, I would want this to also be legal,
  except 
to trap any exception when robustness is more important than catching a 
specific exception.


Catch all exceptions:

 except 

Catch specific exceptions, optionally catching all others:

 except ( if )+ [else ]

Of course, a catch-all is a bare except, with all its dangers!



What would be the typical next step in trying to put this forward?  A 
draft PEP?



___
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] (try-except) conditional expression similar to (if-else) conditional (PEP 308)

2009-08-07 Thread ilya
I believe people now discuss this both on python-dev and python-ideas,
though since I'm new to both lists, I can't really tell where this
belongs.

I played a little with this syntax, my try_ function and @catch
decorator (which are at http://mit.edu/~unknot/www/try_cond.py):

#   x = float(string) except float('nan') if ValueError
x = try_(float, string, except_ = float('nan'), if_ = ValueError)

@catch(ValueError = float('nan'))
def x1(): return float(string)

#   y = float(string) except ValueError: float('nan')
y = try_(float, string, { ValueError: float('nan') })

@catch({ValueError: float('nan')})
def y1(): return float(string)

#   try:
#   z = open(string, 'r')
#   except IOError as e:
#   if e.errno == 2:
#   z = 'not_exist'
#   else:
#   raise
#
z = try_(open, string, 'r', iocatcher({2: 'no file!'}))

@catch(iocatcher({2: 'nothing!'}))
def z1(): return open(string, 'r')

Here are my overall feelings:

(1) it would be interesting to come up with syntax for except/if
clause, but it's not obvious how to make one and this fact itself may
kill the idea.
(2) the more reasonable approach to things like this is by defining a
separate block and then performing a "catch" operation with it.
Unfortunately, this looks very clumsy as currently this can only be
done by defining a separate function. I think code blocks are a good
direction to explore.

2009/8/7 Kristján Valur Jónsson :
> Unless I am very much mistaken, this is the approach Ruby takes.
> Everything is an expression.  For example, the value of a block is the value 
> of
> The last expression in the block.
>
> I've never understood the need to have a distinction betwen statements and 
> expressions, not when expressions can have side effects.  It's like that 
> differentce between procedures and functions in pascal that only serves to 
> confuse
>
> K
>> -Original Message-
>> From: python-dev-bounces+kristjan=ccpgames@python.org
>> [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf
>> Of Xavier Morel
>> Sent: 6. ágúst 2009 10:25
>> To: python-dev@python.org
>> Subject: Re: [Python-Dev] (try-except) conditional expression similar
>> to (if-else) conditional (PEP 308)
>
>
>> Wouldn't it be smarter to fix the issue once and for all by looking
>> into making Python's compound statements (or even all statements
>> without restrictions) expressions that can return values in the first
>> place? Now I don't know if it's actually possible, but if it is the
>> problem becomes solved not just for try:except: (and twice so for
>> if:else:) but also for while:, for: (though that one's already served
>> pretty well by comprehensions) and with:.
>>
>
> ___
> 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/ilya.nikokoshev%40gmail.com
>
___
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] (try-except) conditional expression similar to (if-else) conditional (PEP 308)

2009-08-07 Thread Michael Foord




--
http://www.ironpythoninaction.com

On 7 Aug 2009, at 12:06, ilya  wrote:


I believe people now discuss this both on python-dev and python-ideas,
though since I'm new to both lists, I can't really tell where this
belongs.



It definitely belongs on the ideas list...

Michael





I played a little with this syntax, my try_ function and @catch
decorator (which are at http://mit.edu/~unknot/www/try_cond.py):

   #   x = float(string) except float('nan') if ValueError
   x = try_(float, string, except_ = float('nan'), if_ = ValueError)

   @catch(ValueError = float('nan'))
   def x1(): return float(string)

   #   y = float(string) except ValueError: float('nan')
   y = try_(float, string, { ValueError: float('nan') })

   @catch({ValueError: float('nan')})
   def y1(): return float(string)

   #   try:
   #   z = open(string, 'r')
   #   except IOError as e:
   #   if e.errno == 2:
   #   z = 'not_exist'
   #   else:
   #   raise
   #
   z = try_(open, string, 'r', iocatcher({2: 'no file!'}))

   @catch(iocatcher({2: 'nothing!'}))
   def z1(): return open(string, 'r')

Here are my overall feelings:

(1) it would be interesting to come up with syntax for except/if
clause, but it's not obvious how to make one and this fact itself may
kill the idea.
(2) the more reasonable approach to things like this is by defining a
separate block and then performing a "catch" operation with it.
Unfortunately, this looks very clumsy as currently this can only be
done by defining a separate function. I think code blocks are a good
direction to explore.

2009/8/7 Kristján Valur Jónsson :

Unless I am very much mistaken, this is the approach Ruby takes.
Everything is an expression.  For example, the value of a block is  
the value of

The last expression in the block.

I've never understood the need to have a distinction betwen  
statements and expressions, not when expressions can have side  
effects.  It's like that differentce between procedures and  
functions in pascal that only serves to confuse


K

-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On  
Behalf

Of Xavier Morel
Sent: 6. ágúst 2009 10:25
To: python-dev@python.org
Subject: Re: [Python-Dev] (try-except) conditional expression  
similar

to (if-else) conditional (PEP 308)




Wouldn't it be smarter to fix the issue once and for all by looking
into making Python's compound statements (or even all statements
without restrictions) expressions that can return values in the  
first

place? Now I don't know if it's actually possible, but if it is the
problem becomes solved not just for try:except: (and twice so for
if:else:) but also for while:, for: (though that one's already  
served

pretty well by comprehensions) and with:.



___
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/ilya.nikokoshev%40gmail.com


___
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/fuzzyman%40voidspace.org.uk

___
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] PEP 385: the eol-type issue

2009-08-07 Thread Antoine Pitrou
M.-A. Lemburg  egenix.com> writes:
> 
> IMHO, it would be a lot better to add full Unicode support
> for line breaks to the io layer. Given that the code for the
> complicated handling of the CRLF combination is already there,
> it's not difficult to add support for the remaing line break
> characters.

I'm not against anything in principle here, but I'd just like to point out two
things:

1. Changing line break semantics would break compatibility with the current
behaviour, and it would also diverge from what the `newline` parameter
specifies; this may be annoying if, for example, the TextIOWrapper class is used
to parse some network protocols with a rigorous line ending definition

2. It would be useful to have some input by the original designers of the IO
library (the PEP lists Guido, Daniel Stutzbach and Mike Verdone, but I suppose
other people were involved)

Regards

Antoine.


___
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] PEP 385: the eol-type issue

2009-08-07 Thread M.-A. Lemburg
Antoine Pitrou wrote:
> M.-A. Lemburg  egenix.com> writes:
>>
>> IMHO, it would be a lot better to add full Unicode support
>> for line breaks to the io layer. Given that the code for the
>> complicated handling of the CRLF combination is already there,
>> it's not difficult to add support for the remaining line break
>> characters.
> 
> I'm not against anything in principle here, but I'd just like to point out two
> things:
> 
> 1. Changing line break semantics would break compatibility with the current
> behaviour, and it would also diverge from what the `newline` parameter
> specifies; this may be annoying if, for example, the TextIOWrapper class is 
> used
> to parse some network protocols with a rigorous line ending definition

Sure, but that would still be possible using the newline parameter.
We'd only have to find a way to tell the io layer "accept all Unicode
line break characters".

> 2. It would be useful to have some input by the original designers of the IO
> library (the PEP lists Guido, Daniel Stutzbach and Mike Verdone, but I suppose
> other people were involved)

Fair enough.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 07 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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] (try-except) conditional expression similar to (if-else) conditional (PEP 308)

2009-08-07 Thread Alex Martelli
2009/8/7 Kristján Valur Jónsson :
> Unless I am very much mistaken, this is the approach Ruby takes.
> Everything is an expression.  For example, the value of a block is the value 
> of
> The last expression in the block.
>
> I've never understood the need to have a distinction betwen statements and 
> expressions, not when expressions can have side effects.  It's like that 
> differentce between procedures and functions in pascal that only serves to 
> confuse

If you're interested in understanding it better, research
Query-Command Separation (QCS), e.g. starting at
http://en.wikipedia.org/wiki/Command-query_separation and links
therefrom.


Alex
___
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] Summary of Python tracker Issues

2009-08-07 Thread Python tracker

ACTIVITY SUMMARY (07/31/09 - 08/07/09)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2315 open (+39) / 16175 closed (+16) / 18490 total (+55)

Open issues with patches:   919

Average duration of open issues: 657 days.
Median duration of open issues: 411 days.

Open Issues Breakdown
   open  2283 (+39)
pending31 ( +0)

Issues Created Or Reopened (55)
___

heapq.nsmallest and nlargest should be smarter/more usable/more  07/31/09
CLOSED http://bugs.python.org/issue6614created  jab 
  
   

multiprocessing logging support test 08/01/09
   http://bugs.python.org/issue6615created  OG7 
  
   

PyList_APPEND (append without incref)08/01/09
CLOSED http://bugs.python.org/issue6616created  ideasman42  
  
   patch   

During compiling python 3.1 getting error Undefined symbol libin 08/01/09
   http://bugs.python.org/issue6617created  thoratsandip
  
   

Typo in a listing in 5.2.9 of language reference 08/01/09
CLOSED http://bugs.python.org/issue6618created  gregorlingl 
  
   

Remove duplicated function in Lib/inspect.py 08/01/09
CLOSED http://bugs.python.org/issue6619created  vincele 
  
   patch   

Variable may be used before first being assigned to in Lib/local 08/01/09
CLOSED http://bugs.python.org/issue6620created  vincele 
  
   patch   

[RFC] Remove leftover use of Carbon module from Lib/binhex.py08/01/09
CLOSED http://bugs.python.org/issue6621created  vincele 
  
   patch   

[RFC] wrong variable used in Lib/poplib.py   08/01/09
CLOSED http://bugs.python.org/issue6622created  vincele 
  
   patch   

Lib/ftplib.py netrc class parsing problem08/01/09
   http://bugs.python.org/issue6623created  vincele 
  
   patch   

PyArg_ParseTuple with "s" format and NUL: Bogus TypeError detail 08/01/09
CLOSED http://bugs.python.org/issue6624created  jafo
  
   

UnicodeEncodeError on pydoc's CLI08/02/09
   http://bugs.python.org/issue6625created  christoph   
  
   patch   

show Python mimetypes module some love   08/02/09
   http://bugs.python.org/issue6626created  jrus
  
   patch   

threading.local() does not work with C-created threads   08/02/09
   http://bugs.python.org/issue6627created  Nikratio
  
   

IDLE freezes after encountering a syntax error   08/02/09
   http://bugs.python.org/issue6628created  brian89 
  
   

seek doesn't properly handle file buffer, leads to silent data c 08/03/09
CLOSED http://bugs.python.org/issue6629created  lorentey
  
   patch   

string.Template custom pattern not working   08/03/09
   http://bugs.python.org/issue6630created  jcollado
  
   

urlparse.urlunsplit() can't handle relative files (for urllib*.o 08/03/09
   http://bugs.python.org/issue6631created  albert  
  
   

Include more fullwidth chars in the decimal codec08/03/09
   http://bugs.python.org/issue6632created  ezio.melotti
  
 

[Python-Dev] socket.makefile and EINTR handling

2009-08-07 Thread Gregory P. Smith
In particular this issue:  http://bugs.python.org/issue1628205

I believe we should handle EINTR internally within the
socket._fileobject wrapper as nobody using a file-like object should
ever expect to get an EINTR.  EINTR only comes from using the lowest
level system calls.

Anyone strongly disagree?

-gps
___
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] www, svn.python.org down

2009-08-07 Thread A.M. Kuchling
Both www.python.org and svn.python.org are down.  They're hosted on
the same machine, and it seems to have run into disk problems and
hasn't rebooted even after power-cycling.  Thomas Wouters will be
visiting the machine physically tomorrow to try to diagnose the
problem.

(The machine also hosts planet.python.org and hg.python.org.)

--amk
___
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] (try-except) conditional expression similar to (if-else) conditional (PEP 308)

2009-08-07 Thread Steven D'Aprano
On Fri, 7 Aug 2009 08:22:14 pm Kristján Valur Jónsson wrote:
> Unless I am very much mistaken, this is the approach Ruby takes.
> Everything is an expression.  For example, the value of a block is
> the value of The last expression in the block.

Copying what other languages do is not necessarily a bad thing, but that 
would fail both "explicit is better than implicit" and "in the face of 
ambiguity, avoid the temptation to guess".

It's not immediately obvious to me why the last expression should be 
given that privileged rule. Why not the first expression?



> I've never understood the need to have a distinction betwen
> statements and expressions, not when expressions can have side
> effects.  It's like that differentce between procedures and functions
> in pascal that only serves to confuse

Its been a while, but I don't think it ever confused me. Being unable to 
return multiple values, *that* confused me, but the distinction 
between "procedures are for doing something, functions are for getting 
something back" was perfectly straight-forward.

(And then Pascal went and made it slightly more confusing by adding var 
parameters, so you could get results back from a procedure and have 
side-effects in a function... oh well.)



-- 
Steven D'Aprano
___
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