Guido van Rossum | 1 Oct 07:31 2000

Release candidate followed by feature freeze?

I'm considering to issue a release candidate before the final 2.0
release.  I'd like to poll opinions about this (we haven't had a
PythonLabs group meeting about this yet).

The importance of a release candidate (RC) is twofold: we announce it
widely so it (hopefully) gets a lot of testing -- necessary since a
lot of things have changed again since beta2; and we impose a checkin
stop once the RC is out, with exceptions only allowed by the release
manager to fix showstopper bugs found in the RC.

This will hopefully avoid a disaster like we had with the buggy
last-minute changes in beta2 (for which I take full responsibility).

If the idea of a RC sounds okay, I'd like to propose to release it on
October 5.  The final release would still be on October 10, or perhaps
1-2 days later.  Much less than a week between the RC and the final
release is not good because it doesn't give testers enough time to try
out the RC; much more than a week is bad because the developers get
antsy when they can't check in their changes!

This means that any current bug reports and patches that aren't in the
RC, WON'T BE FIXED in the final release!  Think about it.  This is a
good thing, so we won't be able to screw up the final release at the
last moment.

--Guido van Rossum (home page: http://www.python.org/~guido/)

Thomas Wouters | 1 Oct 14:06 2000
Picon

Re: Changes in semantics to str()?

On Sat, Sep 30, 2000 at 03:56:18PM -0500, Guido van Rossum wrote:

> Below I have included changes to listobject.c, tupleobject.c and
> dictobject.c that fix this.  The fixes change the print and str()
> callbacks for these objects to use PyObject_Str() on the contained
> items -- except if the item is a string or Unicode string.  I made
> these exceptions because I don't like the idea of str(["abc"])
> yielding [abc] -- I'm too used to the idea of seeing ['abc'] here.
> And str() of a Unicode object fails when it contains non-ASCII
> characters, so that's no good either -- it would break too much code.

Personally, I'm -0, or perhaps -1 (I'll make up my mind while going out for
some lunch/breakfast ;) I would be in favor if the str() output were only
used to display something to a user, but that's not the case. And too many
people are under the impression that the 'print' handler is the same as the
'str' handler to make that distinction now, I'm afraid. My main gripe with
this change is that it makes str() for container objects unreliable...
Strings are a special case, but class-instances are not -- so something like
UserString will be displayed without quotes. I don't like the idea of
sometimes doing 'str' and sometimes doing 'repr'.

I understand what it's trying to solve, but I don't think that's a worse
inconsistency than the one this change introduces. It's also easy to
explain: 'str(list or dict) is the same as repr(list or dict)'. The new
phrase would be something like 'str(list or dict) calls str() on the objects
it contains, except for string and unicode objects.'. And even that breaks
when you mix in instances that wrap a container. A list containing a
UserList containing a set of (unicode-)strings would display the strings
without quotes. And you can't see that the second container is a UserList.

(Continue reading)

Jim Fulton | 1 Oct 16:32 2000

select, signals, and "interrupted system call" (EINTR)

If a select-based (or, presumably, poll-based) server wants to
use signals for anything other than shutdown (e.g. closing and
reopening log files, rereading configs, etc.), then, on some 
platforms, a select call can fail with an "interrupted system
call" (EINTR) error that should be ignored.  The asyncore 
main loop should check for this error in it's select call
and the select module should make this error easier to check for.

In Python 1.5.2, the medusa select call can be changed from

        r,w,e = select.select (r,w,e, timeout)

to:

        while 1:
            try: r,w,e = select.select (r,w,e, timeout)
            except select.error, v:
                if v[0] != EINTR: raise
            else: break

I presume that this works in Python 1.6/2.0, but I
haven't tried it yet?

This depends on the structure of select.error values
and requires that we get EINTR from somewhere. (What
should the value be on NT?) 

I wonder if there should be an InterruptedSystemCall
exception somewhere that select raises in this case?

(Continue reading)

Sam Rushing | 1 Oct 21:07 2000

[medusa] select, signals, and "interrupted system call" (EINTR)

Jim Fulton writes:
 > The asyncore main loop should check for this error in it's select
 > call and the select module should make this error easier to check
 > for.

It might go better into the event_loop function, which I think of as a
more user-serviceable part.  [for example, the default loop vs. the
one in medusa/event_loop.py that supports schedulable events]

 > I presume that this works in Python 1.6/2.0, but I
 > haven't tried it yet?
 > 
 > This depends on the structure of select.error values
 > and requires that we get EINTR from somewhere. (What
 > should the value be on NT?) 

If it's a big problem, I guess we could use a different default
event_loop() function for win32 vs. unix.

 > At a minimum, code like the above should be added to asyncore.
 > 
 > Thoughts?

This has been asked for several times, I agree it'd be nice to have at
least a note in the docs..

-Sam

Martin von Loewis | 1 Oct 21:13 2000
Picon

Release candidate followed by feature freeze?

> I'd like to poll opinions about this (we haven't had a PythonLabs
> group meeting about this yet).

YES! I was hoping somebody would propose such a thing; I was quite
concerned that check-in procedures are still that liberate.

To report how similar projects operate: In gcc, a CVS release branch
is created at some point in time (usually months before the
release). When the code is declared frozen, all changes to the release
branch have to go through the release manager. After the release,
"important" changes to the mainline branch are manually propagated to
the release branch for subminor releases.

Regards,
Martin

Dan Wolfe | 1 Oct 23:23 2000
Picon

Re: FW: regarding the Python Developer posting...

>> [commented out code that was causing seg fault in test_sre.py]

>you could try adding a Mac OS clause to the recursion limit stuff
>in Modules/_sre.c:
>
>#if !defined(USE_STACKCHECK)
>#if defined(...whatever's needed to detect Max OS X...)
[....]
>
>replace "...whatever...", and try larger values than 5000 (or smaller,
>if necessary.  10000 is clearly too large for your platform).
>
>(alternatively, you can increase the stack size.  maybe it's very small
>by default?)

the stack size is quite small by default - 512K.  After some testing I 
was able to figure out that it fails around 440 recursions... probably a 
bit too small in comparison to the other *nixes.... but then I'll defer 
to the experts in sre.

I was reading the August developer archives on the getrlimit and since 
that seem to be available, it's probably the right way to implement the 
stack check on Mac OS X.

Sure I can increase the default stack size - just a simple limit -h 
before running it in the shell... I let it run until about 7K 
recursions... even then it was only about 11MB and bumping the stack up 
by 30K or so per recursion... and I still had nearly 100MB free... and 
places to go. :-)

(Continue reading)

Barry Scott | 2 Oct 00:19 2000
Picon
Picon

RE: Patch to avoid conflict with older versions of Python.

I still think that Python needs to fix the problem with the API between
the core and the extensions. That way all the version checking would work
for Windows and Unix.

But since that approach has been rejected I'd take any change to python
that reduces support calls.

		BArry

> -----Original Message-----
> From: python-dev-admin <at> python.org [mailto:python-dev-admin <at> python.org]On
> Behalf Of Mark Hammond
> Sent: 29 September 2000 02:36
> To: python-dev <at> python.org
> Subject: [Python-Dev] Patch to avoid conflict with older versions of
> Python.
> 
> 
> Hi all,
> 	I'd like some feedback on a patch assigned to me.  It is designed to
> prevent Python extensions built for an earlier version of Python from
> crashing the new version.
> 
> I haven't actually tested the patch, but I am sure it works as advertised
> (who is db31 anyway?).
> 
> My question relates more to the "style" - the patch locates the new .pyd's
> address in memory, and parses through the MS PE/COFF format, locating the
> import table.  If then scans the import table looking for Pythonxx.dll, and
> compares any found entries with the current version.
(Continue reading)

M.-A. Lemburg | 2 Oct 09:36 2000

Re: Release candidate followed by feature freeze?

Martin von Loewis wrote:
> 
> > I'd like to poll opinions about this (we haven't had a PythonLabs
> > group meeting about this yet).
> 
> YES! I was hoping somebody would propose such a thing; I was quite
> concerned that check-in procedures are still that liberate.
> 
> To report how similar projects operate: In gcc, a CVS release branch
> is created at some point in time (usually months before the
> release). When the code is declared frozen, all changes to the release
> branch have to go through the release manager. After the release,
> "important" changes to the mainline branch are manually propagated to
> the release branch for subminor releases.

+1

I think this is very good approach to the problem which we should
consider to apply to Python too.

BTW, could the nightly snapshots of the CVS tree that Jeremy
installed be made official ? 

This would be a great way to attract more beta-tester since not
everyone is willing to first set CVS on their machine just
to download the current Python development version.

--

-- 
Marc-Andre Lemburg
______________________________________________________________________
(Continue reading)

Martin v. Loewis | 2 Oct 09:39 2000
Picon

What is --with-next-framework

I've been trying to understand how --with-next-framework is supposed
to work, and on what systems it is supposed to work - with little
success.

From what I understand, it will create a python2.0.dylib, and it will
pass that to the linker when linking extension modules. Fine.

What confuses me is the snippet in Modules/getpath.c, where it somehow
assumes that the Python library will live in an unversioned lib
directory relative to the location of the Python framework. How is
that supposed to work? Is anybody here willing to claim that this code
is not entirely broken?

Regards,
Martin

M.-A. Lemburg | 2 Oct 09:51 2000

Re: Changes in semantics to str()?

Guido van Rossum wrote:
> 
> When we changed floats to behave different on repr() than on str(), we
> briefly discussed changes to the container objects as well, but
> nothing came of it.
> 
> Currently, str() of a tuple, list or dictionary is the same as repr()
> of those objects.  This is not very consistent.  For example, when we
> have a float like 1.1 which can't be represented exactly, str() yields
> "1.1" but repr() yields "1.1000000000000001".  But if we place the
> same number in a list, it doesn't matter which function we use: we
> always get "[1.1000000000000001]".
> 
> Below I have included changes to listobject.c, tupleobject.c and
> dictobject.c that fix this.  The fixes change the print and str()
> callbacks for these objects to use PyObject_Str() on the contained
> items -- except if the item is a string or Unicode string.  I made
> these exceptions because I don't like the idea of str(["abc"])
> yielding [abc] -- I'm too used to the idea of seeing ['abc'] here.
> And str() of a Unicode object fails when it contains non-ASCII
> characters, so that's no good either -- it would break too much code.
> 
> Is it too late to check this in?  Another negative consequence would
> be that for user-defined or 3rd party extension objects that have
> different repr() and str(), like NumPy arrays, it might break some
> code -- but I think this is not very likely.

-1

I don't think that such a change is really worth breaking
(Continue reading)


Gmane