Re: [Python-Dev] Python 3000 Process

[Brett Cannon]

On 3/19/06, Christian Tismer <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> ...
>
> > Please don't respond with answers to these questions -- each of them
> > is worth several threads. Instead, ponder them, and respond with a +1
> > or -1 on the creation of the python-3000 mailing list. We'll start
> > discussing the issues there -- or here, if the general sense is not to
> > split the list.
>
> I think this list has grown already too much activity, so I'd
> appreciate a split.
>
> +1  -- chris

+1 (maybe even with top-posting being acceptable on the list!  =) .

-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] PySet API

[Raymond Hettinger]

[Raymond]
>> What are you proposing to add to the PySet API?

[Barry]
> PySet_Clear(), PySet_Next(), PySet_Update(), and PySet_AsList().

PySet_Clear()
-
Use PyObject_CallMethod(s, "clear", NULL).

Or if you need to save a millisecond on an O(n) operation, use 
PyNumber_InPlaceSubtract(s,s) as shown in the docs.  If the name bugs you, it 
only takes a one-line macro to define a wrapper.  The set API should not be 
cluttered with unnecessary and redundant functions.


PySet_Next()

This is also redundant.  The preferred way to iterate over a set should be 
PyObject_GetIter(s).  The iter api is generic and works for all containers.  It 
ought to be the one-way-to-do-it.

Further, it doesn't make sense to model this after the dictionary API where the 
next function is needed to avoid double lookups by returning pointers to both 
the key and value fields at the same time (allowing for modification of the 
value field).  In contrast, for sets, there is no value field to look-up or 
mutate (the key should not be touched).  So, we shouldn't be passing around 
pointers to the internal structure. I want to keep the internal structure of 
sets much more private than they were for dictionaries -- all access should be 
through the provided C API functions -- that keeps the implementation flexible 
and allows for future improvements without worrying that we've broken code for 
someone who has touched the internal structure directly.

Also, the _Next() api is not as safe as the _GetIter api which checks for 
mutation during iteration.  The safety should not be tossed aside without good 
reason.


PySet_Update()
---
Use PyObject_CallMethod(s, "update", "O", iterable).  That is the preferred way 
to access all of the high volume methods.  Only the fine grained methods (like 
contains, add, pop, or discard) have a need for a direct call.  Adding 
unnecessary functions for the many-at-once methods gains you nothing -- perhaps 
saving a tiny O(1) look-up step in an O(n) operation.

FWIW, the same reasoning also applies to why the list API defines 
PyList_Append() but not PyList_Extend().


PySet_AsList()
---
There is already a function expressly for this purpose, PySequence_List(s).  It 
is clear, readable, and is the one-way-to-do-it for turning arbitrary iterables 
into a list.  FWIW, that function already has an optimization to pre-size the 
result list to the correct size, so it runs pretty fast (no over-allocate / 
resize dance).

I had considered putting a further optimization inside PySequence_List to have 
a 
special case path for sets (like it does for tuples); however, it occurred to 
me 
that this can never be the time critical part of a program since the time to 
convert a set to a list is small compared to the time to construct the set in 
the first place (many times longer).  IOW, further micro-optimization here is 
pointless.




[Raymond]
>> IOW, if I have I still have a say in the matter, the patch will most likely 
>> not
>> be accepted.

[Barry]
> Can you explain why the additions above would not be obvious improvements?

Yes.  A fatter api is not a better api.  The PyObject_CallMethod() approach is 
highly readable and assures direct correspondence with a Python set method of 
the same name.  Trying to save the method name lookup time on O(n) methods is a 
false optimization.  The concrete API should avoid duplicating services 
provided 
by the abstract API such as PySequence_List().  Also, the set API should not 
model parts of the dict API that grant direct access to the internal structure 
or were needed because dictionaries had a value field.

As it stands now, it is possible to use sets in C programs and access them in a 
way that has a direct correspondence to pure Python code -- using 
PyObject_CallMethod() for things we would usually access by name, using the 
PyNumber API for things we would access using operators, using other parts of 
the abstract API exactly as we would in Python (PyObject_Repr, 
PyObject_GetIter, 
PySequence_List, PyObject_Print, etc.), and using a handful of direct access 
functions for the fine grained methods like (add, pop, contains, etc.).  IOW, I 
like the way the C code looks now and I like the minimal, yet complete API. 
Let's don't muck it up.

FWIW, the C implementation in Py2.5 already provides nice speed-ups for many 
operations.  Likewise, its memory requirements have been reduced by a third. 
Try to enjoy the improvements without gilding the lily.

Cheers,


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] GeneratorExit inheriting from Exception

[Raymond Hettinger]

[Guido]
> Sigh. Enough already. PEP 352 was chosen to minimize incompatibilities
> and maximize gain with minimal changes in the tree. Also note that
> Warnings can sometimes be raised and should then treated as errors, so
> Warning would have to inherit from Error.
>
> I vote for the status quo in HEAD, except I've got to think more about
> the pros and cons of making GeneratorExit as special as
> KeyboardInterrupt.

While Guido is thinking, could one of the proponents please enumerate the 
reasons for treating GeneratorExit like KeyboardInterrupt and SystemExit.

To me, they obviously should be under Exception, and not treated like 
KeyboardInterrupt or SystemExit, so that probably means that I'm missing 
something about GeneratorExit.


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] GeneratorExit inheriting from Exception

[Nick Coghlan]

Raymond Hettinger wrote:
> While Guido is thinking, could one of the proponents please enumerate the 
> reasons for treating GeneratorExit like KeyboardInterrupt and SystemExit.
> 
> To me, they obviously should be under Exception, and not treated like 
> KeyboardInterrupt or SystemExit, so that probably means that I'm missing 
> something about GeneratorExit.

If GeneratorExit *isn't* special, then correct catch-all exception handling 
around a yield expression in a generator looks like:

   def run_tasks(tasks, failed_tasks)
   for task in tasks:
   try:
   yield task()
   except GeneratorExit:  # don't break gen.close()
   raise
   except Exception:
   failed_tasks.append((task, sys.exc_info()))


Having to explicitly reraise a terminating exception like that is the exact 
idiom we're trying to get rid of for SystemExit and KeyboardInterrupt, so it 
makes sense to me to avoid it for GeneratorExit as well.

Given that the default system-level excepthook *won't* ignore GeneratorExit 
(and so an error message will still be printed), I see moving it out with the 
other two terminating exceptions as the best option. The only way for that 
approach to do the wrong thing is if GeneratorExit is raised outside a 
generator's pseudothread, at which point I'd be blaming the code that raised 
it explicitly (the interpreter core only ever raises it as a result of a call 
to gen.close()).

Note that this argument does *not* apply to StopIteration - that should stay 
under Exception because it should never accidentally leak beyond the code that 
is calling the next() method.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.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

[Python-Dev] release24-maint FREEZE for 2.4.3c1, this Thursday

[Anthony Baxter]

I'd like to freeze the release24-maint branch for 2.4.3c1 this 
Thursday 23rd March from  UTC. I'll post a note once that's done, 
but as usual, please please only check in critical fixes in the week 
between 2.4.3c1 and 2.4.3 (which will follow next week). 

Please let me know if you have any issues with this. Should I also put 
this sort of information somewhere on the web? Maybe a slot at the 
top of the buildbot page?

Thanks,
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] Python 3000 Process

[Nick Coghlan]

Guido van Rossum wrote:
> I see increased activity related to Python 3000. This is great, but
> there is some danger involved. Some of the dangers are: overloading
> developers; setting unrealistic expectations for what can be
> accomplished; scaring the more conservative user community; paralyzing
> developers who can't decide whether to wait for Python 3000 or not.
> 
> I'd like to address all these issues, but it may be better to first
> spend some time on creating a more streamlined process. Perhaps it's
> finally time to introduce a separate mailing list? If people agree,
> let's call it [EMAIL PROTECTED] For many developers this won't
> make much of a difference (since they'll subscribe to both lists), but
> it will give people who are only concerned with Python 2.x a way to
> opt-out, and perhaps more importantly, it will make it clear whether
> any particular proposal is intended for Python 3000 or for Python 2.x.

+1 on the separate mailing list (and PEP numbers).

If Barry (or another mailing list admin) is feeling energetic, some 
branch-specific topics on python-checkins would be nice, too. While I'm 
interested in tracking trunk checkins, I'm not so concerned about the exact 
details of what's happening on the p3yk branch.

Regards,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.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] Long-time shy failure in test_socket_ssl

[Nick Coghlan]

Neal Norwitz wrote:
> On 3/19/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>>> If anyone sees spurious failures with the buildbot (one time failures,
>>> crashes, etc), please report the problems to python-dev.  It would be
>>> great to see if you can reproduce the results with the same tests that
>>> failed.  We need to determine if it is architecture specific,
>>> test-order related, or something else.
>> One-shot segfaults are still common enough on the Mac box, like the very 
>> recent:
>> 
> 
> Most of the recent failures seem to be related to threads.  the most
> recent info is below.  There's a lot more in case if it can help
> someone debug.  It seems that one thread is in pthread_cond_wait and
> another thread is in PyObject_Call.

Hrrm, test_thread_state hands an object pointer off to a different thread 
without INCREF'ing it first. Could there be a race condition with the 
deallocation of arguments at the end of test_thread_state?

Specifically, that trace looks to me like the spawned thread is trying to call 
the function passed in while the main thread is trying to delete the argument 
tuple passed to test_thread_state.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.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] Python 3000 Process

[BJörn Lindqvist]

> Please don't respond with answers to these questions -- each of them
> is worth several threads. Instead, ponder them, and respond with a +1
> or -1 on the creation of the python-3000 mailing list. We'll start
> discussing the issues there -- or here, if the general sense is not to
> split the list.

-0 on separate mailing list and PEP numbers.

Because to much separation between python 2.x and python 3.x makes 3.x
seem more like vaporware that will never happen (Perl 6). I would have
hoped that the transition to 3.x would be evolutionary in small steps;
removal of string exceptions in one major release, replacement of
print with a function in the next and so on. A total redesign from
bottom up in one release has a very high probability of "failing"
IMHO. Or at least very annoying for end users that who to deal with
two parallel and incompatible versions. The reality is that
discussions about python 3000 has a high probability of being a total
waste of time. I think all those of us who have for lengths argued
whether lambda should stay or be dropped knows that. :)

--
mvh Björn
___
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 3000 Process

[Matthew Fleming]

On 20/03/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
+1 on the separate mailing list (and PEP numbers).If Barry (or another mailing list admin) is feeling energetic, somebranch-specific topics on python-checkins would be nice, too. While I'minterested in tracking trunk checkins, I'm not so concerned about the exact
details of what's happening on the p3yk branch.+1 for the separate mailing list.Reading anything from 50 to 100 emails first thing every morning, I need all the help I can get trying to distinguish different topics.
Also, as Nick said, a separate mailing list for p3yk check-ins would be nice but naturally, only if someone has the time to maintain it.Thanks,Matt
___
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] Py3k: Except clause syntax

[skip]

Skip> There seem to be other places where Python is beginning to require
Skip> parens even though they aren't strictly necessary to resolve
Skip> syntactic ambiguity.

Guido> In the style guide only, I hope.

Alex> Technically, I believe the first place where this did not apply
Alex> was list comprehensions, ...

This was the instance I was thinking of, but it was far enough back that I
didn't remember if it was for readability or disambiguation.

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] Python 3000 Process

[Thomas Wouters]

On 3/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
Please don't respond with answers to these questions -- each of themis worth several threads. Instead, ponder them, and respond with a +1or -1 on the creation of the python-3000 mailing list. We'll startdiscussing the issues there -- or here, if the general sense is not to
split the list.Definately very +1 on a python-3000 list.-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
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] Bug Day on Friday, 31st of March

[Georg Brandl]

Hello,

it's time for the 7th Python Bug Day. The aim of the bug day is to close
as many bugs, patches and feature requests as possible, this time with a
special focus on new features that can still go into the upcoming 2.5 alpha
release.

When?
^

The bug day will take place on Friday, March 31st, running from
1PM to 7PM GMT (9AM to 3PM Eastern time). You don't need to be around all day;
feel free to stop by for a few hours and contribute.

Where and How?
^^

To join, stop by the IRC channel #python-dev on irc.freenode.net, where
efforts will be discussed and coordinated. We'll collaboratively go through
the Python bug database at SourceForge and fix things as they come up.

IMPORTANT: *No* prior knowledge of the Python source is necessary to
participate! You'll get all assistance the developers can offer for starting
up with helping, this is in fact a good opportunity to learn the basics.

Bug day participation helps the developers and makes Python 2.5 a better
release by reducing the backlog of bugs and patches.  Plus, it's fun!

More information


For instructions and more information, see the Wiki page at
http://www.python.org/cgi-bin/moinmoin/PythonBugDay


Cheers,
Georg

___
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 3000 Process

[Barry Warsaw]

On Mon, 2006-03-20 at 19:27 +1000, Nick Coghlan wrote:

> +1 on the separate mailing list (and PEP numbers).

I'm neutral on whether a new mailing list should be added, but +1 on
separate PEP numbers.

> If Barry (or another mailing list admin) is feeling energetic, some 
> branch-specific topics on python-checkins would be nice, too. While I'm 
> interested in tracking trunk checkins, I'm not so concerned about the exact 
> details of what's happening on the p3yk branch.

If we agree on adding a separate discussion list, then I think we should
have a separate checkins list.  Plumbing that through the subversion
machinery shouldn't be too hard.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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 2.5 Schedule

[Barry Warsaw]

On Sun, 2006-03-19 at 20:40 -0800, Guido van Rossum wrote:

> I'm -0 for changing this in 3.0; a larger-scale reorganization could
> be undertaken but it's not a big priority.
> 
> Before you spend more energy on this, I'd like to address the process
> for Python 3000, which is too chaotic right now. See my new thread
> titled "Python 3000 Process".

Fair enough.
-Barry



signature.asc
Description: This is a digitally signed message part
___
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] GeneratorExit inheriting from Exception

[Barry Warsaw]

On Sat, 2006-03-18 at 15:37 -0800, Brett Cannon wrote:

> > Actually, this prompts me to write about an issue I have with PEP 352.
> > I actually don't think it's necessary (yes, I know it's already in the
> > tree).
> >
> 
> Much to personal pain and sprint time.  Are you trying to make me shed
> a manly tear, Barry?!?  =)

> So it isn't that PEP 352 is unnecessary since there is nothing here
> about deprecating string execptions and making built-in exceptions
> new-style.  You just want to change the renaming of the exceptions.

Yes, sorry Brett!  No the other things about PEP 352 are all good, and I
was only commenting about the new hierarchy changes.  I still don't like
that part of the PEP, but I appreciate the competing compromises being
made so I can live with it for Python 2.x.

> I still like my idea of a ControlFlowException, but that died with PEP
> 348 (along with part of my innocence).

Good!  The sooner you replace that with soul-crushing defeatism the
happier you will be!

> Just remember that PEP 348 was meant for Py3K when we are supposed to
> break stuff and how much resistence I hit.  Granted my changes were
> more radical, but even in the end, small changes were resisted
> heavily.  In other words, make sure you have the time and energy to
> take this on.  =)

I know all about soul-crushing PEP championship, which is why I'm such a
happy person. :)

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] GeneratorExit inheriting from Exception

[Barry Warsaw]

On Sun, 2006-03-19 at 13:49 +1200, Greg Ewing wrote:
> Barry Warsaw wrote:
> 
> > Exception
> > +- KeyboardInterrupt
> > +- GeneratorExit
> > +- SystemExit
> > +- StopIteration
> > +- Error
> > |  +- ImportError
> > |  +- (etc.)
> > |
> > +- Warning
> >+- UserWarning
> >+- (etc.)
> 
> +42! This is beautifully clear and simple, especially
> compared to some of the other exception hierarchy
> reorganisations that have been proposed.

I still believe in this, and I'm thankful for the support I've seen.  It
won't happen for Python 2.x, but I do plan on addressing this for Py3K.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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 3000 Process

[Guido van Rossum]

On 3/20/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> -0 on separate mailing list and PEP numbers.

You seem to be the minority so far...

> Because to much separation between python 2.x and python 3.x makes 3.x
> seem more like vaporware that will never happen (Perl 6).

I'm actually trying to reenergize things to make sure Python 3000 *will* happen.

> I would have
> hoped that the transition to 3.x would be evolutionary in small steps;
> removal of string exceptions in one major release, replacement of
> print with a function in the next and so on.

To the extent possible that's certainly the plan. But there are
certain changes that are too hard to do without introducing a major
incompatibility -- you can't add warnings for everything, especially
not where the semantics of an existing API changes (e.g. range(), or
dict.keys(), or int/int). Future statements don't help for some of
these cases either (especially not for dict.keys() and similar, since
dicts are passed between modules).

> A total redesign from
> bottom up in one release has a very high probability of "failing"
> IMHO.

There's not going to be a total redesign. This is exactly the kind of
misunderstanding that I would like to address by specifying a process
for getting there rather than just starting to discuss features. 3.0
will be the opportunity to radically clean up mistakes I made 16 years
ago, by allowing the language to change backwards incompatibly. It is
*not* intended to be as an invitation to start adding random new
ideas. (In fact, there's something to say for *limiting* Python 3000
to the incompatibilities, and to continue introducing new ideas in
2.x, as long as they don't require incompatibilities beyond the
occasional new keyword, which can be handled with a warning and a
future statement. But that's for the Python 3000 process to be
decided.)

> Or at least very annoying for end users that who to deal with
> two parallel and incompatible versions.

Well that can't be helped, really, unless you want to keep the
language backwards compatible forever, can it? Some necessary changes
*are* incompatible, so they are going to cause some pain during the
transition. The alternative would be years and years of pain as
various changes are introduced in different versions (if we did it all
at once it would *be* Python 3.0 of course :-). Python 3000 hopes to
ease the pain by making it all happen at once (ripping the band-aid
off quickly, so to speak :-) while at the same time giving users a
chance to decide *when* to do it -- since (in my vision, anyway) there
will be a fair amount of maintenance applied to the 2.x branch even
after 3.0 has been released.

> The reality is that
> discussions about python 3000 has a high probability of being a total
> waste of time. I think all those of us who have for lengths argued
> whether lambda should stay or be dropped knows that. :)

Now that sounds like an insult. I hope you didn't mean it that way.

Discussing Python 3000 will *not* be a waste of time. I fully intend
to carry through the changes and release Python 3.0 as I have
envisioned it for a long time. If anything's a waste of time, it's
discussing random Python 3000 proposals without having a good process
in place first. That's what I want to change right now.

Barry, if you could create that mailing list, please?

--
--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] GeneratorExit inheriting from Exception

[Barry Warsaw]

On Sun, 2006-03-19 at 17:31 +1000, Nick Coghlan wrote:

> With PEP 352 (tweaked to move GeneratorExit out from under Exception):
>- "except:" continues to mean catch everything
>- "except Exception:" now does the right thing
>- inheriting from Exception continues to be correct for user exceptions
>- errors may choose to inherit from one of the existing Errors instead
> 
> With Barry's proposed hierarchy:
>- "except:" continues to mean catch everything
>- "except Exception:" continues to do the wrong thing
>- all code has to change to do "except Error:" instead
>- inheriting from Exception becomes incorrect for user exceptions
>- all code has to change to inherit from Error instead
>- non-error user exceptions (such as completion of a search using nested
>  loops) have no clear parent to inherit from (both Error and Exception
>  are wrong, albeit for different reasons.
> 
> The additional pain required in order to have 'Exception' at the root of the 
> hierarchy just isn't worth it.

One quibble.  Since the term used for the general concept of something
that is raised and caught is "exception" and since all the raise-able
objects live in a module called "exceptions", it is confusing that
"except Exception" will not catch all exceptions.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] GeneratorExit inheriting from Exception

[Barry Warsaw]

On Sun, 2006-03-19 at 19:18 -0800, Guido van Rossum wrote:

> I have a problem with using Error as the focal point since so many
> exceptions (user-defined or otherwise) aren't errors. 

I'm not sure that's totally true in practice.  I think most user-defined
exceptions are actually errors.  Ideally, StandardError would be called
Error (or there'd be an alias of that name) and people should be
deriving their error exceptions from Error.  Their non-error exceptions
would be derived from Exception.

The last thing I'll suggest in this thread for Python 2.5 is to add an
alias called Error for StandardError.  Then, users can begin to do the
sensible thing (as above).

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] GeneratorExit inheriting from Exception

[Aahz]

On Sun, Mar 19, 2006, Greg Ewing wrote:
> Barry Warsaw wrote:
>> 
>> One possible approach is to revert BaseException out of Py2.5,
>> re-position KeyboardInterrupt, and add Error as an alias for
>> StandardError.  Then we can encourage people to start using Error as the
>> base classes for their own errors.
> 
> Also maybe start issuing warnings whenever you inherit directly from
> Exception.

-1 -- I occasionally use exceptions as a multi-loop break.  That's a
perfectly valid Python practice, those exceptions should inherit from
Exception, and there should not be any warnings raised.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing."  --Alan Perlis
___
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] GeneratorExit inheriting from Exception

[Barry Warsaw]

On Mon, 2006-03-20 at 08:18 -0800, Aahz wrote:

> -1 -- I occasionally use exceptions as a multi-loop break.  That's a
> perfectly valid Python practice, those exceptions should inherit from
> Exception, and there should not be any warnings raised.

Exactly!  But they're not errors, so "except Exception" should catch
them but "except Error"  should not.  This does speak to a generic
ControlFlow (but not ControlFlowError) base class.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] buildbot failure in x86 W2k trunk

[python-dev]

The Buildbot has detected a new failure of x86 W2k trunk.
Full details are available at:
 http://www.python.org:9010/x86%20W2k%20trunk/builds/83

Buildbot URL: http://www.python.org:9010/

Build Reason: 
Build Source Stamp: [branch trunk] HEAD
Blamelist: anthony.baxter

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

___
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] buildbot failure in x86 XP-2 trunk

[python-dev]

The Buildbot has detected a new failure of x86 XP-2 trunk.
Full details are available at:
 http://www.python.org:9010/x86%20XP-2%20trunk/builds/69

Buildbot URL: http://www.python.org:9010/

Build Reason: 
Build Source Stamp: [branch trunk] HEAD
Blamelist: anthony.baxter

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

___
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] buildbot failure in x86 XP-2 trunk

[python-dev]

The Buildbot has detected a new failure of x86 XP-2 trunk.
Full details are available at:
 http://www.python.org:9010/x86%20XP-2%20trunk/builds/71

Buildbot URL: http://www.python.org:9010/

Build Reason: 
Build Source Stamp: [branch trunk] HEAD
Blamelist: anthony.baxter,neal.norwitz

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

___
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] buildbot failure in x86 W2k trunk

[python-dev]

The Buildbot has detected a new failure of x86 W2k trunk.
Full details are available at:
 http://www.python.org:9010/x86%20W2k%20trunk/builds/85

Buildbot URL: http://www.python.org:9010/

Build Reason: 
Build Source Stamp: [branch trunk] HEAD
Blamelist: anthony.baxter,neal.norwitz

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

___
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] buildbot failure in x86 XP 2.4

[python-dev]

The Buildbot has detected a new failure of x86 XP 2.4.
Full details are available at:
 http://www.python.org:9010/x86%20XP%202.4/builds/20

Buildbot URL: http://www.python.org:9010/

Build Reason: 
Build Source Stamp: [branch branches/release24-maint] HEAD
Blamelist: vinay.sajip

BUILD FAILED: failed failed slave lost

sincerely,
 -The Buildbot

___
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 3000 Process

[Terry Reedy]

"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
>Barry, if you could create that mailing list, please?

And please mirror it on gmane the same way as this list is.

Terry



___
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] Py3k: Except clause syntax

[Ron Adam]

[EMAIL PROTECTED] wrote:
> Skip> There seem to be other places where Python is beginning to require
> Skip> parens even though they aren't strictly necessary to resolve
> Skip> syntactic ambiguity.
> 
> Guido> In the style guide only, I hope.
> 
> Alex> Technically, I believe the first place where this did not apply
> Alex> was list comprehensions, ...
> 
> This was the instance I was thinking of, but it was far enough back that I
> didn't remember if it was for readability or disambiguation.

There is also the cases of types needing parens such as tuple((1,2,3)). 
   The same is true for dict, list, and sets.  They could have been 
written to accept individual items, (not a suggestion as it is slower), 
so requiring tuples, sets, and/or sequences where they are used as such 
isn't unexpected.

But as long as I can do the following I will be happy.

some_exc_group = (some_except, some_except, some_except)

try:
   ...
except excgroup as value:
   ...

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

Re: [Python-Dev] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c

[M.-A. Lemburg]

Martin v. Löwis wrote:
> Fernando Perez wrote:
>> So I think M.A. is right on the money here with his statement.  Unless you
>> consider the Linux/64bit camp insignificant.  But if that is the case, it
>> might be worth putting a big statement in the 2.5 release notes indicating
>> "there is a good chance, if you use third party extensions and a 64 bit OS,
>> that this won't work for you".  Which will mean that a fraction of the
>> scientific userbase (a big, enthusiastic and growing community of python
>> users) will have to stick to 2.4.
> 
> It's more intricate than that. If certain extensions are of interest to
> the scientific community, I certainly expect the authors of them to fix
> them.
> 
> However, to "fix" the extension can still be done in different levels:
> you can easily fix it to not crash, by just honoring all compiler
> warnings that gcc produces. That doesn't mean you fully support
> Py_ssize_t, since you might not support collections with more than
> 2**31 elements. In these cases, the extension will not crash, but it
> will compute incorrect results if you ever encounter such a collection.

Sorry Martin, but such an advice is simply not good enough.

You can't expect people to go chasing compiler warnings to
"fix" their code without at the same time giving them a
complete list of APIs that changed and which is needed for
the still required manual inspection.

I really don't understand why you put so much effort into
trying to argue that the ssize_t patch isn't going to break
extensions or that fixing compiler warnings is good enough.

The interface to the Python API should not be a compiler
giving you warnings, it should be a document where users
(extension authors) can read about the changes, check
their code using grep an editor or some other tool and then
*know* that their code works rather than relying on the
compiler warnings which only *might* catch all the cases
where breakage occurs.

Like Fernando said, 64-bit is becoming the de-facto standard
for Unix systems very quickly these days. It is becoming
hard to buy systems not supporting 64-bit and, of course,
people are anxious to use the capabilities of the systems
they bought (whether they need them or not). If you look at
the market for root servers as second example of users
of 64-bit machines next to the scientific users, several
big hosters have completely switched over to 64-bit.
You can't even get a 32-bit install of Linux on those
machines - because they use custom kernels patched for
their particular hardware.

Ignoring this is just foolish.

I consider the fact that it's currently not possible to have
a look at the changed APIs a documentation which is in the
responsibility of the patch authors to provide (just like it
always is).

Please provide such a list.

> Even on all these AMD64 Linux machines, this is still fairly unlikely,
> since you need considerably more than 16GiB main memory to do something
> useful on such collections - very few machines have that much memory
> today. Again, people that have such machines and need to run Python
> programs with that many data need to make sure that the extensions
> work for them. Sticking with 2.4 is no option for these people, since
> 2.4 doesn't support such large collections, anyway.
> 
> To really fix such extensions, I recommend building with either
> Microsoft C or Intel C. The Microsoft compiler is available free
> of charge, but runs on Windows only. It gives good warnings, and
> if you fix them all (in a careful way), your code should fully
> support 64 bits. Likewise for the Intel compiler: it is available
> for free only for a month, but it runs on Linux as well.
> 
> OTOH, I'm still doubtful how many extensions will be really affected
> by the change in the first place. Your code *breaks* with the change
> only if you implement the sequence or buffer protocols. I'm doubtful
> that this is an issue for most applications, since many extensions
> (I believe) work without implementing these protocols.

You know that it's not only the sequence and buffer protocol
that changed.

If you grep through Include, you get at these reference to
output variables which are going to cause breakage regardless
of whether you use 64-bit or not simply due to the fact that
the function is writing into memory owned by the caller:

./dictobject.h:
-- PyAPI_FUNC(int) PyDict_Next(
--  PyObject *mp, Py_ssize_t *pos, PyObject **key, PyObject **value);
./pyerrors.h:
-- PyAPI_FUNC(int) PyUnicodeEncodeError_GetStart(PyObject *, Py_ssize_t *);
-- PyAPI_FUNC(int) PyUnicodeDecodeError_GetStart(PyObject *, Py_ssize_t *);
-- PyAPI_FUNC(int) PyUnicodeTranslateError_GetStart(PyObject *,
Py_ssize_t *);
-- PyAPI_FUNC(int) PyUnicodeEncodeError_GetEnd(PyObject *, Py_ssize_t *);
-- PyAPI_FUNC(int) PyUnicodeDecodeError_GetEnd(PyObject *, Py_ssize_t *);
-- PyAPI_FUNC(int) PyUnicodeTranslateError_GetEnd(PyObject *, Py_ssize_t *);
./sliceobject.h:
-- PyAPI_FUNC(int) PySlice_GetIndices(PySliceObject *r

Re: [Python-Dev] GeneratorExit inheriting from Exception

[Michael Chermside]

Barry writes:
> I still believe in this, and I'm thankful for the support I've seen.  It
> won't happen for Python 2.x, but I do plan on addressing this for Py3K.

When you do, I'd like you to consider one change to the names. You are
proposing this:

> Exception
> +- KeyboardInterrupt
> +- GeneratorExit
> +- SystemExit
> +- StopIteration
> +- Error
> |  +- ImportError
> |  +- (etc.)
[...]

If we use that structure, I still strongly feel that what you call "Error"
ought to be named "Exception" (and what you call "Exception" should be
named "BaseException" or perhaps "Raisable"). The reason is this:

Most people coming to Python today are coming from languages more modern
than Fortran and C, and (if they have any programming background at all)
they are familiar with the idea of an exception. When chatting around the
water cooler, they probably call it "an exception", rather than "a dingus",
"one of those thingys that unwinds the stack until reaching a handler",
or even "an error". (The term "an error" is usually used around the
water cooler for any kind of mistake, whether human or programatic.) This
is encouraged in Python by the fact that the keyword for handling
exceptions in Python is "except".

But we don't want people using the dingus at the top of the hierarchy --
only a few experts who know what they're doing should care about that
one. We want them using the one that you call "Error". So by naming
that one "Exception", we take advantage of the meaning of the word, the
experience from other languages, and the keywords of the language to
encourage correct usage. Naming the top level dingus something slightly
odd is a small price to pay (although both "BaseException" and "Raisable"
seem instantly comprehensible to me).

I present Java as an example. Given it's position as the new Cobol, there
are literally hundreds of thousands of not-very-skillful Java programmers
out there. Yet it is rare to see them write "catch Throwable" when they
should use "catch Exception". That mistake is far more common among
beginning Python users. Surely we can do at least as well as Java!

-- Michael Chermside

PS: I've intentionally ignored the question Guido raised about whether
Warning belongs under your "Error" or your "Exception".

___
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] GeneratorExit inheriting from Exception

[Barry Warsaw]

On Mon, 2006-03-20 at 11:43 -0800, Michael Chermside wrote:

> When you do, I'd like you to consider one change to the names. You are
> proposing this:

I'll keep this in mind, but won't comment further here for two reasons.
I want to think about it some more (you throw, er raise some good
points ;) and I'd rather carry the discussion forward on the soon to be
announced  python-3000 mailing list.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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 3000 Process

[Barry Warsaw]

On Mon, 2006-03-20 at 13:30 -0500, Terry Reedy wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> >Barry, if you could create that mailing list, please?
> 
> And please mirror it on gmane the same way as this list is.

Subscription requests have been made.
-Barry



signature.asc
Description: This is a digitally signed message part
___
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 3000 Process

[Paul Moore]

On 3/20/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-03-20 at 13:30 -0500, Terry Reedy wrote:
> > "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> > >Barry, if you could create that mailing list, please?
> >
> > And please mirror it on gmane the same way as this list is.
>
> Subscription requests have been made.
> -Barry

I assume an appropriate signup URL/address will be announced here (and
added to the python.org site) when the list is created?

Paul.
___
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] r43041 - python/trunk/Modules/_ctypes/cfield.c

[Martin v. Löwis]

M.-A. Lemburg wrote:
> I really don't understand why you put so much effort into
> trying to argue that the ssize_t patch isn't going to break
> extensions or that fixing compiler warnings is good enough.

Well, in *this* thread, my main point is that I don't want
to provide the list that you demand, mainly because I consider
it a waste of my time to create it.

> I consider the fact that it's currently not possible to have
> a look at the changed APIs a documentation which is in the
> responsibility of the patch authors to provide (just like it
> always is).

It is possible to look at the changed APIs, see

http://docs.python.org/dev/api/sequence.html

Regards,
Martin

___
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] supported platforms OS2?

[Jim Jewett]

Is there a list of currently supported platforms?

Is OS2 still actively supported?
___
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] supported platforms OS2?

[Martin v. Löwis]

Jim Jewett wrote:
> Is there a list of currently supported platforms?

No, only a negative list: PEP 11.

> Is OS2 still actively supported?

It's not listed as unsupported. Whether it actually works, nobody
knows.

Regards,
Martin
___
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] supported platforms OS2?

[Jim Jewett]

(Sorry about the early send)

Is there a list of currently supported platforms?

Is OS2 still actively supported?

The reason I ask is that PYOS_OS2
(in Modules/posixmodule.c and Include/pyport.h)
triggers enough ifdeffery that I'm certain it missed
out on some updates, and I'm not certain it is
even still correct.  If no one is checking, should it
be added to the unsupported systems list along
with Windows 95?

-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] Documenting the ssize_t Python C API changes

[M.-A. Lemburg]

Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> I really don't understand why you put so much effort into
>> trying to argue that the ssize_t patch isn't going to break
>> extensions or that fixing compiler warnings is good enough.
> 
> Well, in *this* thread, my main point is that I don't want
> to provide the list that you demand, mainly because I consider
> it a waste of my time to create it.

It's not a waste of time at all: you'd be helping lots and
lots of developers out there who want to fix their extensions.

Apart from that I can only repeat what I said before: you
expect developers to put lots of time into fixing their
extensions to run with Python 2.5, so it's only fair that
you invest some time into making it as easy as possible for
them.

The ssize_t patch is the single most disruptive patch in
Python 2.5, so it deserves special attention.

>> I consider the fact that it's currently not possible to have
>> a look at the changed APIs a documentation which is in the
>> responsibility of the patch authors to provide (just like it
>> always is).
> 
> It is possible to look at the changed APIs, see
> 
> http://docs.python.org/dev/api/sequence.html

That's neither a complete list (see the grep I sent), nor
does it highlight the changes.

The API documentation is not the right place for the
documentation of this change, IMHO, since it always refers
to the current state in a specific Python release and not
the changes applied to an API compared to an older release.
The PEP is the perfect place for such a list, I guess.

-- 
Marc-Andre Lemburg
eGenix.com

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

[Python-Dev] r43041 - python/trunk/Modules/_ctypes/cfield.c

[Jim Jewett]

(Regarding changes caused by ssize_t0

Martin v. Löwis wrote:
> It is possible to look at the changed APIs, see

> http://docs.python.org/dev/api/sequence.html

I think the problem is more with APIs that are not part of the
sequence page.  For instance, in

http://mail.python.org/pipermail/python-dev/2006-March/062679.html

M.-A. Lemburg mentioned

  PyAPI_FUNC(int) PyDict_Next(
  PyObject *mp, Py_ssize_t *pos, PyObject **key, PyObject **value);

PyDict_Next  isn't on the sequence page, but if you call it, it could
write a Py_ssize_t into pos, even though your pointer is only
large enough for an int.

To do things correctly, you really have to change your call to the
new version (and add the #ifdef)

  #if PY_VERSION_HEX < 0x0205
  typedef int Py_ssize_t;
  #endif

You can downcast if you aren't ready to support 64-bits, but ... setting
up a possible buffer overflow is a bit worse than simply not supporting.

-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] Documenting the ssize_t Python C API changes

[Martin v. Löwis]

M.-A. Lemburg wrote:
> It's not a waste of time at all: you'd be helping lots and
> lots of developers out there who want to fix their extensions.

This is free software, anybody is free to decide what they do.
I don't believe that developers would be helped a lot - they
can easily search for Py_ssize_t in the header files, and
find all the APIs that have changed.

However, they *should* not have to do that. Instead, they
should look at it from a conceptual point of view: Does
that variable "count" something (memory, number of elements,
size of some structure). If it does, and it currently counts
that using an int, it should be changed to use a Py_ssize_t
instead.

So just review all occurrences of int in your code, and you
are done. No need to look at API lists.

> The ssize_t patch is the single most disruptive patch in
> Python 2.5, so it deserves special attention.

I can believe you that you would have preferred not to see
that patch at all, not at this time, and preferably never.
I have a different view. I don't see it as a problem, but
as a solution.

Again, if you think the documentation should be improved,
go ahead and improve it.

Regards,
Martin

___
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] buildbot failure in sparc solaris10 gcc trunk

[buildbot]

The Buildbot has detected a new failure of sparc solaris10 gcc trunk.
Full details are available at:
 http://www.python.org/dev/buildbot/sparc%20solaris10%20gcc%20trunk/builds/85

Buildbot URL: http://www.python.org/dev/buildbot/

Build Reason: The web-page 'rebuild' button was pressed by 'Martin von Loewis': 
Trigger a build failure

Build Source Stamp: [branch trunk] HEAD
Blamelist: raymond.hettinger

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

___
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] r43041 - python/trunk/Modules/_ctypes/cfield.c

[Martin v. Löwis]

Jim Jewett wrote:
>> It is possible to look at the changed APIs, see
> 
>> http://docs.python.org/dev/api/sequence.html
> 
> I think the problem is more with APIs that are not part of the
> sequence page.  For instance, in
> 
> http://mail.python.org/pipermail/python-dev/2006-March/062679.html
> 
> M.-A. Lemburg mentioned
> 
>   PyAPI_FUNC(int) PyDict_Next(
>   PyObject *mp, Py_ssize_t *pos, PyObject **key, PyObject **value);
> 
> PyDict_Next  isn't on the sequence page, but if you call it, it could
> write a Py_ssize_t into pos, even though your pointer is only
> large enough for an int.

I gave the sequence page just as an example. The new signature of 
PyDict_Next is also documented, see

http://docs.python.org/dev/api/dictObjects.html#l2h-629

> To do things correctly, you really have to change your call to the
> new version (and add the #ifdef)
> 
>   #if PY_VERSION_HEX < 0x0205
>   typedef int Py_ssize_t;
>   #endif
> 
> You can downcast if you aren't ready to support 64-bits, but ... setting
> up a possible buffer overflow is a bit worse than simply not supporting.

Sure. In that case, the compiler will give you a compiler warning, on
a 64-bit system. You certainly should react to that warning.

I personally doubt that somebody would go through the list of the 
100-something APIs that changed, memorize them, and then go to his
source code, to find out what to change; I know that I don't work
that way. That said, if somebody things it is worthwhile to create
such a list: contributions are welcome.

Regards,
Martin
___
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] All green!

[Tim Peters]

[Tim, last Friday]
> ... all 14 columns in
>
> http://www.python.org/dev/buildbot/all/
>
> are green.  Yippee!  Let's keep 'em that way.  You can all take the
> weekend off ;-)

But you didn't, and they haven't been all green again since then .

With the next 2.4 release candidate imminent, remember that the
buildbot isn't testing release-mode builds, or -O runs.  There are 8
combinations you can make out of:

debug vs release
-O or not
with/without deleting .py[co] files first

I'll run all 8 on WinXP Pro.  It would be prudent for someone to do
the same on at least one flavor of Linux.
___
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] buildbot warnings in x86 gentoo trunk

[buildbot]

The Buildbot has detected a new failure of x86 gentoo trunk.
Full details are available at:
 http://www.python.org/dev/buildbot/x86%20gentoo%20trunk/builds/95

Buildbot URL: http://www.python.org/dev/buildbot/

Build Reason: The web-page 'force build' button was pressed by 'Tim': someone 
forgot to say "trunk" last time a build was forced

Build Source Stamp: [branch trunk] HEAD
Blamelist: 

Build Had Warnings: warnings test

sincerely,
 -The Buildbot

___
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] Py3k: Except clause syntax

[Greg Ewing]

Guido van Rossum wrote:

> In the style guide only, I hope. The parens that are mandatory in a
> few places *are* necessary to resolve ambiguity.

That's not entirely true. My original list comprehension
implementation didn't require parens around unpacked loop
variables -- Guido added them because he thought it looked
better that way.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiam! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[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] Python 3000 Process

[Greg Ewing]

Guido van Rossum wrote:

> respond with a +1
> or -1 on the creation of the python-3000 mailing list.

+1

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiam! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[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] Py3k: Except clause syntax

[Greg Ewing]

Gareth McCaughan wrote:

> but wouldn't if be nice if you could say
> 
> def f((x0,y0) as p0, (x1,y1) as p1):

I'm not sure that it would. Currently you can look at
a function header and get a picture of its calling
signature, but this would clutter it up with
implementation details of the function that aren't
relevant to the caller.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiam! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[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] GeneratorExit inheriting from Exception

[Greg Ewing]

Barry Warsaw wrote:

> One quibble.  Since the term used for the general concept of something
> that is raised and caught is "exception" and since all the raise-able
> objects live in a module called "exceptions", it is confusing that
> "except Exception" will not catch all exceptions.

My thoughts exactly.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiam! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[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] GeneratorExit inheriting from Exception

[Greg Ewing]

Barry Warsaw wrote:

> Ideally, StandardError would be called
> Error ...  Their non-error exceptions
> would be derived from Exception.

Having something called StandardError suggests that
there are "non-standard errors" around somewhere.
Are we to have Error Police going around making
sure everyone's errors are standardised? :=)

Also, "standard error" sounds like some sort of
statistical term to me...

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiam! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[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] GeneratorExit inheriting from Exception

[Greg Ewing]

Aahz wrote:

> > Also maybe start issuing warnings whenever you inherit directly from
> > Exception.
> 
> -1 -- I occasionally use exceptions as a multi-loop break.  That's a
> perfectly valid Python practice, those exceptions should inherit from
> Exception, and there should not be any warnings raised.

There probably should be a ControlFlowException category
for these that would also include StopIteration and
GeneratorExit. I don't think it should include *all*
exceptions other than Errors or Warnings, though.
SystemExit and KeyboardInterrupt remain two things
that you will almost always not want to catch, even
in a top-level catch-almost-everything loop. So I'd
leave these two out on their own.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiam! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[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

[Python-Dev] segfaults on Mac (was Re: Long-time shy failure in test_socket_ssl))

[Tim Peters]

[Nick Coghlan]
> Hrrm, test_thread_state hands an object pointer off to a different thread
> without INCREF'ing it first. Could there be a race condition with the
> deallocation of arguments at the end of test_thread_state?
>
> Specifically, that trace looks to me like the spawned thread is trying to call
> the function passed in while the main thread is trying to delete the argument
> tuple passed to test_thread_state.

Good eye!  I haven't been able to _provoke_ that failure on Windows
yet, but it sure looks promising.  Compounding the problem is that the
thread tests in test_capi.py are set up incorrectly:  due to "hidden"
fighting over Python's import lock, the second TestThreadState here
(the one run in the new thread) can't really start before test_capi.py
(when run via regrtest.py) finishes:

if have_thread_state:
TestThreadState()
import threading
t=threading.Thread(target=TestThreadState)  THIS ONE
t.start()

The dramatic  way to show that is to add "t.join()". 
test_capi.py deadlocks then (not a problem with t.join(), the problem
is that TestThreadState is hung trying to do its imports, which it
can't do before regrtest.py's import of test_capi.py completes,
because of the hidden import lock; so the thread never makes progress,
and t.join() waits forever).  I can fix that easily (and will), but I
want to provoke "a problem" on my box first.

The consequence is that the instance of TestThreadState run in the
thread ends up running in parallel with later tests run by
regrtest.py.  Therefore it's not surprising to see a segfault due to
test_thread_state occur a few tests after regrtest.py believes
test_capi has completed.

Later:  by adding strategic little counters and conditional sleeps all
over the place in the C code, I was able to reproduce a segfault on
Windows.  I'm not yet sure how to fix it (repairing the structure of
test_capi.py would make it more likely that the segfault would occur
closer to the time test_capi runs, but the segfault actually occurs in
a non-threading.py thread spawned by the _C_ test code, and there's
nothing we can do in test_capi.py to wait for that thread to finish).
___
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 3000 Process

[R Morris]

Barry Warsaw wrote:
> 
> On Mon, 2006-03-20 at 13:30 -0500, Terry Reedy wrote:
>> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
>> >Barry, if you could create that mailing list, please?
>> 
>> And please mirror it on gmane the same way as this list is.
> 
> Subscription requests have been made.
> -Barry
> 

BTW: It's already archived here and searchable back to the end of August:

http://www.nabble.com/Python---python-dev-f2960.html

Sorry for the intrustion.

Regards,
Rod Morris
Nabble.com

--
View this message in context: 
http://www.nabble.com/Python-3000-Process-t1309231.html#a3506703
Sent from the Python - python-dev forum at Nabble.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] Python 3000 Process

[Guido van Rossum]

The Python 3000 mailing list has been created. From now on let's have
all discussions related to Python 3000 on that list. Please subscribe
here:

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

Let's start by attempting to answer the process questions: timeline;
upgrade path; library reform; implementation strategy; and feature
proposal process. I'll be away tomorrow so there's plenty of
opportunity to start without me. :-)

There's also a list for Python-3000-related checkins. Don't subscribe
to that one yet, it's very boring and uninteresting. Also, Barry
hasn't done the svn magic yet. :-)

BTW please be patient with inquiries about Python 3000 on python-dev.
While *proposals* of new features etc. can safely be referred to the
python-3000 list, *questions* on python-dev about Python 3000 (e.g.
"when will it be released" or "will I have to rewrite all my code" or
even "what's the fate of existing feature X") are best answered,
initially directly on python-dev, eventually by referring to the
appropriate PEPs once they have been written (and are on-line -- a
sore point right now since the new website has broken the process for
updating the on-line copies of PEPs automatically upon checkin into
svn).

--
--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] r43041 - python/trunk/Modules/_ctypes/cfield.c

[Jim Jewett]

On 3/20/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jim Jewett wrote:

> > To do things correctly, you really have to change
> > your call to the new version (and add the #ifdef)

> >   #if PY_VERSION_HEX < 0x0205
> >   typedef int Py_ssize_t;
> >   #endif

> > You can downcast if you aren't ready to
> > support 64-bits, but ... setting up a possible
> > buffer overflow is a bit worse than simply
> > not supporting.

> Sure. In that case, the compiler will give you a
> compiler warning, on a 64-bit system.  You
> certainly should react to that warning.

The person compiling on a 64-bit system may
not be the developer.

The buildbot was started in part because the
Windows build didn't work -- many developers
didn't have a windows environment to test with.

This change will put 64 bit systems in the same
awkward position -- they need different code,
which many developers can't really test
properly.

> I personally doubt that somebody would go
> through the list of the 100-something APIs
> that changed, memorize them, and then go
> to his source code, to find out what to change;

Agreed; they would be more likely to run a
grep for a one-time conversion.  Catching the
error as it creeps back in later would be ...
something people learn the hard way.  But
not having that list for a grep makes the
situation even worse.

-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

[Python-Dev] Problem with module loading on multi-arch?

[Jim Jewett]

> x86_64 is multiarch.  That means, we allow both
> i386 and x86_64 binaries to coexits.  Is the proposal
> that python should not support this?  That would
> be unfortunate.

The problem is that at the moment, a package
has to live all in one place.  This doesn't mean
you can't have both types of binaries for python
as a whole.  (Though whether you can run them
in the same process is another issue.)  It does
mean that you can't have them in the same
package.

This is already awkward for packages split
between python and extension modules.

As a workaround, you can add a .pth file;
eggs and namespace packages may improve
the situation some more.

-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