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

[Stephen J. Turnbull]

"Martin v. Löwis" writes:
 > > This is simply false AFAICS.  There was little participation on this
 > > particular issue during PEP 374 that I can recall.  Now that it is
 > > clearly an issue after all, it's still early in the PEP 385 process.
 > > Martin has already picked up the ball on EOL support, and has carried
 > > informal design pretty much to the goal line already ... all that's
 > > left is the detailed design and the implementation, and there are
 > > several people involved who will help develop the patch, all very
 > > capable. 
 > 
 > I'm not so optimistic. To me, it looks like that either Dirkjan or Mark
 > will implement a hg hook, or else it won't happen (for me, I certainly
 > know that I will not write Mercurial hooks anytime soon).

Ouch.  Still, I think the informal discussion so far is pretty close
to a usable solution at that level.
___
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

[M.-A. Lemburg]

Neil Hodgson wrote:
> Glenn Linderman:
> 
>> and perhaps other things (and
>> are there new Unicode control characters that could be used for line
>> endings?),
> 
>Unicode includes Line Separator U+2028 and Paragraph Separator
> U+2029 but they are rarely supported and very rarely used. They are a
> pain to work with since they are 3 byte sequences in UTF-8. Visual
> Studio does support them.
> 
>Python does not currently support these line separators such as in
> this example which only reads 2 lines rather than 3:
> 
> with open("x.txt", "wb") as f:
>   f.write("a\nb\u2029c\n".encode('utf-8'))
> with open("x.txt", "r") as f:
>   n = 1
>   for l in f.readlines():
>   print(n, repr(l))
>   n += 1

Please file a bug report for this. f.readlines() (or rather
the io layer) should be using Py_UNICODE_ISLINEBREAK(ch)
for detecting line break characters.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 06 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] PEP 385: the eol-type issue

[Antoine Pitrou]

M.-A. Lemburg  egenix.com> writes:
> 
> Please file a bug report for this. f.readlines() (or rather
> the io layer) should be using Py_UNICODE_ISLINEBREAK(ch)
> for detecting line break characters.

Actually, no. It has been designed from the start to only recognize the
"standard" line break representations found in common formats/protocols (CR, LF
and CR+LF).
People wanting to split on arbitrary unicode line breaks should use
str.splitlines().

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

[Nick Coghlan]

Antoine Pitrou wrote:
> M.-A. Lemburg  egenix.com> writes:
>> Please file a bug report for this. f.readlines() (or rather
>> the io layer) should be using Py_UNICODE_ISLINEBREAK(ch)
>> for detecting line break characters.
> 
> Actually, no. It has been designed from the start to only recognize the
> "standard" line break representations found in common formats/protocols (CR, 
> LF
> and CR+LF).
> People wanting to split on arbitrary unicode line breaks should use
> str.splitlines().

The fairly long-standing RFE relating to an arbitrarily selectable
newline separator seems relevant here:
http://bugs.python.org/issue1152248

As with the discussion there, the problem with using str.splitlines is
that it prevents pipelining approaches that avoid reading a whole file
into memory.

While removing the validity check from readlines() completely is
questionable (the readrecords() approach mentioned in the tracker issue
would still be better there), loosening the validity check to be based
on Py_UNICODE_IS_LINEBREAK seems a bit more feasible. (I'd still call it
a feature requests rather than a bug though).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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

[M.-A. Lemburg]

Nick Coghlan wrote:
> Antoine Pitrou wrote:
>> M.-A. Lemburg  egenix.com> writes:
>>> Please file a bug report for this. f.readlines() (or rather
>>> the io layer) should be using Py_UNICODE_ISLINEBREAK(ch)
>>> for detecting line break characters.
>>
>> Actually, no. It has been designed from the start to only recognize the
>> "standard" line break representations found in common formats/protocols (CR, 
>> LF
>> and CR+LF).
>> People wanting to split on arbitrary unicode line breaks should use
>> str.splitlines().
> 
> The fairly long-standing RFE relating to an arbitrarily selectable
> newline separator seems relevant here:
> http://bugs.python.org/issue1152248
> 
> As with the discussion there, the problem with using str.splitlines is
> that it prevents pipelining approaches that avoid reading a whole file
> into memory.
> 
> While removing the validity check from readlines() completely is
> questionable (the readrecords() approach mentioned in the tracker issue
> would still be better there), loosening the validity check to be based
> on Py_UNICODE_IS_LINEBREAK seems a bit more feasible. (I'd still call it
> a feature requests rather than a bug though).

I've had a look at the io implementation: this appears to be
based on the universal newline support idea which addresses
only a fixed set of "new line" character combinations and is
not as straight forward to extend to support all Unicode
line break characters as I thought.

What I don't understand is why the io layer tries to reinvent
the wheel here instead of just using the codec's .readline()
method - which *does* use .splitlines() and has full support
for all Unicode line break characters (including the CRLF
combination).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 06 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] PEP 385: the eol-type issue

[M.-A. Lemburg]

M.-A. Lemburg wrote:
> Nick Coghlan wrote:
>> Antoine Pitrou wrote:
>>> M.-A. Lemburg  egenix.com> writes:
 Please file a bug report for this. f.readlines() (or rather
 the io layer) should be using Py_UNICODE_ISLINEBREAK(ch)
 for detecting line break characters.
>>>
>>> Actually, no. It has been designed from the start to only recognize the
>>> "standard" line break representations found in common formats/protocols 
>>> (CR, LF
>>> and CR+LF).
>>> People wanting to split on arbitrary unicode line breaks should use
>>> str.splitlines().
>>
>> The fairly long-standing RFE relating to an arbitrarily selectable
>> newline separator seems relevant here:
>> http://bugs.python.org/issue1152248
>>
>> As with the discussion there, the problem with using str.splitlines is
>> that it prevents pipelining approaches that avoid reading a whole file
>> into memory.
>>
>> While removing the validity check from readlines() completely is
>> questionable (the readrecords() approach mentioned in the tracker issue
>> would still be better there), loosening the validity check to be based
>> on Py_UNICODE_IS_LINEBREAK seems a bit more feasible. (I'd still call it
>> a feature requests rather than a bug though).
> 
> I've had a look at the io implementation: this appears to be
> based on the universal newline support idea which addresses
> only a fixed set of "new line" character combinations and is
> not as straight forward to extend to support all Unicode
> line break characters as I thought.
> 
> What I don't understand is why the io layer tries to reinvent
> the wheel here instead of just using the codec's .readline()
> method - which *does* use .splitlines() and has full support
> for all Unicode line break characters (including the CRLF
> combination).

... and because of this, the feature is already available if
you use codecs.open() instead of the built-in open():

import codecs

with codecs.open("x.txt", "w", encoding='utf-8') as f:
  f.write("a\nb\u2029c\n")

with codecs.open("x.txt", "r", encoding='utf-8') as f:
  n = 1
  for l in f.readlines():
 print(n, repr(l))
 n += 1

This prints:

1 'a\n'
2 'b\u2029'
3 'c\n'

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 06 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)

[Nick Coghlan]

P.J. Eby wrote:
> At 05:59 PM 8/5/2009 -0700, Raymond Hettinger wrote:
>> [Jeffrey E. McAninch, PhD]
>>> I very often want something like a try-except conditional expression
>>> similar
>>> to the if-else conditional.
>>>
>>> An example of the proposed syntax might be:
>>>x = float(string) except float('nan')
>>> or possibly
>>>x = float(string) except ValueError float('nan')
>>
>> +1 I've long wanted something like this.
>> One possible spelling is:
>>
>>   x = float(string) except ValueError else float('nan')
> 
> I think 'as' would be better than 'else', since 'else' has a different
> meaning in try/except statements, e.g.:
> 
>x = float(string) except ValueError, TypeError as float('nan')
> 
> Of course, this is a different meaning of 'as', too, but it's not "as"
> contradictory, IMO...  ;-)

(We're probably well into python-ideas territory at this point, but I'll
keep things where the thread started for now)

The basic idea appears sound to me as well. I suspect finding an
acceptable syntax is going to be the sticking point.

Breaking the problem down, we have three things we want to separate:

1. The expression that may raise the exception
2. The expression defining the exceptions to be caught
3. The expression to be used if the exception actually is caught

>From there it is possible to come up with all sorts of variants.

Option 1:

Change the relative order of the clauses by putting the exception
definition last:

  x = float(string) except float('nan') if ValueError
  op(float(string) except float('nan') if ValueError)

I actually like this one (that's why I listed it first). It gets the
clauses out of order relative to the statement, but the meaning still
seems pretty obvious to me.

Option 2:

Follow the lamba model and allow a colon inside this form of expression:

  x = float(string) except ValueError: float('nan')
  op(float(string) except ValueError: float('nan'))

This has the virtue of closely matching the statement syntax, but
embedding colons inside expressions is somewhat ugly. Yes, lambda
already does it, but lambda can hardly be put forward as a paragon of
beauty.

Option 3a/3b:

Raymond's except-else suggestion:

  x = float(string) except ValueError else float('nan')
  op(float(string) except ValueError else float('nan'))

This has the problem of inverting the sense of the else clause relative
to the statement form (where the else clause is executed only if no
exception occurs)

A couple of extra keywords would get the sense correct again, but I'm
not sure the parser could cope with it and it is rather verbose (I much
prefer option 1 to this idea):

  x = float(string) if not except ValueError else float('nan')
  op(float(string) if not except ValueError else float('nan'))

Option 4:

PJE's except-as suggestion:

  x = float(string) except ValueError as float('nan')
  op(float(string) except ValueError as float('nan'))

Given that we now use "except ValueError as ex" in exception statements,
the above strikes me a really confusing idea.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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

[Antoine Pitrou]

M.-A. Lemburg  egenix.com> writes:
> 
> What I don't understand is why the io layer tries to reinvent
> the wheel here instead of just using the codec's .readline()
> method - which *does* use .splitlines() and has full support
> for all Unicode line break characters (including the CRLF
> combination).

As for the original Python implementation, the goal was probably to start from a
clean sheet. Besides, the new API has seek() and tell() as well. But I'm not
really qualified to say more -- I didn't participate in its design.

As for the C implementation, it had to be written from scratch anyway --
codecs.open() is pure Python and too slow. Deferring to str.splitlines() would
still have been possible but a bit wasteful since in C you can use buffers
directly.

(and, besides, when writing the C implementation we were concerned with exact
compatibility with the Python version -- including line break semantics)

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

[Dj Gilcrease]

On Thu, Aug 6, 2009 at 4:47 AM, Nick Coghlan wrote:
> Option 2:
>  x = float(string) except ValueError: float('nan')
>  op(float(string) except ValueError: float('nan'))
>
> This has the virtue of closely matching the statement syntax, but
> embedding colons inside expressions is somewhat ugly. Yes, lambda
> already does it, but lambda can hardly be put forward as a paragon of
> beauty.

+1 on this option as it resembles the standard try/except block enough
it would be a quick edit to convert it to one if later you realize you
need to catch more exceptions*

* I recommend NOT allowing multiple exceptions in this form eg
x = float(string)/var except ValueError, ZeroDivisionError, ...: float('nan')

as it will start to reduce readability quickly
___
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 si milar to (if-else) conditional (PEP 308)

[Antoine Pitrou]

Raymond Hettinger  rcn.com> writes:
> 
> For example:
> 
>x = min(seq) except ValueError else 0 # default to zero for empty
sequences

How about:
x = min(seq) if seq else 0

Shorter and more readable ("except X else Y" isn't very logical).

>   sample_std_deviation = sqrt(sum(x - mu for x in seq) / (len(seq)-1)) except
ZeroDivisionError else float('Inf')

Same transformation here.

I have to say that the original example:
x = float(string) except ValueError else float('nan')

looks artificial. I don't see how it's adequate behaviour to return a NaN when
presented with a string which doesn't represent a float number.

Besides, all this is python-ideas material (and has probably already been
proposed before).

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

[M.-A. Lemburg]

Antoine Pitrou wrote:
> M.-A. Lemburg  egenix.com> writes:
>>
>> What I don't understand is why the io layer tries to reinvent
>> the wheel here instead of just using the codec's .readline()
>> method - which *does* use .splitlines() and has full support
>> for all Unicode line break characters (including the CRLF
>> combination).
> 
> As for the original Python implementation, the goal was probably to start 
> from a
> clean sheet. Besides, the new API has seek() and tell() as well. But I'm not
> really qualified to say more -- I didn't participate in its design.
> 
> As for the C implementation, it had to be written from scratch anyway --
> codecs.open() is pure Python and too slow. Deferring to str.splitlines() would
> still have been possible but a bit wasteful since in C you can use buffers
> directly.

Sure, but the code for line splitting is not really all that
complicated (see PyUnicode_Splitlines()), so could easily
be adapted to work on buffers directly.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 06 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)

[Xavier Morel]

On 6 Aug 2009, at 00:22 , Jeff McAninch wrote:
I'm new to this list, so please excuse me if this topic has been  
discussed, but I didn't

see anything similar in the archives.

I very often want something like a try-except conditional expression  
similar

to the if-else conditional.
I fear this idea is soon going to extend to all compound statements  
one by one.


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)

[MRAB]

Nick Coghlan wrote:

P.J. Eby wrote:

At 05:59 PM 8/5/2009 -0700, Raymond Hettinger wrote:

[Jeffrey E. McAninch, PhD]

I very often want something like a try-except conditional expression
similar
to the if-else conditional.

An example of the proposed syntax might be:
   x = float(string) except float('nan')
or possibly
   x = float(string) except ValueError float('nan')

+1 I've long wanted something like this.
One possible spelling is:

  x = float(string) except ValueError else float('nan')

I think 'as' would be better than 'else', since 'else' has a different
meaning in try/except statements, e.g.:

   x = float(string) except ValueError, TypeError as float('nan')

Of course, this is a different meaning of 'as', too, but it's not "as"
contradictory, IMO...  ;-)


(We're probably well into python-ideas territory at this point, but I'll
keep things where the thread started for now)

The basic idea appears sound to me as well. I suspect finding an
acceptable syntax is going to be the sticking point.

Breaking the problem down, we have three things we want to separate:

1. The expression that may raise the exception
2. The expression defining the exceptions to be caught
3. The expression to be used if the exception actually is caught


From there it is possible to come up with all sorts of variants.


Option 1:

Change the relative order of the clauses by putting the exception
definition last:

  x = float(string) except float('nan') if ValueError
  op(float(string) except float('nan') if ValueError)

I actually like this one (that's why I listed it first). It gets the
clauses out of order relative to the statement, but the meaning still
seems pretty obvious to me.


A further extension (if we need it):

result = foo(arg) except float('inf') if ZeroDivisionError else 
float('nan')


The 'else' part handles any other exceptions (not necessarily a good idea!).

or:

result = foo(arg) except float('inf') if ZeroDivisionError else 
float('nan') if ValueError


Handles a number of different exceptions.


Option 2:

Follow the lamba model and allow a colon inside this form of expression:

  x = float(string) except ValueError: float('nan')
  op(float(string) except ValueError: float('nan'))

This has the virtue of closely matching the statement syntax, but
embedding colons inside expressions is somewhat ugly. Yes, lambda
already does it, but lambda can hardly be put forward as a paragon of
beauty.


A colon is also used in a dict literal.


Option 3a/3b:

Raymond's except-else suggestion:

  x = float(string) except ValueError else float('nan')
  op(float(string) except ValueError else float('nan'))


[snip]
-1
___
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

[Antoine Pitrou]

M.-A. Lemburg  egenix.com> writes:
> 
> Sure, but the code for line splitting is not really all that
> complicated (see PyUnicode_Splitlines()), so could easily
> be adapted to work on buffers directly.

Certainly indeed. It all comes down to compatibility with the original
implementation.
(PEP 3116 itself is vague on the subject, but it didn't come to me to question
the validity of the Python implementation, I admit)

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

[Python-Dev] (try-except) conditional expression similar to (if-else) conditional (PEP 308)

[ilya]

I took a look at the options 1 and 2:

x = float(string) except float('nan') if ValueError
y = float(string) except ValueError: float('nan')

and I think this can be done just as easily with existing syntax:

x = try_1(float, string, except_ = float('nan'), if_ = ValueError)
y = try_2(float, string, { ValueError: float('nan') })

Here's the full example:

- example starts -

def try_1(func, *args, except_ = None, if_ = None):
try:
return func(*args)
except if_ as e:
return except_

def try_2(func, *args):
'The last argument is a dictionary {exception type: return value}.'
dic = args[-1]
try:
return func(*args[:-1])
except Exception as e:
for k,v in dic.items():
if isinstance(e, k):
return v
raise

for string in ['5', 'five']:
#   x = float(string) except float('nan') if ValueError
x = try_1(float, string, except_ = float('nan'), if_ = ValueError)
#   y = float(string) except ValueError: float('nan')
y = try_2(float, string, { ValueError: float('nan') })
print(x, y)

- example ends -

As a side note, if I just subscribed to python-dev, is it possible to
quote an old email? Below is my manual cut-and-paste quote:

-- my quote --

Nick Coghlan wrote:
> P.J. Eby wrote:
>> At 05:59 PM 8/5/2009 -0700, Raymond Hettinger wrote:
>>> [Jeffrey E. McAninch, PhD]
 I very often want something like a try-except conditional expression
 similar
 to the if-else conditional.

 An example of the proposed syntax might be:
x = float(string) except float('nan')
 or possibly
x = float(string) except ValueError float('nan')
>>> +1 I've long wanted something like this.
>>> One possible spelling is:
>>>
>>>   x = float(string) except ValueError else float('nan')
>> I think 'as' would be better than 'else', since 'else' has a different
>> meaning in try/except statements, e.g.:
>>
>>x = float(string) except ValueError, TypeError as float('nan')
>>
>> Of course, this is a different meaning of 'as', too, but it's not "as"
>> contradictory, IMO...  ;-)
>
> (We're probably well into python-ideas territory at this point, but I'll
> keep things where the thread started for now)
>
> The basic idea appears sound to me as well. I suspect finding an
> acceptable syntax is going to be the sticking point.
>
> Breaking the problem down, we have three things we want to separate:
>
> 1. The expression that may raise the exception
> 2. The expression defining the exceptions to be caught
> 3. The expression to be used if the exception actually is caught
>
>>From there it is possible to come up with all sorts of variants.
>
> Option 1:
>
> Change the relative order of the clauses by putting the exception
> definition last:
>
>   x = float(string) except float('nan') if ValueError
>   op(float(string) except float('nan') if ValueError)
>
> I actually like this one (that's why I listed it first). It gets the
> clauses out of order relative to the statement, but the meaning still
> seems pretty obvious to me.
>
A further extension (if we need it):

 result = foo(arg) except float('inf') if ZeroDivisionError else
float('nan')

The 'else' part handles any other exceptions (not necessarily a good idea!).

or:

 result = foo(arg) except float('inf') if ZeroDivisionError else
float('nan') if ValueError

Handles a number of different exceptions.

> Option 2:
>
> Follow the lamba model and allow a colon inside this form of expression:
>
>   x = float(string) except ValueError: float('nan')
>   op(float(string) except ValueError: float('nan'))
>
> This has the virtue of closely matching the statement syntax, but
> embedding colons inside expressions is somewhat ugly. Yes, lambda
> already does it, but lambda can hardly be put forward as a paragon of
> beauty.
>
A colon is also used in a dict literal.

> Option 3a/3b:
>
> Raymond's except-else suggestion:
>
>   x = float(string) except ValueError else float('nan')
>   op(float(string) except ValueError else float('nan'))
>
[snip]
-1
___
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)

[Eric Pruitt]

What about catching specific error numbers? Maybe an option so that
the dictionary elements can also be dictionaries with integers as the
keys:

filedata = try_3(open, randomfile, except = { IOError,  {2: None} } )

If it isn't found in the dictionary, then we raise the error.

On Thu, Aug 6, 2009 at 07:03, ilya wrote:
> I took a look at the options 1 and 2:
>
>    x = float(string) except float('nan') if ValueError
>    y = float(string) except ValueError: float('nan')
>
> and I think this can be done just as easily with existing syntax:
>
>    x = try_1(float, string, except_ = float('nan'), if_ = ValueError)
>    y = try_2(float, string, { ValueError: float('nan') })
>
> Here's the full example:
>
> - example starts -
>
> def try_1(func, *args, except_ = None, if_ = None):
>    try:
>        return func(*args)
>    except if_ as e:
>        return except_
>
> def try_2(func, *args):
>    'The last argument is a dictionary {exception type: return value}.'
>    dic = args[-1]
>    try:
>        return func(*args[:-1])
>    except Exception as e:
>        for k,v in dic.items():
>            if isinstance(e, k):
>                return v
>        raise
>
> for string in ['5', 'five']:
>    #   x = float(string) except float('nan') if ValueError
>    x = try_1(float, string, except_ = float('nan'), if_ = ValueError)
>    #   y = float(string) except ValueError: float('nan')
>    y = try_2(float, string, { ValueError: float('nan') })
>    print(x, y)
>
> - example ends -
>
> As a side note, if I just subscribed to python-dev, is it possible to
> quote an old email? Below is my manual cut-and-paste quote:
>
> -- my quote --
>
> Nick Coghlan wrote:
>> P.J. Eby wrote:
>>> At 05:59 PM 8/5/2009 -0700, Raymond Hettinger wrote:
 [Jeffrey E. McAninch, PhD]
> I very often want something like a try-except conditional expression
> similar
> to the if-else conditional.
>
> An example of the proposed syntax might be:
>    x = float(string) except float('nan')
> or possibly
>    x = float(string) except ValueError float('nan')
 +1 I've long wanted something like this.
 One possible spelling is:

   x = float(string) except ValueError else float('nan')
>>> I think 'as' would be better than 'else', since 'else' has a different
>>> meaning in try/except statements, e.g.:
>>>
>>>    x = float(string) except ValueError, TypeError as float('nan')
>>>
>>> Of course, this is a different meaning of 'as', too, but it's not "as"
>>> contradictory, IMO...  ;-)
>>
>> (We're probably well into python-ideas territory at this point, but I'll
>> keep things where the thread started for now)
>>
>> The basic idea appears sound to me as well. I suspect finding an
>> acceptable syntax is going to be the sticking point.
>>
>> Breaking the problem down, we have three things we want to separate:
>>
>> 1. The expression that may raise the exception
>> 2. The expression defining the exceptions to be caught
>> 3. The expression to be used if the exception actually is caught
>>
>>>From there it is possible to come up with all sorts of variants.
>>
>> Option 1:
>>
>> Change the relative order of the clauses by putting the exception
>> definition last:
>>
>>   x = float(string) except float('nan') if ValueError
>>   op(float(string) except float('nan') if ValueError)
>>
>> I actually like this one (that's why I listed it first). It gets the
>> clauses out of order relative to the statement, but the meaning still
>> seems pretty obvious to me.
>>
> A further extension (if we need it):
>
>     result = foo(arg) except float('inf') if ZeroDivisionError else
> float('nan')
>
> The 'else' part handles any other exceptions (not necessarily a good idea!).
>
> or:
>
>     result = foo(arg) except float('inf') if ZeroDivisionError else
> float('nan') if ValueError
>
> Handles a number of different exceptions.
>
>> Option 2:
>>
>> Follow the lamba model and allow a colon inside this form of expression:
>>
>>   x = float(string) except ValueError: float('nan')
>>   op(float(string) except ValueError: float('nan'))
>>
>> This has the virtue of closely matching the statement syntax, but
>> embedding colons inside expressions is somewhat ugly. Yes, lambda
>> already does it, but lambda can hardly be put forward as a paragon of
>> beauty.
>>
> A colon is also used in a dict literal.
>
>> Option 3a/3b:
>>
>> Raymond's except-else suggestion:
>>
>>   x = float(string) except ValueError else float('nan')
>>   op(float(string) except ValueError else float('nan'))
>>
> [snip]
> -1
> ___
> 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/eric.pruitt%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
h

[Python-Dev] Tkinter has many files

[cool-RR]

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. What I've noticed
when I did that is that Tkinter has *a lot* of files. This is a bit
inconvenient for several reasons, the main one being that the installer for
PythonTurtle takes a long time to copy all of those little files. (I think
the reason for the slowness is not the weight of the files, but the fact
that there are so many of them.) There are also other reasons why it's
annoying: Ohloh thinks my project is "Mostly written in Tcl," and git-gui
gave me trouble for trying to commit so many files.
Do you think it will be a good thing to package all of these Tkinter files
into one big file (or several big files)?

Best Wishes,
Ram Rachum.
___
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

[Michael Foord]

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. What I've noticed when I did that is that 
Tkinter has /a lot/ of files. This is a bit inconvenient for several 
reasons, the main one being that the installer for PythonTurtle takes 
a long time to copy all of those little files. (I think the reason for 
the slowness is not the weight of the files, but the fact that there 
are so many of them.) There are also other reasons why it's annoying: 
Ohloh thinks my project is "Mostly written in Tcl," and git-gui gave 
me trouble for trying to commit so many files.
Do you think it will be a good thing to package all of these Tkinter 
files into one big file (or several big files)?



Do you mean the .tcl files? Tkinter is a Python wrapper around Tcl - 
which is a separate project / programming environment that includes the 
Tk GUI. Python is not in a position to modify or repackage those files.


Why do you need to keep the whole Python distribution under version 
control? Isn't all you need a script to *generate* the py2exe'd output 
from an *installed* Python? This is the approach I take with Movable 
Python which does something very similar.


All the best,

Michael Foord



Best Wishes,
Ram Rachum.


___
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/
http://www.voidspace.org.uk/blog


___
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

[cool-RR]

>
> Why do you need to keep the whole Python distribution under version
> control? Isn't all you need a script to *generate* the py2exe'd output from
> an *installed* Python? This is the approach I take with Movable Python which
> does something very similar.
>
>
Never mind the source control issue, it's minor.

If it's not possible to minimize the number of files there, I guess I'll
have to live with it.


-- 
Sincerely,
Ram Rachum
___
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)

[Jeff McAninch]

Nick Coghlan wrote:

Option 1:

Change the relative order of the clauses by putting the exception
definition last:

  x = float(string) except float('nan') if ValueError
  op(float(string) except float('nan') if ValueError)

I actually like this one (that's why I listed it first). It gets the
clauses out of order relative to the statement, but the meaning still
seems pretty obvious to me.

  

Since I don't know the parser coding, I won't comment on the relative 
implentability (implementableness?) of the syntax options that Nick,
P.J. and Raymond suggested.  But all seem readable and debugable.

Nick's option 1 seems like it might be the most understandable to 
a Python novice.


Would the full syntax include multiple Exceptions after the "if"?

Jeff

--
==
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)

[Russell E. Owen]

In article ,
 Xavier Morel  wrote:

> On 6 Aug 2009, at 00:22 , Jeff McAninch wrote:
> > I'm new to this list, so please excuse me if this topic has been  
> > discussed, but I didn't
> > see anything similar in the archives.
> >
> > I very often want something like a try-except conditional expression  
> > similar
> > to the if-else conditional.
> I fear this idea is soon going to extend to all compound statements  
> one by one.
> 
> 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:.

I like this idea a lot.

-- Russell

___
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)

[Dino Viehland]

On option 1 is this legal then?

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

-Original Message-
From: python-dev-bounces+dinov=microsoft@python.org 
[mailto:python-dev-bounces+dinov=microsoft@python.org] On Behalf Of Nick 
Coghlan
Sent: Thursday, August 06, 2009 3:48 AM
To: P.J. Eby
Cc: python-dev@python.org; Jeff McAninch
Subject: Re: [Python-Dev] (try-except) conditional expression similar to 
(if-else) conditional (PEP 308)

P.J. Eby wrote:
> At 05:59 PM 8/5/2009 -0700, Raymond Hettinger wrote:
>> [Jeffrey E. McAninch, PhD]
>>> I very often want something like a try-except conditional expression
>>> similar to the if-else conditional.
>>>
>>> An example of the proposed syntax might be:
>>>x = float(string) except float('nan') or possibly
>>>x = float(string) except ValueError float('nan')
>>
>> +1 I've long wanted something like this.
>> One possible spelling is:
>>
>>   x = float(string) except ValueError else float('nan')
>
> I think 'as' would be better than 'else', since 'else' has a different
> meaning in try/except statements, e.g.:
>
>x = float(string) except ValueError, TypeError as float('nan')
>
> Of course, this is a different meaning of 'as', too, but it's not "as"
> contradictory, IMO...  ;-)

(We're probably well into python-ideas territory at this point, but I'll keep 
things where the thread started for now)

The basic idea appears sound to me as well. I suspect finding an acceptable 
syntax is going to be the sticking point.

Breaking the problem down, we have three things we want to separate:

1. The expression that may raise the exception 2. The expression defining the 
exceptions to be caught 3. The expression to be used if the exception actually 
is caught

>From there it is possible to come up with all sorts of variants.

Option 1:

Change the relative order of the clauses by putting the exception definition 
last:

  x = float(string) except float('nan') if ValueError
  op(float(string) except float('nan') if ValueError)

I actually like this one (that's why I listed it first). It gets the clauses 
out of order relative to the statement, but the meaning still seems pretty 
obvious to me.

Option 2:

Follow the lamba model and allow a colon inside this form of expression:

  x = float(string) except ValueError: float('nan')
  op(float(string) except ValueError: float('nan'))

This has the virtue of closely matching the statement syntax, but embedding 
colons inside expressions is somewhat ugly. Yes, lambda already does it, but 
lambda can hardly be put forward as a paragon of beauty.

Option 3a/3b:

Raymond's except-else suggestion:

  x = float(string) except ValueError else float('nan')
  op(float(string) except ValueError else float('nan'))

This has the problem of inverting the sense of the else clause relative to the 
statement form (where the else clause is executed only if no exception occurs)

A couple of extra keywords would get the sense correct again, but I'm not sure 
the parser could cope with it and it is rather verbose (I much prefer option 1 
to this idea):

  x = float(string) if not except ValueError else float('nan')
  op(float(string) if not except ValueError else float('nan'))

Option 4:

PJE's except-as suggestion:

  x = float(string) except ValueError as float('nan')
  op(float(string) except ValueError as float('nan'))

Given that we now use "except ValueError as ex" in exception statements, the 
above strikes me a really confusing idea.

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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/dinov%40microsoft.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

[Python-Dev] issue 6654

[Kristján Valur Jónsson]

I added http://bugs.python.org/issue6654
I also put a not to python-ideas but have had no response yet.  Any comments?
Here's the summary:


I've created http://codereview.appspot.com/100046 on Rietveld:

by passing the "path" component of the xmlrpc request to the dispatch

method, itbecomes possible to dispatch differently according to this.  This 
patch

providesthat addition.

Additionally, it provides an MultiPathXMLRPCDispatcher mixin

class and a MultiPathXMLRPCServer that uses it, to have multiple dispatchers for

different paths.

This allows a single server port to serve different XMLRPC servers as

differentiated by the HTTP path.  A test is also preovided.


Kristján
___
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

[Neil Hodgson]

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?

   Neil
___
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)

[MRAB]

Dino Viehland wrote:

On option 1 is this legal then?

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


Well, is this is legal?

try:
x = float(string)
except some_check():
x = float('nan')
except ValueError:
x = float('inf')

In other words, some_check() returns an exception _class_.

>>> def get_exception():
return ValueError

>>> try:
x = float("")
except get_exception():
print "not a float"


not a float

___
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)

[Dino Viehland]

MRAB wrote:
> Dino Viehland wrote:
> > On option 1 is this legal then?
> >
> > x = float(string) except float('nan') if some_check() else float('inf') if
> ValueError
> >
> Well, is this is legal?
>
>  try:
>  x = float(string)
>  except some_check():
>  x = float('nan')
>  except ValueError:
>  x = float('inf')
>

I was thinking this was would be equal to:

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


___
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)

[MRAB]

Dino Viehland wrote:

MRAB wrote:

Dino Viehland wrote:

On option 1 is this legal then?

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

ValueError
Well, is this is legal?

 try:
 x = float(string)
 except some_check():
 x = float('nan')
 except ValueError:
 x = float('inf')



I was thinking this was would be equal to:

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


I suppose it depends on the precedence of 'x except y if z' vs 'x if y
else y'.
___
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)

[MRAB]

Russell E. Owen wrote:

In article ,
 Xavier Morel  wrote:


On 6 Aug 2009, at 00:22 , Jeff McAninch wrote:
I'm new to this list, so please excuse me if this topic has been  
discussed, but I didn't

see anything similar in the archives.

I very often want something like a try-except conditional expression  
similar

to the if-else conditional.
I fear this idea is soon going to extend to all compound statements  
one by one.


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


I like this idea a lot.


For some reason this kind of reminds me of BCPL.

A function definition looked like:

LET func_name(arg1, arg2) = expression

so, strictly speaking, no multiline functions.

However, there was also the VALOF ... RESULTIS ... block.

In Python, the 'return' statement provides the result of a function; in
BCPL, the 'RESULTIS' statement provided the result of the VALOF block,
which was call from within an expression, like:

LET foo(...) = VALOF
$(
...
RESULTIS expression
$)
___
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

[Terry Reedy]

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.


___
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