Re: [Python-Dev] Bare except clauses in PEP 348

[Michael Hudson]

Guido van Rossum <[EMAIL PROTECTED]> writes:

> On 8/24/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
>> I really hope string exceptions can be killed off before 3.0.  They
>> should be fully deprecated in 2.5.
>
> But what about class exceptions that don't inherit from Exception?
> That will take a while before we can deprecate that.

Oh, for sure.  I didn't mean to imply anything else.

Cheers,
mwh

-- 
 "Sturgeon's Law (90% of everything is crap) applies to Usenet."
 "Nothing guarantees that the 10% isn't crap, too."
-- Gene Spafford's Axiom #2 of Usenet, and a corollary
___
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] python-dev Summary for 2005-08-01 through 2005-08-15 [draft]

[Tony Meyer]

Here's August Part One.  As usual, if anyone can spare the time to proofread
this, that would be great!  Please send any corrections or suggestions to
Steve (steven.bethard at gmail.com) and/or me, rather than cluttering the
list.  Ta!

=
Announcements
=


QOTF: Quote of the Fortnight


Some wise words from Donovan Baarda in the PEP 347 discussions:

It is true that some well designed/developed software becomes reliable
very quickly. However, it  still takes heavy use over time to prove that.

Contributing thread:

- `PEP: Migrating the Python CVS to Subversion
`__

[SJB]


Process PEPs


The PEP editors have introduced a new PEP category: "Process", for PEPs that
don't fit into the  "Standards Track" and "Informational" categories.  More
detail can be found in `PEP 1`_, which it  itself a Process PEP.

.. _PEP 1: http://www.python.org/peps/pep-0001.html

Contributing thread:

- `new PEP type: Process
`__

[TAM]

---
Tentative Schedule for 2.4.2 and 2.5a1 Releases
---

Python 2.4.2 is tentatively scheduled for a mid-to-late September release,
and a first alpha of Python  2.5 for March 2006 (with a final release around
May/June).  This means that a PEP for the 2.5 release,  detailing what will
be included, will likely be created soon; at present there are various
accepted  PEPs that have not yet been implemented.

Contributing thread:

- `plans for 2.4.2 and 2.5a1
`__

[TAM]

=
Summaries
=

---
Moving Python CVS to Subversion
---

The `PEP 347`_ discussion from last fortnight continued this week, with a
revision of the PEP, and a  lot more discussion about possible version
control software (RCS) for the Python repository, and where  the repository
should be hosted.  Note that this is not a discussion about bug trackers,
which will  remain with Sourceforge (unless a separate PEP is developed for
moving that).

Many revision control systems were extensively discussed, including
`Subversion`_ (SVN), `Perforce`_,  and `Monotone`_.  Whichever system is
moved to, it should be able to be hosted somewhere (if  *.python.org, then
it needs to be easily installable), needs to have software available to
convert a  repository from CVS, and ideally would be open-source; similarity
to CVS is also an advantage in that  it requires a smaller learning curve
for existing developers.  While Martin isn't willing to discuss  every
system there is, he will investigate those that make him curious, and will
add other people's  submissions to the PEP, where appropriate.

The thread included a short discussion about the authentication mechanism
that svn.python.org will  use; svn+ssh seems to be a clear winner, and a
test repository will be setup by Martin next fortnight.

The possibility of moving to a distributed revision control system
(particularly `Bazaar-NG`_) was  also brought up.  Many people liked the
idea of using a distributed revision control system, but it  seems unlikely
that Bazaar-NG is mature enough to be used for the main Python repository at
the  current time (a move to it at a later time is possible, but outside the
scope of the PEP).   Distributed RCS are meant to reduce the barrier to
participation (anyone can create the their own  branches, for example);
Bazaar-NG is also implemented in Python, which is of some benefit.  James Y
Knight pointed out `svk`_, which lets developers create their own branches
within SVN.

In general, the python-dev crowd is in favour of moving to SVN.  Initial
concern about the demands on  the volunteer admins should the repository be
hosted at svn.python.org were addressed by Barry Warsaw,  who believes that
the load will be easily managed with the existing volunteers.  Various
alternative  hosts were discussed, and if detailed reports about any of them
are created, these can be added to the  PEP.

While the fate of all PEPS lie with the BDFL (Guido), it is likely that the
preferences of those that  frequently check in changes, the pydotorg admins,
and the release managers (who have all given  favourable reports so far),
will have a significant effect on the pronouncement of this PEP.

.. _PEP 347: http://www.python.org/peps/pep-0347.html
.. _svk: http://svk.elixus.org/
.. _Perforce: http://www.perforce.com/
.. _Subversion: http://subversion.tigris.org/
.. _Monotone: http://venge.net/monotone/
.. _Bazaar-NG: http://www.bazaar-ng.org/

Contributing threads:

- `PEP: Migrating the Python CVS to Subversion
`__
- `PEP 347: Migration to Subversion

Re: [Python-Dev] Style for raising exceptions (python-dev Summary for 2005-08-01 through 2005-08-15 [draft])

[M.-A. Lemburg]

I must have missed this one:

> 
> Style for raising exceptions
> 
> 
> Guido explained that these days exceptions should always be raised as::
> 
> raise SomeException("some argument")
> 
> instead of::
> 
> raise SomeException, "some argument"
> 
> The second will go away in Python 3.0, and is only present now for backwards
> compatibility.  (It was  necessary when strings could be exceptions, in
> order to pass both the exception "type" and message.)   PEPs 8_ and 3000_
> were accordingly updated.

AFAIR, the second form was also meant to be able to defer
the instantiation of the exception class until really
needed in order to reduce the overhead related to raising
exceptions in Python.

However, that optimization never made it into the implementation,
I guess.

> .. _8: http://www.python.org/peps/pep-0008.html
> .. _3000: http://www.python.org/peps/pep-3000.html
> 
> Contributing threads:
> 
> - `PEP 8: exception style
> `__
> - `FW: PEP 8: exception style
> `__

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 25 2005)
>>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] Bare except clauses in PEP 348

[Raymond Hettinger]

> > OK, I'm convinced. Let's drop bare except for Python 3.0, and
> > deprecate them until then, without changing the meaning.
> >
> 
> Woohoo

That's no cause for celebration.  Efforts to improve Py3.0 have spilled
over into breaking Py2.x code with no compensating benefits.  Bare
except clauses appear in almost every Python book that has ever been
written and occur at least once in most major Python applications.

I had thought the plan was to introduce Py3.0 capabilities into 2.x as
they become possible but not to break anything.  Isn't that why string
exceptions, buffer(), and repr() still live and breathe?

We don't have to wreck 2.x in order to make 3.0 better.  I wish the 3.0
PEPs would stop until we are actually working on the project and have
some chance of making people's lives better.  If people avoid 2.5 just
to avert unnecessary breakage, then Py3.0 doesn't benefit at all.

I propose that the transition plan be as simple as introducing
BaseException.  This allows people to write code that will work on both
2.x and 3.0.  It doesn't break anything.  

The guidance for cross-version (2.5 to 3.0) code would be:

* To catch all but terminating exceptions, write:

except (KeyError, SystemExit):
raise
except Exception:   
...

* To catch all exceptions, write:
except BaseException:   
...


To make the code also run on 2.4 and prior, add transition code:

try:
BaseException
except NameError:
class BaseException(Exception):
pass

With that minimal guidance, people can write code that works on from 2.0
to 3.0 and not break anything that is currently working.  No
deprecations are necessary.

Remember, the ONLY benefit from the whole PEP is that in 3.0, it will no
longer be necessary to write "except (KeyError, SystemExit):  raise".
Steven and Jack's research show that that doesn't arise much in practice
anyway.  IOW, there's nothing worth inflicting destruction on tons of
2.x code.



Raymond

___
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] Bare except clauses in PEP 348

[Michael Chermside]

Raymond writes:
> Efforts to improve Py3.0 have spilled
> over into breaking Py2.x code with no compensating benefits. [...]
> We don't have to wreck 2.x in order to make 3.0 better.

I think you're overstating things a bit here.

> Remember, the ONLY benefit from the whole PEP is that in 3.0, it will no
> longer be necessary to write "except (KeyError, SystemExit):  raise".
> [...] IOW, there's nothing worth inflicting destruction on tons of
> 2.x code.

And now I *KNOW* you're overstating things. There are LOTS of benefits
to the PEP in 3.0. My own personal favorite is that users can be
guaranteed that all exceptions thrown will share a particular common
ancestor and type. And no one is proposing "destruction" of 2.x code.

On the other hand, I thought these were very good points:
> Bare
> except clauses appear in almost every Python book that has ever been
> written and occur at least once in most major Python applications.
 [...]
> I had thought the plan was to introduce Py3.0 capabilities into 2.x as
> they become possible but not to break anything.
 [...]
> I propose that the transition plan be as simple as introducing
> BaseException.  This allows people to write code that will work on both
> 2.x and 3.0.

I think the situation is both better than and worse than you describe. The
PEP is now proposing that bare "except:" be removed in Python 3.0. If I
understand Guido correctly, he is proposing that in 2.5 the use of
bare "except:" generate a PendingDeprecationWarning so that conscientious
developers who want to write code now that will continue to work in
Python 3.0 can avoid using bare "except:". Perhaps I'm misreading him
here, but I presume this was intended as a PENDINGDeprecationWarning so
that it's easy to ignore.

But it's a bit worse than it might seem, because conscientious users
aren't ABLE to write safe 2.5 code that will run in 3.0. The problem
arises when you need to write code that calls someone else's library
but then unconditionally recovers from errors in it. Correct 2.4 syntax
for this reads as follows:

try:
my_result = call_some_library(my_data)
except (KeyboardInterrupt, MemoryError, SystemError):
raise
except:
report_error()

Correct 3.0 syntax will read like this:

try:
my_result = call_some_library(my_data)
except (KeyboardInterrupt, MemoryError, SystemError):
raise
except BaseException:
report_error()

But no syntax will work in BOTH 2.5 and 3.0. The 2.4 syntax is
illegal in 3.0, and the 3.0 syntax fails to catch exceptions that
do not inherit from BaseException. Such exceptions are deprecated
(by documentation, if not by code) so our conscientious programmer
will never raise them and the standard library avoids doing so.
But "call_some_library()" was written by some less careful
developer, and may well contain these atavisims.

The only complete solution that comes to mind immediately is for
the raising of anything not extending BaseException to raise a
PendingDeprecationWarning as well. Then the conscientious developer
can feel confident again so long as her unit tests are reasonably
exhaustive. If we cannot produce a warning for these, then I'd
rather not produce the warning for the use of bare "except:".
After all, as it's been pointed out, if the use of bare "except:"
is all you are interested in it is quite easy to grep the code to
find all uses.

-- Michael Chermside

___
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] Bare except clauses in PEP 348

[Raymond Hettinger]

> > Efforts to improve Py3.0 have spilled
> > over into breaking Py2.x code with no compensating benefits. [...]
> > We don't have to wreck 2.x in order to make 3.0 better.
> 
> I think you're overstating things a bit here.

It's only an overstatement if Guido didn't mean what he said.  If bare
except clauses are deprecated in 2.x, it WILL affect tons of existing
code and invalidate a portion of almost all Python books.



> > Remember, the ONLY benefit from the whole PEP is that in 3.0, it
will no
> > longer be necessary to write "except (KeyError, SystemExit):
raise".
> > [...] IOW, there's nothing worth inflicting destruction on tons of
> > 2.x code.
> 
> And now I *KNOW* you're overstating things. There are LOTS of benefits
> to the PEP in 3.0. My own personal favorite is that users can be
> guaranteed that all exceptions thrown will share a particular common
> ancestor and type. 

Right, there are a couple of parts of the PEP that were
non-controversial from the start and would likely have happened even in
the absence of the PEP.

My point was that a lot of machinery is being thrown at a tiny problem.
To eliminate the need for "except (KeyError, SystemExit):  raise", we're
rearranging the tree, introducing a new builtin, banning an existing and
popular form of an except clause, and introducing a non-trivial
deprecation that will affect most users.  This is a lot of firepower
directed at a somewhat small problem.



> But no syntax will work in BOTH 2.5 and 3.0. 

There's the rub.  If you can't write code that will work for both, then
there is no reason to force 2.x users to make any changes to their
existing code, especially given that they won't see any benefit from the
mass edits.



> If we cannot produce a warning for these, then I'd
> rather not produce the warning for the use of bare "except:".
> After all, as it's been pointed out, if the use of bare "except:"
> is all you are interested in it is quite easy to grep the code to
> find all uses.

Bingo.  A bare except clause is well known as a consenting adults
construct.  If Guido feels driven to eliminate it from Py3.0, then that
is the way it is.  But for 2.x, why introduce unnecessary pain.

Of course, if bare except clauses weren't banned for 3.0, then we would
have no problem writing code that works on all versions on Python from
2.0 to 3.0, that doen't break existing code, and that doesn't invalidate
the text in Python books.  IMO, that is a nice situation.  Just how
badly do you want to kill bare except clauses.

I propose that leave them alone, and be happy that in 3.0 we can write
"except Exception" and get what we want without any fuss.



Raymond

___
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] Bare except clauses in PEP 348

[Sjoerd Mullender]

Michael Chermside wrote:
> Raymond writes:
> 
>>Efforts to improve Py3.0 have spilled
>>over into breaking Py2.x code with no compensating benefits. [...]
>>We don't have to wreck 2.x in order to make 3.0 better.
> 
> 
> I think you're overstating things a bit here.

There is an important point, though.  Recently I read complaints about
the lack of backward compatibility in Python on the fedora-list (mailing
list for users of Fedora Core).  Somebody asked what language he should
learn and people answered, don't learn Python because it changes too
often in backward incompatible ways.  They even suggested using that
other P language because that was much more backward compatible.

Check out the thread starting at
https://www.redhat.com/archives/fedora-list/2005-August/msg01682.html .

-- 
Sjoerd Mullender


signature.asc
Description: OpenPGP digital signature
___
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] Bare except clauses in PEP 348

[Guido van Rossum]

On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> It's only an overstatement if Guido didn't mean what he said.  If bare
> except clauses are deprecated in 2.x, it WILL affect tons of existing
> code and invalidate a portion of almost all Python books.

Deprecation means your code will still work I hope every book that
documents "except:" also adds "but don't use this except under very
special circumstances".

I think you're overreacting (again), Raymond. 3.0 will be much more
successful if we can introduce many of its features into 2.x. Many of
those features are in fact improvements of the language even if they
break old code. We're trying to balance between breaking old code and
introducing new features; deprecation is the accepted way to do this.

Regarding the complaint that Python is changing too fast, that really
sounds like FUD to me. With a new release every 18 months Python is
about as stable as it gets barring dead languages. The PHP is in the
throws of the 4->5 conversion which breaks worse than Python 2->3 will
(Rasmus ia changing object assignment semantics from copying to
sharing).  Maybe they should be warned not to learn Perl because Larry
is deconstructing it all for Perl 6? :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Bare except clauses in PEP 348

[Tim Lesher]

On 8/25/05, Sjoerd Mullender <[EMAIL PROTECTED]> wrote:
> There is an important point, though.  Recently I read complaints about
> the lack of backward compatibility in Python on the fedora-list (mailing
> list for users of Fedora Core).  Somebody asked what language he should
> learn and people answered, don't learn Python because it changes too
> often in backward incompatible ways.  They even suggested using that
> other P language because that was much more backward compatible.

I think you're overstating what actually happened there.  Here's the
actual quote from the thread:

: perl is more portable than python - programs written for perl are far
: more likely to run on a new version of perl than the equivalent for
: python. However, python is probably more readable and writable than perl
: for a new user, and is the language most Fedora system utilities (e.g.
: yum) are written in. Both perl and python run on Windows too.
: 
: You have to be very careful about how you write your code to make it
: portable to both environments. If you need a GUI, you'll need a
: cross-platform GUI toolkit like Qt too.
: 
: If it's only one language to learn, and you're a Fedora user, I'd go for
: python.

Yes, later there were additional posts about portability and
backwards-compatibility, but they were for the most part factually
incorrect (reliance on new 2.x features, not
backwards-incompatibility, were the issue with CML1) and relied to "I
heard that..." information

So your point is well-taken, but the problem is one of user
perception.  That's not a dismissal of the problem--witness the
"JAVA/LISP/Python is too slow" and "all PERL code is cryptic" memes.

To me, this perception problem alone raises the bar on backwards
compatibility. Even if obsoleted features are seldom useed, "$language
breaks old code!" is a virulent meme, in both senses of the word.
-- 
Tim Lesher <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Style for raising exceptions (python-dev Summary for 2005-08-01 through 2005-08-15 [draft])

[Guido van Rossum]

On 8/25/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I must have missed this one:
> 
> > 
> > Style for raising exceptions
> > 
> >
> > Guido explained that these days exceptions should always be raised as::
> >
> > raise SomeException("some argument")
> >
> > instead of::
> >
> > raise SomeException, "some argument"
> >
> > The second will go away in Python 3.0, and is only present now for backwards
> > compatibility.  (It was  necessary when strings could be exceptions, in
> > order to pass both the exception "type" and message.)   PEPs 8_ and 3000_
> > were accordingly updated.
> 
> AFAIR, the second form was also meant to be able to defer
> the instantiation of the exception class until really
> needed in order to reduce the overhead related to raising
> exceptions in Python.
> 
> However, that optimization never made it into the implementation,
> I guess.

Something equivalent is used internally in the C code, but that
doesn't mean we'll need it in Python code. The optimization only works
if the exception is also *caught* in C code, BTW (it is instantiated
as soon as it is handled by a Python except clause).

Originally, the second syntax was the only available syntax, because
all we had were string exceptions. Now that string exceptions are dead
(although not yet buried :) I really don't see why we need to keep
both versions of the syntax; Python 3.0 will only have one version.
(We're still debating what to do with the traceback argument; wanna
revive PEP 344?)

If you need to raise exceptions fast, pre-instantiate an instance.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Bare except clauses in PEP 348

[Raymond Hettinger]

> Deprecation means your code will still work I hope every book that
> documents "except:" also adds "but don't use this except under very
> special circumstances".
> 
> I think you're overreacting (again), Raymond. 3.0 will be much more
> successful if we can introduce many of its features into 2.x. Many of
> those features are in fact improvements of the language even if they
> break old code. We're trying to balance between breaking old code and
> introducing new features; deprecation is the accepted way to do this.

IMO, the proponents of 2.x deprecation are underreacting.  Deprecation
has a cost -- there needs to be a corresponding payoff.  Deprecation is
warranted if the substitute code would still run on future Pythons
(Michael explained the issues here).  Deprecation is only warranted if
the interim substitute works -- AFAICT, there is no other way to broadly
catch exceptions not derived from Exception.  The effort is only
warranted if it makes the code better -- but here nothing is currently
broken and the new code will be much less attractive and less readable
(if the changes are done correctly); only 3.0 will offer the tools to do
it readably and beautifully.  Also, as we learned with apply(), even if
ignored, the deprecation machinery has a tremendous runtime cost.  None
of this will make upgrading to Py2.5 an attractive option.

There is a reason that over 120 bare except clauses remain in the
standard library despite a number of attempts to get rid of them.  It
won't be trivial to properly evaluate whether each should be Exception
or BaseException; to catch string exceptions; to write the test cases;
to follow other PEPs requiring compatibility with older Pythons; or to
do this in a way that it won't have to be done again for Py3.0.  If the
proponents don't have time to fix the standard library, how can they in
good conscience mandate change for the rest of the world.

Besides, I thought Guido was opposed to efforts to roam through
mountains of code, making alterations in a non-holistic way.  With a
change this complex, the odds of introducing errors are very high.

Fredrik, please speak up.  Someone should represent the users here.  I'm
reached my limit on how much time I can devote to thinking out the
implications of these proposals.  Someone else needs to "overreact". 

___
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] Bare except clauses in PEP 348

[Neil Schemenauer]

On Thu, Aug 25, 2005 at 11:58:48AM -0400, Raymond Hettinger wrote:
> Deprecation is only warranted if the interim substitute works --
> AFAICT, there is no other way to broadly catch exceptions not
> derived from Exception.

This seems to get to the heart of the problem.  I'm no fan of bare
excepts but I think we could handle them in 2.x (at least for the
next few releases) by providing a workable alternative and then
strongly discouraging their use (like we do for "from x import *").

  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] Revised PEP 349: Allow str() to return unicode strings

[Dieter Maurer]

The following message is a courtesy copy of an article
that has been posted to comp.lang.python as well.

Neil Schemenauer <[EMAIL PROTECTED]> writes on Mon, 22 Aug 2005 15:31:42 -0600:
> ...
> Some code may require that str() returns a str instance.  In the
> standard library, only one such case has been found so far.  The
> function email.header_decode() requires a str instance and the
> email.Header.decode_header() function tries to ensure this by
> calling str() on its argument.  The code was fixed by changing
> the line "header = str(header)" to:
> 
> if isinstance(header, unicode):
> header = header.encode('ascii')

Note, that this is not equivalent to the old "str(header)":

  "str(header)" used Python's "default encoding" while the
  new code uses 'ascii'.

  The new code might be more correct than the old one has been.


> ...
> Alternative Solutions
> 
> A new built-in function could be added instead of changing str().
> Doing so would introduce virtually no backwards compatibility
> problems.  However, since the compatibility problems are expected to
> rare, changing str() seems preferable to adding a new built-in.

Can we get a new builtin with the exact same behaviour as
the current "str" which can be used when we do require an "str"
(and cannot use a "unicode").



Dieter
___
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] [Argon] Re: 51 Million calls to _PyUnicodeUCS2_IsLinebreak() (???)

[Greg Wilson]

Hi Martin (and everyone else); thanks for your mail.  The N*N/2
invocations would explain why we saw such a large number of invocations
--- thanks for figuring it out.  W.r.t. how we're invoking our script:

> > But if you're using CGI, you're importing your source on every
> > invocation.
>
> Well, no. Only the CGI script needs to be parsed every time; all modules
> could load off bytecode files.
>
> Which suggests that Keir Mierle doesn't use bytecode files, I think he
> should.

Yes, mod_python and .pyc's are the obviously way to go --- once the code
actually works ;-).  I just wanted students to have as few moving parts as
possible while debugging.

Thanks again,
Greg
___
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] [Argon] Re: 51 Million calls to _PyUnicodeUCS2_IsLinebreak() (???)

[Greg Wilson]

> > Walter Dörwald wrote:
> >>At least it would remove the quadratic number of calls to
> >>_PyUnicodeUCS2_IsLinebreak(). For each character it would be called only
> >>once.

> Martin v. Löwis wrote:
> > Correct. However, I very much doubt that this is the cause of the
> > slowdown.

> Walter Dörwald wrote:
> Probably. We'd need a test with the original Argon source to really know.

We can do that.

> OK, so should we add this for 2.4.2 or only for 2.5?

2.4.2 please ;-)

Thanks,
Greg
___
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] Bare except clauses in PEP 348

[Guido van Rossum]

On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>[...] AFAICT, there is no other way to broadly
> catch exceptions not derived from Exception.

But there is rarely a need to do so. I bet you that 99 out of 100 bare
excepts in the stdlib could be replaced by "except Exception" without
breaking anything, since they only expect a wide variety of standard
exceptions, and don't care about string exceptions or user exceptions.

The exception is the first of the two bare except: clauses in code.py.

> The effort is only
> warranted if it makes the code better -- but here nothing is currently
> broken and the new code will be much less attractive and less readable
> (if the changes are done correctly); only 3.0 will offer the tools to do
> it readably and beautifully.

Please explain? If 9 out of 10 bare excepts can safely be replaced by
"except Exception", what's not beautiful about that?

> Also, as we learned with apply(), even if
> ignored, the deprecation machinery has a tremendous runtime cost.  None
> of this will make upgrading to Py2.5 an attractive option.

Not in this case; bare except: can be flagged by the parser so the
warning happens only once per compilation.
 
> There is a reason that over 120 bare except clauses remain in the
> standard library despite a number of attempts to get rid of them.

I betcha almost all of then can safely be replaced with "except Exception".

> Besides, I thought Guido was opposed to efforts to roam through
> mountains of code, making alterations in a non-holistic way.

This is trumped by the need to keep the standard library warning-free.

But how about the following compromise: make it a silent deprecation
in 2.5, and a full deprecation in 2.6.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Revised PEP 349: Allow str() to return unicode strings

[Neil Schemenauer]

On Wed, Aug 24, 2005 at 09:11:18PM +0200, Dieter Maurer wrote:
> Neil Schemenauer <[EMAIL PROTECTED]> writes on Mon, 22 Aug 2005 15:31:42 
> -0600:
> > The code was fixed by changing
> > the line "header = str(header)" to:
> > 
> > if isinstance(header, unicode):
> > header = header.encode('ascii')
> 
> Note, that this is not equivalent to the old "str(header)":
> 
>   "str(header)" used Python's "default encoding" while the
>   new code uses 'ascii'.

It also doesn't call __str__ if the object is not a basestring
instance.  I have a hard time understanding the exact purpose of
calling str() here.  Maybe Barry can comment.

> Can we get a new builtin with the exact same behaviour as
> the current "str" which can be used when we do require an "str"
> (and cannot use a "unicode").

That fact that no code in the standard library requires such a
function (AFAIK), leads me to believe that it would not be useful
enough to be made a built-in.  You would just write it yourself:

def mystr(s):
s = str(s)
if isinstance(s, unicode):
s = s.encode(sys.getdefaultencoding())
return s

Cheers,

  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] Bare except clauses in PEP 348

[Reinhold Birkenfeld]

Raymond Hettinger wrote:
>> Deprecation means your code will still work I hope every book that
>> documents "except:" also adds "but don't use this except under very
>> special circumstances".
>> 
>> I think you're overreacting (again), Raymond. 3.0 will be much more
>> successful if we can introduce many of its features into 2.x. Many of
>> those features are in fact improvements of the language even if they
>> break old code. We're trying to balance between breaking old code and
>> introducing new features; deprecation is the accepted way to do this.

> Fredrik, please speak up.  Someone should represent the users here.  I'm
> reached my limit on how much time I can devote to thinking out the
> implications of these proposals.  Someone else needs to "overreact".

Perhaps I may add a pragmatic POV (yes, I know that "pragmatic" is usually
attributed to another language ;-).

If "except:" issues a deprecation warning in 2.5, many people will come and
say "woohoo, Python breaks backwards compatibility" and "I knew it, Python
is unreliable, my script issues 1,233 warnings now" and such.

You can see this effect looking at the discussion that broke out when Guido
announced that map, filter and reduce would vanish (as builtins) in 3.0.
People spoke up and said, "if that's going to be the plan, I'll stop using
Python" etc.

That said, I think that unless it is a new feature (like with statements)
transitions to Python 3.0 shouldn't be enforced in the 2.x series. With 3.0,
everyone expects a clear cut and a compatibility breach.

Reinhold

-- 
Mail address is perfectly valid!

___
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] Bare except clauses in PEP 348

[Raymond Hettinger]

> > Also, as we learned with apply(), even if
> > ignored, the deprecation machinery has a tremendous runtime cost.
None
> > of this will make upgrading to Py2.5 an attractive option.
> 
> Not in this case; bare except: can be flagged by the parser so the
> warning happens only once per compilation.

That's good news.  It mitigates runtime cost completely.



> > There is a reason that over 120 bare except clauses remain in the
> > standard library despite a number of attempts to get rid of them.
> 
> I betcha almost all of then can safely be replaced with "except
> Exception".

Because the tree is not being re-arranged until 3.0, those cases should
also introduce a preceding:

   except (KeyboardInterrupt, SystemExit):
   raise

Anywhere that doesn't apply will need:

   except BaseException:
  . . .

and also some corresponding backwards compatibility code to work with
older pythons.

If any are expected to work with user or third-party modules, then they
cannot safely ignore string exceptions and exceptions not derived from
Exception.  

Each of those changes needs to be accompanied by test cases so that all
code paths get exercised.

After the change, we should run Zope, Twisted, Gadfly, etc to make sure
no major application got broken.  Long running apps should verify that
their recover and restart routines haven't been compromised.  This is
doubly true if the invariant for a bare except was being relied upon as
a security measure (this may or may not be a real issue).



> But how about the following compromise: make it a silent deprecation
> in 2.5, and a full deprecation in 2.6.

I'd love to compromise but it's your language.  If you're going to
deprecate, just do it.  Pulling the band-aid off slowly doesn't lessen
the total pain.

My preference is of course, to leave 2.x alone and make this part of the
attraction to 3.0.  Remember, none of the code changes buys us anything
in 2.x.  It is an exercise without payoff.

My even stronger preference is to leave bare excepts in for Py3.0.  That
buys us a happy world where code old code continues to work and new code
can be written that functions as intended on all pythons new and old.

I'm no fan of bare exceptions, but I'm not inclined to shoot myself in
the foot to be rid of them.  I wish Fredrik would chime in.  He would
have something pithy, angry, and incisive to say about this.



Raymond

___
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] Bare except clauses in PEP 348

[Scott David Daniels]

Raymond Hettinger wrote:
>... I propose that the transition plan be as simple as introducing
> BaseException.  This allows people to write code that will work on both
> 2.x and 3.0.  It doesn't break anything.  
> 
> The guidance for cross-version (2.5 to 3.0) code would be:
> 
> * To catch all but terminating exceptions, write:
> 
> except (KeyError, SystemExit):
> raise
> except Exception:   
> ...
How about:
   except BaseException, error:
   if not isinstance(error, Exception):
   raise
   ...

This would accommodate other invented exceptions  such as
"FoundConvergance(BaseException)", which is my pseudo-example
for an exiting exception that is not properly a subclass of
either KeyError or SystemExit.  The idea is a relaxation stops
when it doesn't move and may start generating something silly
like divide-by-zero.  Not the end of an App, but the end of a Phase.

--Scott David Daniels
[EMAIL PROTECTED]

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

Re: [Python-Dev] Bare except clauses in PEP 348

[Guido van Rossum]

On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:

> I wish Fredrik would chime in.  He would
> have something pithy, angry, and incisive to say about this.

Raymond, I'm sick of the abuse. Consider the PEP rejected.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Bare except clauses in PEP 348

[Michael Chermside]

Guido:
> But how about the following compromise: make it a silent deprecation
> in 2.5, and a full deprecation in 2.6.

Reinhold Birkenfeld:
> That said, I think that unless it is a new feature (like with statements)
> transitions to Python 3.0 shouldn't be enforced in the 2.x series. With 3.0,
> everyone expects a clear cut and a compatibility breach.

Raymond:
> I'd love to compromise but it's your language.  If you're going to
> deprecate, just do it.  Pulling the band-aid off slowly doesn't lessen
> the total pain.

There are actually THREE possible levels of deprecation available. In order
of severity, they are:

  1. Modifying the documentation to advise people to avoid this feature.
 No one gets alerted.

  2. Using a PendingDeprecationWarning so people who explicitly request
 it can have the compiler alert them when they use it.

  3. Using a DeprecationWarning so people using it are alerted unless they
 explicitly request NOT to be alerted.

I think 3 is unwarrented in this case. For reasons I explained in a previous
posting, I would be in favor of 2 if we can *also* have a
PendingDeprecationWarning for use of string exceptions and arbitrary-object
exceptions (those not derived from BaseException). I am in favor of 3 in
any case. Of course, that's just one person's opinion...


Raymond also raised this excellent point:
> There is a reason that over 120 bare except clauses remain in the
> standard library despite a number of attempts to get rid of them. [...]
> If the proponents don't have time to fix the standard library, how can
> they in good conscience mandate change for the rest of the world.

That seems like a fair criticism to me. As we've already noted, it is
impossible to replace ALL uses of bare "except:" in 2.5 (particularly
the
___
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] Bare except clauses in PEP 348

[Michael Chermside]

[PLEASE IGNORE PREVIOUS EMAIL... I HIT [Send] BY MISTAKE]

Guido:
> But how about the following compromise: make it a silent deprecation
> in 2.5, and a full deprecation in 2.6.

Reinhold Birkenfeld:
> That said, I think that unless it is a new feature (like with statements)
> transitions to Python 3.0 shouldn't be enforced in the 2.x series. With 3.0,
> everyone expects a clear cut and a compatibility breach.

Raymond:
> I'd love to compromise but it's your language.  If you're going to
> deprecate, just do it.  Pulling the band-aid off slowly doesn't lessen
> the total pain.

There are actually THREE possible levels of deprecation available. In order
of severity, they are:

  1. Modifying the documentation to advise people to avoid this feature.
 No one gets alerted.

  2. Using a PendingDeprecationWarning so people who explicitly request
 it can have the compiler alert them when they use it.

  3. Using a DeprecationWarning so people using it are alerted unless they
 explicitly request NOT to be alerted.

I think 3 is unwarrented in this case. For reasons I explained in a previous
posting, I would be in favor of 2 if we can *also* have a
PendingDeprecationWarning for use of string exceptions and arbitrary-object
exceptions (those not derived from BaseException). I am in favor of 3 in
any case. Of course, that's just one person's opinion...


Raymond also raised this excellent point:
> There is a reason that over 120 bare except clauses remain in the
> standard library despite a number of attempts to get rid of them. [...]
> If the proponents don't have time to fix the standard library, how can
> they in good conscience mandate change for the rest of the world.

That seems like a fair criticism to me. As we've already noted, it is
impossible to replace ALL uses of bare "except:" in 2.5 (particularly
the use in code.py that Guido referred to). But we ought to make an
extra effort to remove unnecessary uses of bare "except:" from the
standard library if we intend to deprecate it.

-- Michael Chermisde

___
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] Bare except clauses in PEP 348

[Steve Holden]

Guido van Rossum wrote:
> On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> 
> 
>>I wish Fredrik would chime in.  He would
>>have something pithy, angry, and incisive to say about this.
> 
> 
> Raymond, I'm sick of the abuse. Consider the PEP rejected.
> 
Perhaps you should go for the £10 argument next door?

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC http://www.holdenweb.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] Bare except clauses in PEP 348

[Ron Adam]

Raymond Hettinger wrote:
>>Deprecation means your code will still work I hope every book that
>>documents "except:" also adds "but don't use this except under very
>>special circumstances".
>>
>>I think you're overreacting (again), Raymond. 3.0 will be much more
>>successful if we can introduce many of its features into 2.x. Many of
>>those features are in fact improvements of the language even if they
>>break old code. We're trying to balance between breaking old code and
>>introducing new features; deprecation is the accepted way to do this.

> Fredrik, please speak up.  Someone should represent the users here.  I'm
> reached my limit on how much time I can devote to thinking out the
> implications of these proposals.  Someone else needs to "overreact".

How about a middle of the road (or there abouts) opinion from an average
user?  Just my 2 cents anyways.

I get the impression that just how much existing code will work or not
work in 3.0 is still fairly up in the air.  Python 3.0 still quite a
ways off from what I understand.

So to me.. depreciating anything at this time that's not going to be
removed *before* Python 3.0 is possibly jumping the gun a bit. (IMHO) It
definitely makes since to depreciate anything that will be removed prior
to Python 3.0.  And to also document anything that will be changed in
3.0. (but not depreciate yet)

If/when it is decided (maybe it already has) that a smooth transition
can be made between 2.x and 3.0 with a high degree of backwards
compatibility, then depreciating 2.x features that will be removed from
3.0 makes since at some point but maybe not in 2.5.

If it turns out that the amount of changes in 3.0 are such as to be a
"New but non backwards compatible version of Python" with a lot of
really great new features.  Then depreciating items in 2.x that will not
be removed from 2.x seems like it gives a since of false hope.  It might
be better to just document the differences (but not depreciate them) and
make a clean break.

Or to put it another way... having a lot of depreciated items in the
final 2.x version may give a message 2.x is flawed, yet it may not be
possible for many programs to move to 3.0 easily for some time if there
are a lot of large changes.

My opinion is... I would rather see the final version of 2.x not have
any depreciated items and efforts be made to make it the best and most
dependable 2.x version that will be around for a while.  And then have
Python 3.0 be a new beginning and an open book without the backwards
compatible chains holding it back.  That dosen't mean it won't be, I
think it's just too soon to tell to what degree.

At this time the efforts towards 3.0 seem to be towards those
improvements that may be included in some future version of 2.x which is
great.

Is it possible the big changes have yet to be considered for Python 3.0?


Cheers,
Ron








___
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] PEP 342: simple example, closure alternative

[Ian Bicking]

I was trying to translate a pattern that uses closures in a language 
like Scheme (where closed values can be written to) to generators using 
PEP 342, but I'm not clear exactly how it works; the examples in the PEP 
have different motivations.  Since I can't actually run these examples, 
perhaps someone could confirm or debug these:

A closure based accumulator (using Scheme):

(define (accum n)
  (lambda (incr)
   (set! n (+ n incr))
   n))
(define s (accum 0))
(s 1) ; -> 1 == 0+1
(s 5) ; -> 6 == 1+5

So I thought the generator version might look like:

def accum(n):
 while 1:
 incr = (yield n) or 0
 n += incr

 >>> s = accum(0)
 >>> s.next()
 >>> s.send(1)
0
 >>> s.send(5)
1
 >>> s.send(1)
6

Is the order of the output correct?  Is there a better way to write 
accum, that makes it feel more like the closure-based version?

Is this for loop correct?

 >>> s = accum(0)
 >>> for i in s:
... if i >= 10: break
... print i,
... assert s.send(2) == i
0 2 4 6 8

Hmm... maybe this would make it feel more closure-like:

def closure_like(func):
 def replacement(*args, **kw):
 return ClosureLike(func(*args, **kw))
 return replacement

class ClosureLike(object):
 def __init__(self, iterator):
 self.iterator = iterator
 # I think this initial .next() is required, but I'm
 # very confused on this point:
 assert self.iterator.next() is None
 def __call__(self, input):
 assert self.iterator.send(input) is None
 return self.iterator.next()

@closure_like
def accum(n):
 while 1:
 # yields should always be in pairs, the first yield is input
 # and the second yield is output.
 incr = (yield) # this line is equivalent to (lambda (incr)...
 n += incr  # equivalent to (set! ...)
 yield n# equivalent to n; this yield always returns None

 >>> s = accum(0)
 >>> s(1)
1
 >>> s(5)
6

Everything before the first (yield) is equivalent to the closed values 
between "(define (accum n)" and "(lambda" (for this example there's 
nothing there; I guess a more interesting example would have closed 
variables that were written to that were not function parameters).

-- 
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.org
___
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 342: simple example, closure alternative

[Phillip J. Eby]

At 02:10 PM 8/25/2005 -0500, Ian Bicking wrote:
>I was trying to translate a pattern that uses closures in a language
>like Scheme (where closed values can be written to) to generators using
>PEP 342, but I'm not clear exactly how it works; the examples in the PEP
>have different motivations.  Since I can't actually run these examples,
>perhaps someone could confirm or debug these:
>
>A closure based accumulator (using Scheme):
>
>(define (accum n)
>   (lambda (incr)
>(set! n (+ n incr))
>n))
>(define s (accum 0))
>(s 1) ; -> 1 == 0+1
>(s 5) ; -> 6 == 1+5
>
>So I thought the generator version might look like:
>
>def accum(n):
>  while 1:
>  incr = (yield n) or 0
>  n += incr
>
>  >>> s = accum(0)
>  >>> s.next()

The initial next() will yield 0, not None.

>  >>> s.send(1)
>0

1

>  >>> s.send(5)
>1

6

>  >>> s.send(1)
>6

7


>Is the order of the output correct?  Is there a better way to write
>accum, that makes it feel more like the closure-based version?
>
>Is this for loop correct?
>
>  >>> s = accum(0)
>  >>> for i in s:
>... if i >= 10: break
>... print i,
>... assert s.send(2) == i
>0 2 4 6 8

The assert will fail on the first pass.  s.send(2) will == i+2, e.g.:

 >>> s = accum(0)
 >>> for i in s:
... if i>=10: break
... print i,
... assert s.send(2) == i+2
...
0 2 4 6 8


___
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 342: simple example, closure alternative

[Ian Bicking]

Phillip J. Eby wrote:
> At 02:10 PM 8/25/2005 -0500, Ian Bicking wrote:
> 
>>I was trying to translate a pattern that uses closures in a language
>>like Scheme (where closed values can be written to) to generators using
>>PEP 342, but I'm not clear exactly how it works; the examples in the PEP
>>have different motivations.  Since I can't actually run these examples,
>>perhaps someone could confirm or debug these:
>>
>>A closure based accumulator (using Scheme):
>>
>>(define (accum n)
>>  (lambda (incr)
>>   (set! n (+ n incr))
>>   n))
>>(define s (accum 0))
>>(s 1) ; -> 1 == 0+1
>>(s 5) ; -> 6 == 1+5
>>
>>So I thought the generator version might look like:
>>
>>def accum(n):
>> while 1:
>> incr = (yield n) or 0
>> n += incr

Bah, I don't know why this had me so confused.  Well, I kind of know 
why.  So maybe this example would be better written:

def accum(n):
 incr = yield   # wait to get the first incr to be sent in
 while 1:
 n += incr
 incr = yield n # return the new value, wait for next incr

This way it is more explicit all around -- the first call to .next() is 
just setup, kind of like __init__ in an object, except it has to be 
explicitly invoked.
-- 
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.org
___
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] Bare except clauses in PEP 348

[skip]

Guido> It's never too early to start deprecating a feature we know will
Guido> disappear in 3.0.

Though if it's a widely used feature the troops will be highly annoyed by
all the deprecation warnings.  (Or does deprecation not coincide with
emitting warnings?)

Skip

___
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] Style for raising exceptions (python-dev Summary for 2005-08-01 through 2005-08-15 [draft])

[skip]

MAL> I must have missed this one:

That's because it was brief and to the point, so the discussion lasted for
maybe three messages.  Also, someone told us you were on holiday so we
thought we could squeak it through without you noticing.  Darn those
Aussies.  Late on the pydev summary again! 

>> 
>> Style for raising exceptions
>> 
>> 
>> Guido explained that these days exceptions should always be raised as::
>> 
>> raise SomeException("some argument")
>> 
>> instead of::
>> 
>> raise SomeException, "some argument"
>> 
>> The second will go away in Python 3.0, and is only present now for
>> backwards compatibility.  (It was necessary when strings could be
>> exceptions, in order to pass both the exception "type" and message.)
>> PEPs 8_ and 3000_ were accordingly updated.

I do have a followup question on the style thing.  (I'll leave others to
answer MAL's question about optimization.)  If I want to raise an exception
without an argument, which of the following is the proper form?

raise ValueError
raise ValueError()

Skip
___
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] Style for raising exceptions (python-dev Summary for 2005-08-01 through 2005-08-15 [draft])

[Guido van Rossum]

On 8/25/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I do have a followup question on the style thing.  (I'll leave others to
> answer MAL's question about optimization.)  If I want to raise an exception
> without an argument, which of the following is the proper form?
> 
> raise ValueError
> raise ValueError()

The latter.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Bare except clauses in PEP 348

[Guido van Rossum]

On 8/25/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 
> Guido> It's never too early to start deprecating a feature we know will
> Guido> disappear in 3.0.
> 
> Though if it's a widely used feature the troops will be highly annoyed by
> all the deprecation warnings. (Or does deprecation not coincide with
> emitting warnings?)

See Michael Chermside's post.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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 342: simple example, closure alternative

[Andrew Koenig]

> A closure based accumulator (using Scheme):
> 
> (define (accum n)
>   (lambda (incr)
>(set! n (+ n incr))
>n))
> (define s (accum 0))
> (s 1) ; -> 1 == 0+1
> (s 5) ; -> 6 == 1+5
> 
> So I thought the generator version might look like:
> 
> def accum(n):
>  while 1:
>  incr = (yield n) or 0
>  n += incr

Maybe I'm missing something but this example seems needlessly tricky to me.
How about doing it this way?

def accum(n):
acc = [n]
def f(incr):
acc[0] += incr
return acc[0]
return f

Here, the [0] turns "read-only" access into write access to a list element.
The list itself isn't written; only its element is.



___
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 342: simple example, closure alternative

[Ian Bicking]

Andrew Koenig wrote:
>>A closure based accumulator (using Scheme):
>>
>>(define (accum n)
>>  (lambda (incr)
>>   (set! n (+ n incr))
>>   n))
>>(define s (accum 0))
>>(s 1) ; -> 1 == 0+1
>>(s 5) ; -> 6 == 1+5
>>
>>So I thought the generator version might look like:
>>
>>def accum(n):
>> while 1:
>> incr = (yield n) or 0
>> n += incr
> 
> 
> Maybe I'm missing something but this example seems needlessly tricky to me.
> How about doing it this way?
> 
>   def accum(n):
>   acc = [n]
>   def f(incr):
>   acc[0] += incr
>   return acc[0]
>   return f
> 
> Here, the [0] turns "read-only" access into write access to a list element.
> The list itself isn't written; only its element is.

I was just exploring how it could be done with coroutines.  But also 
because using lists as pointers isn't that elegant, and isn't something 
I'd encourage people do to coming from other languages (where closures 
are used more heavily).

More generally, I've been doing some language comparisons, and I don't 
like literal but non-idiomatic translations of programming patterns.  So 
I'm considering better ways to translate some of the same use cases.

-- 
Ian Bicking  /  [EMAIL PROTECTED]  / http://blog.ianbicking.org
___
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] Bare except clauses in PEP 348

[Brett Cannon]

The PEP has been rejected.

-Brett

On 8/25/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/25/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> 
> > I wish Fredrik would chime in.  He would
> > have something pithy, angry, and incisive to say about this.
> 
> Raymond, I'm sick of the abuse. Consider the PEP rejected.
> 
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> ___
> 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/brett%40python.org
>
___
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