I believe Brett mentioned the 'languishing' status for the tracker in
passing in his notes from the language summit.
To expand on this: the desire for this arises from the observation
that we have a lot of bugs in the tracker that we don't want to close,
because they are real bugs or non-crazy enhancement requests, but for
one reason or another (lack of an interested party, lack of a good,
non-controversial solution, lack of a test platform on which to test the
bug fix, the fix is hard but the bug is not of a commensurate priority,
etc) the issue just isn't getting dealt with, and won't get dealt with
until the blocking factor changes.
The motivation for introducing a new status, rather than continuing
to leave these bugs in 'open' state, is to make it clear which bugs
are the *active* bugs, the ones we should be focusing on and working
to fix first. This would allow the count of open bugs to be a more
meaningful metric than it is currently, and might even allow us to get
to a point where the open bug count stops increasing. More importantly,
however, it would act as a first level partition of the non-closed bugs,
such that the ones for which it is most likely that effective action can
be taken will be what appear first. This is especially important for new
people coming in to help. How many people have looked at the tracker,
and decided to start from the oldest bugs and see what they can fix?
I know I started out that way. Looking through those oldest bugs can
be quite discouraging, since many of them are old because they are hard,
or blocked for one reason or another.
We would in addition propose that a 'languishing' search be added to
the standard searches. I would also propose that the default search
be changed to search all bugs, and group them by status, not priority.
This will make it more likely that bug *reporters* will find existing
bugs that relate to the problem they are experiencing or the feature
they want to propose. The other searches (except open) should probably
return languishing issues as well as open, since they sort in reverse
chronological order the more active bugs will be at the top, and that
way the languishing bugs won't be forgotten. (Note: languishing bugs
should probably never have the 'needs review' keyword, since bugs should
not be allowd to languish simply for need of a review.)
To move a bug to state languishing, the procedure should be to post
a comment saying why you are moving the bug to that status, that by
implication or explicitly lays out the conditions required for it to
move back to open. Doing so may wake someone up who wants to and can
deal with the issue, in which case it can be moved back to open.
--David
PS: I believe that the other change that would be required in addition
to adding the new status and search is to alter the bug summary email
script to handle the languishing state. If I've missed anything else
please let me know.
Hello, Dave;
My name is Craig Connor and I am a senior s/w developer at Northrop
Grumman.
I have a question for you. I have installed Boost (via the Installer),
and stored it into my
C Drive inside a dir called:
C:\boost_1_42
I also installed the Boost Jam into a directory called:
C:\boost-jam-3.1.17
I am using 2 separate compilers in my Win OS XP (SP3)
and I would like to be able to use the Python module of Boost
in order to embed Python.h into my C++ compiler.
The C++ compilers that I have are:
o Dev-cpp, and
o Visual C++.net (of MS Visual Studio.Net 2008).
Problem:
When I compile a simple program, I keep getting the error:
"pyconfig.h: No such file or directory".
The program I am trying to start with is (below):
#include <iostream>
#include<boost/any.hpp>
#include<boost/python.hpp>
using namespace std;
int main( )
{
cout << "Hello, Boost World!!" << endl;
boost::any a(5);
a = 7.67;
std::cout<<boost::any_cast<double>(a)<<std::endl;
system( "PAUSE" );
return 0;
}
Also:
I did set up my environmental config to go to the Boost dir.
Question:
Do you know what am I doing wrong?
Regards,
Craig Connor
720.622.2209
It's been a long time!
So for the past few weeks, Mercurial crew member Patrick Mezard has
been hunting for the ugly bug in hgsubversion that I'd previously been
looking at, and it finally got fixed. A new bug popped up, but then we
managed to fix that, too (thanks to the PSF for partially funding our
sprint, it was very succesful!). In a joyous moment, I nagged Augie
Fackler to actually put a hgsubversion release out there so hopefully
more people can start using it, so we now have that, too. Another
sponsor for our sprint was Logilab (who provided their brand new
office for us to work in), and one of their employees, Andre Espaze,
fortunately wanted to help out and managed to write up a patch for the
sys.mercurial attribute (now in the pymigr repo).
In fact, a few weeks ago I talked to Brett and we figured that we
should probably pin down a deadline. We discussed aiming at May 1, and
at this time I think that should be feasible. That also seems to
coincide with the release of 2.7b2, though, so maybe we need to do it
one week later (or sooner?). Anyway, we figured that a weekend would
probably be a good time. If we manage to find a good date, I'll put it
in the PEP.
As for the current state of The Dreaded EOL Issue, there is an
extension which seems to be provide all the needed features, but it
appears there are some nasty corner cases still to be fixed. Martin
Geisler has been working on it over the sprint, but I think there's
more work to be done here. Anyone who wants to jump in would be quite
welcome (maybe Martin will clarify here what exactly the remaining
issues are).
The current version of the repository (latest SVN revision is 78055,
clone it from hg.python.org) weighs in at about 1.4G, but still needs
branch pruning (which will be my primary focus for the coming few
weeks). The good part about it now being a year later than, well, last
year is that named branches are much more solid than before, and so I
feel much better about using those for Python's release branches.
Any questions and/or concerns?
I will also be at PyCon; I'll be doing a more advanced talk on
Mercurial internals on Sunday but I'd also be happy to do some
handholding or introductory stuff in an open space. If there's anyone
who'd like help converting their SVN repository, I might be able to
help there too (during the sprints). For other conversions, I know for
a fact that an expert in CVS conversions will be there.
Cheers,
Dirkjan
This code works on 2.6 and 3.0:
>>> format(1+1j, '10s')
'(1+1j) '
That's because format ends up calling object.__format__ because complex
doesn't have its own __format__. Then object.__format__ calls str(self)
which returns '(1+1j) '. So the original call basically turns into
"format('(1+1j) ', '10s')".
In 3.1 (released) and 2.7 (not yet released) I implemented __format__ on
complex. So now that same code is an error:
>>> format(1+1j, '10s')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Unknown format code 's' for object of type 'complex'
That's because complex._format__ doesn't recognize string formatting
codes, in particular 's'.
There's a general problem that types that sprout __format__ will break
existing usages of format() that use some string formatting codes,
unless the types recognize string formats in addition to their own. I
think we should change the documentation of format() to warn that you
should really call str() on the first argument if you're relying on the
second argument being a string formatting code.
But what to do about 3.1 and 2.7 with respect to complex? I see 2 options:
1. Leave it as-is, such that 3.1 and 2.7 might break some uses of
format(complex, str).
2. Modify format to understand 's' and do the conversion itself. But we
don't do this for int and float, that's why we added '!s'.
I'm sort of leaning toward #1, but I'd like to know if anyone has an
opinion. I haven't heard of anyone complaining about this yet; it would
only have tripped up people moving from 3.0 -> 3.1, or from 2.6 -> 3.1
who used format (or str.format()) while specifying 's' or some other
str-specific format codes.
Eric.
Hello Dirkjan,
We are going to start working on a few things in Distutils at Pycon
outside the trunk.
I was about to start this work in the svn sandbox, but if possible I'd
rather have a repo at hg.python.org as well
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
An advantage of being at PyCon :)
We *may* be able to get on mercurial very fast -- since all of the
interested parties are here. I'm going to get an svndump now -- the
downside to this is whatever anyone checks in during this in between
stage would need to get re-checked in after we move.
I'll let you know how it goes.
-Frank
Hey Dirkjan,
Would it be possible for us to get a Mercurial repository on
python.org for the Unladen Swallow benchmarks? Maciej and I would like
to move the benchmark suite out of Unladen Swallow and into
python.org, where all implementations can share it and contribute to
it. PyPy has been adding some benchmarks to their copy of the Unladen
benchmarks, and we'd like to have as well, and Mercurial seems to be
an ideal solution to this.
Thanks,
Collin Winter
(http://trentmick.blogspot.com/2010/02/other-python-vms-upcoming-python.html)
Note that this was just from the first 15 minutes or so...
>
> Some quick notes about the coming plans by the "other" Python implementations
> from today's Python Language Summit at PyCon 2010:
>
> - IronPython:
> - plan is to do Python 2.7 first, focus for this year
> - python 3.2 for the end of next year hopefully
> - other work on IDE stuff
> - Pynie (i.e. Parrot) -- Allison Randall:
> - about 4 major features away from pure Python syntax (did dicts last
> night)
> - targetting py3k repo and test suite: should be on track for python 3.2
> - Jython:
> - plan to target 2.6 (b/c 2to3 depends on 2.6)
> - temporarily skip 2.7 and target 3.x (probably 3.2)
> - then if 3.x adoption isn't fully there, then go back and add Python 2.7
> - will require JDK 2.7 for Python 3 support (b/c of new support for
> dynamic languages)
> - PyPy (Holger):
> - plan is Benjamin will port to Python 2.7 in the summer
> - only have slight deviations from CPython: idea is to merge back with
> CPython so don't have deviations. Typcically 1 or 2 line changes in ~25
> modules.
>
Trent
--
Trent Mick
trentm at activestate.comhttp://trentm.com/blog/
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
>I'm not sure how this should best work on Windows (without symlinks,
>and where things generally work differently), but I would hope if
>this idea is more visible that someone more opinionated than I would
>propose the appropriate analog on Windows.
You'd probably have to just copy pythonv.exe to an appropriate
directory, and have it use the configuration file to find the "real"
prefix. At least, that'd be a relatively obvious way to do it, and
it would have the advantage of being symmetrical across platforms:
just copy or symlink pythonv, and make sure the real prefix is in
your config file.
(Windows does have "shortcuts" but I don't think that there's any way
for a linked program to know *which* shortcut it was launched from.)
