Re: [Python-Dev] Shorter release schedule?
On Wed, May 13, 2009 at 12:29 AM, Barry Warsaw wrote: > I've been in favor of that for a while now. With the move to a DVCS (how's > that coming along?) I've been rewriting PEP 374 about the Mercurial migration. Will post here once it's ready for review. Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter release schedule?
>From the perspective of this application developer and prototyper... In general, releases should be more frequent when the language is less mature and perhaps lacking. With maturity one seeks stability and less frequency. Python is, for the most part, a mature language. I submit the issue is less a question of frequency, but more a question of the number and value of each of the new features. Too many new features added to a mature language begs the question of simplicity vs complexity. One of Python's original goals, if I recall correctly, was to keep life simple, to have executable psuedocode, be easy to learn and re-learn, and be able to quickly read and grok your code 6-12 months later. Ease of maintenance is a huge advantage of Python. From an application developer's perspective, too many confusing features and the language becomes more and more like C++ and APL. I submit Python is now at the point where new features must not be added just because they are cool, but because they indeed add significant value *without* compromising simplicity and the suite of "easy to" benefits. The alternative is to rethink the long-term goals for the language. That could have large unintended consequences. Larry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] How to build Python 2.6.2 on HP-UX Itanium with thread support?
How to build Python 2.6.2 on HP-UX Itanium with thread support? Note: I know that the first address to post this question is comp.lang.python, but I posted this question a week ago on comp.lang.python (http://groups.google.com/group/comp.lang.python/browse_thread/thread/c7006ad8e5cf81e8) and unfortunately, I didn't receive any answers. According to Patch 1225212, at least Peter Kropf was able to get Python running with threading support on this platform, though AFAIK he was not using GCC. But I guess it should be possible with GCC as well. Is anyone able to confirm that Python (built with GCC) does or does not work with multi-threading on HP-UX Itanium? Is HP-UX Itanium a supported platform at all? BTW: A search for "supported platforms" at www.python.org does not help! And if it does work, which steps need to be taken to build it, e.g. other libraries/packages, environment variables, configure options, manual modifications? Henning ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter release schedule?
Martin v. Löwis v.loewis.de> writes: > > Such a schedule was initially used for the first 2.x releases. We then > switched to 18 months because of user complaints: if releases come too > frequently, the users are confused as to what release they should be > using. Even 24 months is too frequently for some: some people are only > starting to move to 2.5 right now - when we have stopped maintaining > it already. Obviously, there are some users who value stability over everything else. While new language features are never critical and can easily be circumvented if you want your code to run on old Python versions, stdlib improvements can be more important for the average user. So perhaps the answer is the split that Brett proposed between core language and stdlib. > One question is what would happen to the old releases: would we still > maintain them? If so, how many of them? For how long? Yes, I realized that's one of the problems with this proposal. If we had to maintain more than one stable branch, it would become a burden. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter release schedule?
Antoine Pitrou wrote: Yes, I realized that's one of the problems with this proposal. If we had to maintain more than one stable branch, it would become a burden. Agreed. And since we have 2.x and 3.x now, we already have that problem. I'd like to an acceleration of release schedules (if it even happens) come after 2.x is retired. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter release schedule?
Antoine Pitrou wrote: > Hello, > > Just food for thought here, but seeing how 3.1 is going to be a real > featureful > schedule despite being released shortly after 3.0, wouldn't it make sense to > tighten future release planning a little? I was thinking something like doing > a > major release every 12 months (rather than 18 to 24 months as has been > heuristically the case lately). This could also imply switching to some kind > of > loosely time-based release system. > > If I'm wildly off-base, you can either flame me, ignore me, or assign me > annoying release blockers involving memoryviews and weird character encodings > :-) I don't think a shorter release cycle makes sense for a programming language. It's already the case that even with 18+ month release cycles some end users will leapfrog releases (e.g. 2.2-> 2.4 -> 2.6) for their environments (speaking from experience there, although the 2.6 part is mere wishful thinking at this stage). It also seems to takes 6-12 months for the complaints about Windows binary compatibility to die down after each release (although that appears to be less of an issue since MS released Visual Studio Express). That said, the 3.1 to 3.2 spacing will probably be shorter than normal (i.e. around 12 months), simply because 3.1 is an "extra" release to iron out some of the major issues with 3.0. This will give 'normal' 18 month spacing for the 2.6 -> 2.7 gap. The other big factor to consider here is the duration of bug fix support for releases. With our policy of "current release and previous release are supported with bug fixes" and the 18-24 month release cycle, that means each release typically receives bug fix updates for 3-4 years. That's a reasonably period of time (and gives plenty of time to shake out even fairly thorny issues). If we were to switch to yearly releases, then either the support policy would have to change to at least "current release and the previous two releases" or we'd have to accept the fact that the support period for each release would now be no more than 2 years. Since 2 years strikes me as an unacceptably short period for maintenance, shorter release cycles would then lead directly to having to maintain more parallel branches (which doesn't strike me as a good use of developer effort). Standardising a time frame for major releases is a fine idea, but I don't think shortening that time frame to 12 months would be wise. Settling on 18 months would probably work though - those that crave stability can then use every alternate version and only upgrade every 3 years, as each branch would be maintained with general bug fixes for at least 3 years and security fixes for a further 3 years after that. I think 24 months would lead to too slow an overall development tempo though - the year-and-a-half approach feels to me like it would strike a better balance. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Shorter release schedule?
Nick Coghlan wrote: > Settling on 18 months would probably work though - those that crave > stability can then use every alternate version and only upgrade every 3 > years I wonder about that. Lots of people are forced to upgrade by new language features: decorators, list comprehensions, set literals, etc., that are required by external libraries that they use. One of the huge strengths of Python is the external library community. Interesting tension there... Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Should collections.Counter check for int?
I just noticed that while the docs say that "Counts are allowed to be
any integer value including zero or negative counts",
collections.Counter doesn't perform any check on the types of count
values. Instead, non-numerical values will lead to strange behaviour or
exceptions later on:
>>> c = collections.Counter({'a':'3', 'b':'20', 'c':'100'})
>>> c.most_common(2)
[('a', '3'), ('b', '20')]
>>> c+c
Traceback (most recent call last):
File "", line 1, in
File "/local/hagenf/lib/python3.1/collections.py", line 467, in __add__
if newcount > 0:
TypeError: unorderable types: str() > int()
I'd prefer Counter to refuse non-numerical values right away as the
present behaviour may hide bugs (e.g. a forgotten string->int
conversion). Any opinions? (And what about negative values or floats?)
- Hagen
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to build Python 2.6.2 on HP-UX Itanium with thread support?
> How to build Python 2.6.2 on HP-UX Itanium with thread support? > Note: I know that the first address to post this question is > comp.lang.python, but > I posted this question a week ago on comp.lang.python > (http://groups.google.com/group/comp.lang.python/browse_thread/thread/c7006ad8e5cf81e8) > and unfortunately, I didn't receive any answers. That isn't sufficient reason to post to python-dev, though. > Is HP-UX Itanium a supported platform at all? Python does not have a single supported platform (*), so: no. (*) in the sense that anybody is providing "support" for it, ie. guarantees help in case somebody has problems. (**) HP-UX is not a platform that any of the regular Python contributors uses or tests on at a regular basis. Python contributors mostly use Linux, Windows, and OS X; some also use Solaris and *BSD. > And if it does work, which steps need to be taken to build it, > e.g. other libraries/packages, environment variables, > configure options, manual modifications? This really is out of scope for python-dev. In scope would be a proposal to apply a certain patch that you had to write Python work on HP-UX, and discussion whether this patch is the appropriate solution. Regards, Martin (**) There is, of course, ActiveState, which does provide binaries, including for HP-UX, so I suppose they support it - at least if you buy commercial support. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to build Python 2.6.2 on HP-UX Itanium with thread support?
Hi Henning, henning.vonbargen wrote: > How to build Python 2.6.2 on HP-UX Itanium with thread support? [snip bit about python-list] I can't give you directions, but if you can describe your issues I might be able to help. I'll respond in python-list, as I think this is OT for python-dev. > Is HP-UX Itanium a supported platform at all? > BTW: A search for "supported platforms" at www.python.org does not help! Now, this looks like python-dev material. PEP 11[0], the information in README[1] and the notes in the downloads pages[2] could be improved and updated. If someone has time to invest in this, a compatibility matrix would be very nice to have. Regards, Daniel [0] http://www.python.org/dev/peps/pep-0011/ [1] http://svn.python.org/view/python/trunk/README?revision=72107&view=markup [2] http://www.python.org/download/source/ and http://www.python.org/download/other/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to build Python 2.6.2 on HP-UX Itanium with thread support?
> Now, this looks like python-dev material. PEP 11[0], the information > in README[1] and the notes in the downloads pages[2] could be > improved and updated. If someone has time to invest in this, a > compatibility matrix would be very nice to have. I don't think HP-UX is ready for PEP 11 yet. It may not work, but that's a bug that could be fixed if users would actually contribute fixes. Likewise, changes to README could be accepted if users contribute them. I'm not sure /download/source is really that useful - perhaps it would be best to remove it. As for /download/other - contributions are welcome. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to build Python 2.6.2 on HP-UX Itanium with thread support?
On 2009.05.13 10:34:55 +0200, [email protected] wrote: > How to build Python 2.6.2 on HP-UX Itanium with thread support? > Note: I know that the first address to post this question is > comp.lang.python, but > I posted this question a week ago on comp.lang.python > (http://groups.google.com/group/comp.lang.python/browse_thread/thread/c7006ad8e5cf81e8) > and unfortunately, I didn't receive any answers. > > According to Patch 1225212, > at least Peter Kropf was able to get Python running with threading support > on this platform, though AFAIK he was not using GCC. > > But I guess it should be possible with GCC as well. > > Is anyone able to confirm that Python (built with GCC) > does or does not work with multi-threading on HP-UX Itanium? The good news: I did get Python 2.4.x working on HP-UX Itanium, with threading. The compiler was gcc 4.0.x. (I also tried building Python with aCC, but failed.) I remember building both 32-bit and 64-bit versions. I don't remember it being that hard. Used the source for the package at hpux.connect.org.uk as a starting point, since it had a lot of good porting tweaks, but it needed some further tweaking. (The main one I remember that is that the shared library extension for Itanium should be .so not .sl There were also a bunch of paths that required appending 32 or 64.) We used that build of Python in production, for very heavily multithreaded code, on multi-CPU boxes. Worked fine. AFAIK they're still using it. I'm not sure why the binary available at hpux.connect.org.uk has threading disabled. I suspect that some older version of HP/UX had pthread bugs that got fixed somewhere along the line. The bad news: I did this about 3.5 years ago, and I don't work there anymore, so I don't have access to that HP-UX hardware anymore, or to the notes I made when I was doing the port. So I can give you encouragement but not step-by-step instructions. Sorry. -- David [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should collections.Counter check for int?
On Wed, May 13, 2009, Hagen F?rstenau wrote: > > I'd prefer Counter to refuse non-numerical values right away as the > present behaviour may hide bugs (e.g. a forgotten string->int > conversion). Any opinions? (And what about negative values or floats?) Please file a report on bugs.python.org so that there's a record of this issue. -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] special method lookup: how much do we care?
On Sun, May 10, 2009 11:51PM, Nick Coghlan wrote: > However lots of developers rely on CPython ref counting as well, no > matter how many times they're told not to do that if they want to > support alternative interpreters. > > Cheers, > Nick. >From socket.py: # Wrapper around platform socket objects. This implements # a platform-independent dup() functionality. The # implementation currently relies on reference counting # to close the underlying socket object. class _socketobject(object): You don't know how much time I've spent trying to understand why test_httpserver.py hanged indefinitely when I was experimenting with new opcodes in my VM. Cheers, Cesare ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
