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

[James Y Knight]

On Aug 9, 2005, at 7:15 PM, Raymond Hettinger wrote:
> The data gathered by Jack and Steven's research indicate that the  
> number
> of cases where TerminatingException would be useful is ZERO.  Try  
> not to
> introduce a new builtin that no one will ever use.  Try not to add  
> a new
> word whose only function is to replace a two-word tuple (TOOWTDI).   
> Try
> not to unnecessarily nest the tree (FITBN).  Try not to propose
> solutions to problems that don't exist (PBP).

I disagree. TerminatingException is useful. For the immediate future,  
I'd like to be able to write code like this (I'm assuming that  
"except:" means what it means now, because changing that for Py2.5  
would be insane):
   try:
 TerminatingException
   except NameError:
 # compatibility with python < 2.5
 TerminatingException = (KeyboardInterrupt, SystemExit)

   try:
 foo
   except TerminatingException:
 raise
   except:
 print "error message"

What this gets me:
  1) easy backwards compatibility with earlier pythons which still  
have KeyboardInterrupt and SystemExit under Exception and don't  
provide TerminatingException
  2) I still catch string exceptions, in case anyone raises one
  3) Forward compatibility with pythons that add more types of  
terminating exceptions.

James
___
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] Exception Reorg PEP revised yet again

[James Y Knight]

On Aug 10, 2005, at 7:45 PM, Raymond Hettinger wrote:

>>> Then I don't follow what you mean by "moved under os".
>>>
>>
>> In other words, to get the exception, do ``from os import
>> WindowsError``.  Unfortunately we don't have a generic win module to
>> put it under.  Maybe in the platform module instead?
>>
>
> -1 on either.  The WindowsError exception needs to in the main  
> exception
> tree.  It occurs in too many different modules and applications.  That
> is a good reason for being in the main tree.
>
> If the name bugs you, I would support renaming it to PlatformError or
> somesuch.  That would make it free for use with Mac errors and Linux
> errors.  Also, it wouldn't tie a language feature to the name of an MS
> product.

WindowsError is an important distinction because its error codes are  
to be interepreted as being from Microsoft's windows error code list.  
That is a useful meaning. PlatformError is completely meaningless.  
Whether or not Python should really be raising errors with error  
numbers from the MS error number list instead of translating them to  
standard error codes is another issue...but as long as it does so, it  
should do so using WindowsError.

James
___
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] Exception Reorg PEP revised yet again

[James Y Knight]

On Aug 11, 2005, at 2:41 PM, Josiah Carlson wrote:
> Remember, the Exception reorganization is for Python 3.0/3k/whatever,
> not for 2.5 .

Huh, I could *swear* we were talking about fixing things for  
2.5...but I see at least the current version of the PEP says it's  
talking about 3.0. If that's true, this is hardly worth discussing as  
3.0 is never going to happen anyways.

And here I was hoping this was an actual proposal. Ah well, then.

James
___
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] [Python-checkins] python/dist/src/Objects setobject.c, 1.45, 1.46

[Jim Jewett]

(1)  Is there a reason that you never shrink sets for discard/remove/pop?  

(set difference will do a one-time shrink, if there are enough dummy
entries, but even then, it doesn't look at the %filled, so a
merge-related overallocation will stick around)

I note the you do the same with dicts, but I think sets are a more
natural candidate for "this is the set of things I still have to
process, in any order".  (I suppose enforcing an order with deque may
be faster -- unless I'm worried about duplicates.)

(2)  When adding an element, you check that 

if (!(so->used > n_used && so->fill*3 >= (so->mask+1)*2))

Is there any reason to use that +1?  Without it, resizes will happen
element sooner, but probably not much more often -- and you could
avoid an add on every insert.
(I suppose dictionaries have the same question.)

(3)  In set_merge, when finding the new size, you use (so->fill + other->used)

Why so->fill?  If it is different from so->used, then the extras are
dummy entries that it would be good to replace.

(I note that dictobject does use ->used.)

-jJ
___
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] Exception Reorg PEP revised yet again

[Brett Cannon]

On 8/11/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Aug 11, 2005, at 2:41 PM, Josiah Carlson wrote:
> > Remember, the Exception reorganization is for Python 3.0/3k/whatever,
> > not for 2.5 .
> 
> Huh, I could *swear* we were talking about fixing things for
> 2.5...but I see at least the current version of the PEP says it's
> talking about 3.0. If that's true, this is hardly worth discussing as
> 3.0 is never going to happen anyways.
> 

And why do you think it will never happen?  Guido has already said
publicly multiple times that the 2.x branch will not go past 2.9, so
unless Python goes stale there will be a 3.0 release.  Python 3.0
might not be around the corner, but will come eventually and this
stuff needs to get done at some point.

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

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

[Guido van Rossum]

On 8/11/05, James Y Knight <[EMAIL PROTECTED]> wrote:
>  If that's true, this is hardly worth discussing as
> 3.0 is never going to happen anyways.

You are wrong. So wrong.

-- 
--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] [Python-checkins] python/dist/src/Objectssetobject.c, 1.45, 1.46

[Raymond Hettinger]

[Jim Jewett]
> (1)  Is there a reason that you never shrink sets for
discard/remove/pop?

Yes, to avoid adding an O(n) step to what would otherwise be an O(1)
operation.  These tight, granular methods are so fast that even checking
for potential resizes would impact their performance.

Also, I was keeping the dict philosophy of shrinking only when an item
is added.  That approach prevents thrashing in the face of a series of
alternating add/pop operations.

OTOH, practicality beats purity.  Set differencing demands some
downsizing code (see below).



> (set difference will do a one-time shrink, if there are enough dummy
> entries, but even then, it doesn't look at the %filled, so a
> merge-related overallocation will stick around)
> 
> I note the you do the same with dicts, but I think sets are a more
> natural candidate for "this is the set of things I still have to
> process, in any order".  (I suppose enforcing an order with deque may
> be faster -- unless I'm worried about duplicates.)

It is all about balancing trade-offs.  Dummies have very little impact
on iteration speed, it is the used/(mask+1) sparseness ratio that
matters.  Also, they have very little impact on lookup time unless the
table is nearly full (and it affects not-found searches more than
successful searches).  Resizing is not a cheap operation.  The right
balance is very likely application dependent.  For now, my goal is to
deviate from dict code only for clear improvements (i.e. lookups based
on entry rather than just the key).



> (2)  When adding an element, you check that
> 
> if (!(so->used > n_used && so->fill*3 >= (so->mask+1)*2))
> 
> Is there any reason to use that +1?  Without it, resizes will happen
> element sooner, but probably not much more often -- and you could
> avoid an add on every insert.
> (I suppose dictionaries have the same question.)

Without the +1, small dicts and sets could only hold four entries
instead of five (which has shown itself to be a better cutoff point).

Even if this didn't apply to sets, I still aspire to keep true to
dictobject.c.  That code has been thoroughly tested and tuned.  By
starting with mature code, I've saved years of evolution.  Also, there
is a maintenance benefit -- developers familiar with dictobject.c will
find setobject.c to be instantly recognizable.  There is only one new
trick, set_swap_bodies(), and that is thoroughly commented.




 
> (3)  In set_merge, when finding the new size, you use (so->fill +
other-
> >used)
> 
> Why so->fill?  If it is different from so->used, then the extras are
> dummy entries that it would be good to replace.
> (I note that dictobject does use ->used.)

The cop-out answer is that this is what is done in PyDict_Merge().

I believe the reasoning behind that design was to provide the best guess
as to the maximum amount of space that could be consumed by the
impending insertions.  If they will all fit, then resizing is skipped.
The approach reflects a design that values avoiding resizes more than it
values eliminating dummy entries.  AFAICT, dummy elimination is a
by-product of resizing rather than its goal.

With sets, I followed that design except for set differencing.  In
dictionaries, there is no parallel operation of mass deletion.  I had to
put in some control so that s-=t wouldn't leave a giant set with only a
handful of non-dummy entries.  This reflects the space saving goal for
the Py2.5 updates.  There was also a goal to eliminate redundant calls
to PyObject_Hash().  The nice performance improvement was an unexpected
bonus.



Your questions are good.  Thanks for reading the code and thinking about
it.  Hope you enjoy the new implementation which for the first time can
outperform dicts in terms of both space and speed.



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] Exception Reorg PEP revised yet again

[Raymond Hettinger]

[James Y Knight]
> Huh, I could *swear* we were talking about fixing things for
> 2.5...but I see at least the current version of the PEP says it's
> talking about 3.0. If that's true, this is hardly worth discussing as
> 3.0 is never going to happen anyways.
> 
> And here I was hoping this was an actual proposal. Ah well, then.

Whenever a 3.0 aimpoint is agreed upon, as much as possible will be
introduced before then (pretty much everything that doesn't break code).

Ideally, the final step to 3.0 will consist primary of dropping obsolete
things that had been kept only for backwards compatibility.



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

[Python-Dev] plans for 2.4.2 and 2.5a1

[Anthony Baxter]

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

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

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
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] pdb: should next command be extended?

[Anthony Baxter]

On Monday 08 August 2005 20:13, Ilya Sandler wrote:
> > At OSCON, Anthony Baxter made the point that pdb is currently one of the
> > more unPythonic modules.
>
> What is unpythonic about pdb? Is this part of Anthony's presentation
> online? (Google found a summary and slides from presentation but they
> don't say anything about pdb's deficiencies)

It was a lightning talk, I'll put the slides up somewhere at some point.
My experience with pdb is that it's more or less impossible to extend or
subclass it in any way, and the code is pretty nasty. In addition, pretty
much everyone I asked "which modules in the std lib need to be seriously 
fixed" listed pdb first (and sometimes first, second and third). 

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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: Migrating the Python CVS to Subversion

[Anthony Baxter]

On Sunday 07 August 2005 15:33, Martin v. Löwis wrote:
> Ah, ok. That's true. It doesn't mean you can't do proper merging
> with subversion - it only means that it is harder, as you need to
> figure out the revision range that you want to merge.
>
> If this is too painful, you can probably use subversion to store
> the relevant information. For example, you could define a custom
> property on the directory, last_merge_from_trunk, which you
> would always update after you have done a merge operation. Then
> you don't have to look through history to find out when you
> last merged.

This is what I do with shtoom - I have properties branchURI and branchRev on 
the root of the branch. I can then use these when landing the branch. It 
seems to work well enough for me. 

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] pdb: should next command be extended?

[Bob Ippolito]

On Aug 11, 2005, at 3:02 PM, Anthony Baxter wrote:

> On Monday 08 August 2005 20:13, Ilya Sandler wrote:
>
>>> At OSCON, Anthony Baxter made the point that pdb is currently one  
>>> of the
>>> more unPythonic modules.
>>>
>>
>> What is unpythonic about pdb? Is this part of Anthony's presentation
>> online? (Google found a summary and slides from presentation but they
>> don't say anything about pdb's deficiencies)
>>
>
> It was a lightning talk, I'll put the slides up somewhere at some  
> point.
> My experience with pdb is that it's more or less impossible to  
> extend or
> subclass it in any way, and the code is pretty nasty. In addition,  
> pretty
> much everyone I asked "which modules in the std lib need to be  
> seriously
> fixed" listed pdb first (and sometimes first, second and third).

One thing PDB needs is a mode that runs as a background thread and  
opens up a socket so that another Python process can talk to it, for  
embedded/remote/GUI debugging.  This is what IDLE, Wing, and WinPDB  
(haven't tried it yet ) do.

Unfortunately, most of the other Python IDE's run interpreters and  
debuggers in-process, so it makes them unsuitable for developing GUI  
and embedded apps and opens you up for crashing the IDE as well as  
whatever code you're trying to fix.

-bob

___
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