Hello,
Malte Helmert helmert at informatik.uni-freiburg.de writes:
are their any plans to organize another Python Bug Day in the near
future? It's been a while since the last one (last May). I might be
misremembering, but I think at one time there was even talk of having
one bug day every
On Mon, Jan 5, 2009 at 8:44 PM, Antoine Pitrou solip...@pitrou.net wrote:
Hello,
Malte Helmert helmert at informatik.uni-freiburg.de writes:
are their any plans to organize another Python Bug Day in the near
future? It's been a while since the last one (last May). I might be
Guido van Rossum wrote:
« Q: Do we want to mandate in the specification that switching between reading
and writing on a read-write object implies a .flush()? Or is that an
implementation convenience that users should not rely on? »
Is it ok if I assume that the answer is it is an
When the merging of the libffi3 branch took place in March, it broke
the logic in configure and fficonfig.py.in to deal with MIPS
architecture, specifically differentiating in which files to include
for MIPS_IRIX versus MIPS_LINUX. I've re-added that logic based on the
older code, and
If there's going to be another bug day, I'd like to see the problem of
getting patches from the bug tracker into Python addressed in some
way. It's kinda frustrating to work on things and not actually get to
close any issues because there are not enough people with commit
access taking part.
On Monday 05 January 2009 23:48:13 Malte Helmert wrote:
For people who are not core developers but would still like to
contribute, the Bug Days are quite exciting events. It would be great if
they could keep going.
As a not core developer, I would like to know what exactly that means.
;)
Uli
On Mon, Jan 5, 2009 at 9:10 AM, Duncan McGreggor
duncan.mcgreg...@gmail.com wrote:
Last Fall, Guido opened a ticket to include Google's ipaddr.py in the
standard lib:
http://bugs.python.org/issue3959
There has been some recent discussion on that ticket, enough so that
it might benefit
Leif Walsh writes:
True, most of the upgrade problems deal with packages that aren't in
the server install. This should be an easy one, but now I'd ask, why
not use Debian instead?
You mean, why not stick with Debian instead?wink
The reason is that Debian stable lags the real world
On 2009-01-03 04:15, Adam Olsen wrote:
On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg m...@egenix.com wrote:
On 2009-01-02 08:26, Adam Olsen wrote:
Python's malloc wrappers are pretty messy. Of your examples, only
unicode-str isn't obvious what the result is, as the rest are local
to that
On Mon, Jan 5, 2009 at 11:44 AM, Guido van Rossum gu...@python.org wrote:
On Mon, Jan 5, 2009 at 9:10 AM, Duncan McGreggor
duncan.mcgreg...@gmail.com wrote:
Last Fall, Guido opened a ticket to include Google's ipaddr.py in the
standard lib:
http://bugs.python.org/issue3959
There has been
Hi!
To craete this issue compilation [0] I use roundup through its web interface.
For example, to know which version names corresponds to each number, I
consulted them through:
http://bugs.python.org/version
But since two weeks ago, this list was trimmed down. I think that it
was to not be
Last Fall, Guido opened a ticket to include Google's ipaddr.py in the
standard lib:
http://bugs.python.org/issue3959
There has been some recent discussion on that ticket, enough so that
it might benefit everyone if it was moved on to the dev list. I do
recommend reading that ticket, though --
On Mon, Jan 5, 2009 at 00:53, Benjamin Peterson wrote:
On Sun, Jan 4, 2009 at 5:36 PM, s...@pobox.com wrote:
Since print is now a builtin function why is there still a PRINT_EXPR
opcode?
Benjamin I believe it's used in the interactive interpreter to display
Benjamin the repr
http://bugs.python.org/issue3582
I submitted a patch last august, but have had no comments. Any thoughts?
Here is a suggested update to thread_nt.c. It has two significant
changes:
1) it uses the new and safer _beginthreadex API to start a thread
2) it implements native TLS functions on NT,
Hello,
Amaury (mainly) and I are rewriting the IO stack in C, and there is a small
thing in PEP 3116 about the BufferedRandom object that I'd like to clarify:
« Q: Do we want to mandate in the specification that switching between reading
and writing on a read-write object implies a .flush()? Or
But since two weeks ago, this list was trimmed down. I think that it
was to not be able to submit bugs for older Python versions, which is
great, but there're some bugs assigned to older versions (for example,
[1]).
All true.
Should I use another way to query the version number-name
Funny, I was just looking at this code.
Anyway, whenever I need Unicode stuff as an argument, I use this idiom:
PyObject *uO;
PyObject *uU;
Py_UNICODE *u;
If (!PyArg_ParseTuple(args, O, uO)) return 0;
uU = PyUnicode_FromObject(uO);
if (!uU) return 0;
u = PyUnicode_AS_UNICODE(uU);
There is no
On Mon, Jan 5, 2009 at 12:01 PM, Antoine Pitrou solip...@pitrou.net wrote:
Amaury (mainly) and I are rewriting the IO stack in C,
Very cool!
and there is a small
thing in PEP 3116 about the BufferedRandom object that I'd like to clarify:
« Q: Do we want to mandate in the specification that
On 5/01/2009 11:13 PM, M.-A. Lemburg wrote:
See above. Assertions are not meant to be checked in a production
build. You use debug builds for debugging such low-level things.
Although ironically, assertions have been disabled in debug builds on
Windows - http://bugs.python.org/issue4804
If there's anything (be it a python-dev issue, or something for
python-committers, or a bug) that needs my attention, please resend.
In order to start getting work done today, I am archiving all
python-related email from the last 2.5 weeks unread that doesn't have
me explicitly in the To: or CC:
2009/1/5 Martin v. Löwis mar...@v.loewis.de:
All existing associations between versions and issues stay as they are.
I don't quite understand what the problem is. Yes, the versions were
retired (in roundup speak), and yes, issues that were originally
associated with the retired versions stay
21 matches
Mail list logo
