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.
;)
U
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.
It'd
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 adjus
On Mon, Jan 5, 2009 at 8:13 PM, Terry Reedy wrote:
> 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 o
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 implementatio
On Mon, Jan 5, 2009 at 8:44 PM, Antoine Pitrou wrote:
>
> Hello,
>
> Malte Helmert 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
Hello,
Malte Helmert 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 month
A merger sounds like a good way forward.
It shouldn't be as painful as it might sound initially and there should be
lots of room for some early big wins.
Contentious Issues
--
*** Separate IP and CIDR classes
The IP and CIDR object split in netaddr is going to require some furth
2009/1/5 "Martin v. Löwis" :
> 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 associated.
Dear python-dev group,
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 month.
For people who are not core developers but w
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: he
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
Che
On Mon, Jan 5, 2009 at 12:01 PM, Antoine Pitrou 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 switching betwe
>> How about a merger?
>
> I think that's a brilliant idea. David and Peter, logistics aside,
> what do you think of (or how to you feel about) this suggestion?
the devil, as they say, is in the details :). I'd be interested to
know what form this merger would take. WRT v4/v6 manipulation, it
see
> 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 rel
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
On Mon, Jan 5, 2009 at 4:25 AM, Amaury Forgeot d'Arc wrote:
> On Mon, Jan 5, 2009 at 00:53, Benjamin Peterson wrote:
>> On Sun, Jan 4, 2009 at 5:36 PM, wrote:
>>>
>>>>> Since print is now a builtin function why is there still a PRINT_EXPR
>>>>> opcode?
>>>
>>>Benjamin> I believe it's
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 ab
On Mon, Jan 5, 2009 at 11:44 AM, Guido van Rossum wrote:
> On Mon, Jan 5, 2009 at 9:10 AM, Duncan McGreggor
> 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 t
On Mon, Jan 5, 2009 at 9:10 AM, Duncan McGreggor
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 everyone if it was moved o
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 -- lo
Our of curiousity, why are these constants for internal use only?
Is there concern that people might start using "is", or is it just to
keep the (beyond the spec) API small, or ...?
-jJ
On Fri, Jan 2, 2009 at 6:07 PM, mark. dickinson
wrote:
> Author: mark.dickinson
> Date: Sat Jan 3 00:07:08 2
On Mon, Jan 5, 2009 at 00:53, Benjamin Peterson wrote:
> On Sun, Jan 4, 2009 at 5:36 PM, 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 r
On 2009-01-03 04:15, Adam Olsen wrote:
> On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg 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 functi
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 au
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?"
The reason is that Debian stable lags the real world drama
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, whic
27 matches
Mail list logo
