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
___
>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
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 unfor
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
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 eve
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
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 li
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 = colle
> 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)
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 H
> 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. I
On 2009.05.13 10:34:55 +0200, henning.vonbar...@arcor.de 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.c
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 t
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 obj
14 matches
Mail list logo
