Guido van Rossum <[EMAIL PROTECTED]> added the comment:
It would break the symmetry with map().
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2186>
__
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Sorry, I will claim ignorance on this one. I don't recall the last time
I've used a bisection, but it was probably around the time bisect.py was
first added to the standard library. I do recall using heap sort as a
way to c
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Didn't you say it does sets too? Does this work?
a = [1, 2, 3]
{1, *a, 0, 4} # {0, 1, 2, 3, 4}
How about dicts?
kwds = {'z': 0, 'w': 12}
{'x': 1, 'y': 2, **kwds} # {'x': 1, &
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Looking at the flatten() example I'm curious -- how come the output of
>>> flatten(L)
is displayed as a list rather than as ?
Also, do I understand correctly that
yield *(1, 2, 3)
is equivalent to
yield 1
yield
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9674/unnamed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2292>
__
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file9675/unnamed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2292>
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Why can't this be closed?
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
Somebody will have to write the "What's new in 2.6" document. I'm doing
3.0 but I'm not doing 2.6 as well.
--
assignee: georg.brandl
components: Documentation
messages: 63591
nosy: georg.brandl, gva
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
I will be working on this.
--
assignee: gvanrossum
components: Documentation
messages: 63592
nosy: gvanrossum
priority: high
severity: normal
status: open
title: Update What's
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
A pickled str instance written by 2.6 currently unpickles under 3.0 as a
bytes instance. That would be correct if the intended use is binary
data, but it's wrong if the intended use is text. My hunch is that
there's more p
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
The built-in type structseq (used by e.g. os.stat() for the stat
structure and by the time module for a time tuple) resembles the new
namedtuple type added to the collections module in 2.6.
It would be nice if these had at least a
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
Georg Lingl has offered his xturtle for the standard library. Barring
showstopping problems with dependencies or code qualitiy I think this is
a good thing to add to 3.0 as a replacement for turtle, and to add to
2.6 while keepi
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
See http://mail.python.org/pipermail/python-dev/2008-March/077621.html
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
The 3.0 Misc/NEWS file is a mess. It is vastly incomplete because it
usually gets skipped during merges rather than resolving the conflicts.
--
assignee: georg.brandl
components: Documentation
messages: 63597
nosy: georg.
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
We should keep the ACKS files up to date. Have all the GHOP contributors
been added?
--
assignee: georg.brandl
components: Documentation
messages: 63598
nosy: georg.brandl, gvanrossum
priority: normal
severity: normal
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
The super() PEP currently is completely wrong w.r.t. reality. The
implementation is solid and won't change. The PEP just needs to be
rewritten to match reality.
--
assignee: georg.brandl
components: Documentati
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
(This is no longer the latest version. Gregor, mind uploading a newer one?)
--
nosy: +gvanrossum
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
So what did the email you sent look like?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2314>
__
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Any progress?
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1950>
__
_
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
So what's the syntax for setting multiple attributes via an email subject?
[assignee=+twouters,priority=low]?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Picky!
--
assignee: gvanrossum -> nnorwitz
nosy: +twouters
priority: immediate -> low
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
[assignee=guido]
Does it also work in the body of the message?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
No.
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2314>
__
___
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'd rather not label this as easy yet, since there's a decision to be
made. I would welcome a doc patch though!
Tracker <[EMAIL PROTECTED]>
<http://bu
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Confirmed. Ping, since you're looking at io.py anyway, can you fix this
too?
--
assignee: -> ping
nosy: +ping
priority: -> high
__
Tracker <[EMAIL PROTECTED]>
<http:/
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
assignee: georg.brandl -> akuchling
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2305>
__
___
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Sure. (Though sending pickles to 3.0 would still cause problems.
Consumers of pickled checksums would do wise to *always* take the CRC
mod 2**32 before doing comparisons.)
__
Tracker <[EMAIL
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
The issue is different; there is already a bug open for this (bug 2307).
--
nosy: +gvanrossum
resolution: -> invalid
status: open -> closed
superseder: -> Decide what to do with bytes/str when transferring pickl
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
We have a proposed solution for 2.x -> 3.x. In 3.x, an (8-bit) str
instance received from 2.x will be decoded into a (Unicode) str
instance. The encoding defaults to ASCII; you can specify a different
encoding and also an error
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
Barry, can you update the PEP with a discussion of the schedule, so we
can refer to it?
--
assignee: barry
components: Documentation
messages: 63686
nosy: barry, gvanrossum
priority: urgent
severity: normal
status: open
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Correct. Martin & I just discussed this. We'll empty the current 3.0
NEWS file and start adding stuff consistently from 3.0a3, but skipping
stuff merged from 3.0. For the big changes since 2.x, people will have
to refer t
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Brett meant to add 'builtins' as an alias for __builtin__. I don't
think we should do that. However we should have a fixer for this.
Assigning to Collin and changing the subject to match.
--
assignee: gvanr
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Checked in as r61467.
When pickling a bytes instance in a protocol < 3, it is pickled as a
user-defined type (essentially faking a __reduce__ operation) which can
be read back correctly in 3.0 but probably n
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I see no great advantage in having it backported, though I also don't
see no great harm.
Since we still use interning as an internal speed-up, I believe in
exposing the API, past discussions notwithstanding.
--
prior
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'll review this. My hunch is that we don't need this -- 2to3 takes
care of this so there is no reason to tell people to change their code
by hand.
(You may notice a pattern -- things that 2to3 can fix easily generally
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Let's not do this. This approach is not sufficiently backwards
compatible; it will break any code that uses isinstance(x, file). Even
though that's not forward compatible with 3.0, it works in 2.5 and
before, so it should
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Looks good, Neal. Are you hesitant to check this in? I ran a little
test showing that indeed it gives much more memory back to the system.
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTE
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'll review this once I address issue2291.
--
assignee: -> gvanrossum
nosy: +gvanrossum
priority: -> normal
__
Tracker <[EMAIL PROTECTED]>
<http:/
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I finally figured this out. The try/except statement is a complete red
herring; the problem is in the raise statement. The behavior is the
same in 2.4, 2.5 and 2.6, even though Exception is a classic class in
2.4 and a new-style cl
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
This is likely fixed; setting the status to pending and priority to low.
I believe this will eventually close it.
--
priority: normal -> low
status: open -> pending
__
Tracker <[
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Thanks!
Applied as r61475.
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
"except object:" will continue to be a no-op, if only for compatibility.
With -3 it will issue a warning (I just checked this in, from
issue2371). With -3 -Werror it will be an error.
We still need patches to issue
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
This is fun, but needs more work (see python-3000 thread).
I'm setting the priority to low, since I won't hold up a release to get
this in (if there's even a rough consensus).
--
assignee: gvanrossum -> tw
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'm setting this to critical to ensure that I will at least have a
thorough look at this before the release. I'm not sure whether I will
decide to address it or leave it alone.
--
priori
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Alex, can you please open a separate bug for that? The cross-posting of
comments is unhelpful, and the issue was not introduced by this patch.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I've checked a temporary work-around for that issue and another one in
r61478. This now has some false negatives; that's better than false
positives IMO.
__
Tracker <[EMAI
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'll set this to critical to ensure that I look at it at least once
before we release. I'm not sure however that we can do much about it --
nor that it matters much in practice.
Perhaps we could speed up certain common is
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Thanks!
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'll review this soon.
--
assignee: -> gvanrossum
nosy: +gvanrossum
priority: -> release blocker
__
Tracker <[EMAIL PROTECTED]>
<http:/
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'll review this soon.
--
assignee: -> gvanrossum
nosy: +gvanrossum
priority: critical -> release blocker
__
Tracker <[EMAIL PROTECTED]>
<http:/
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Checked in as r61486.
I tweaked your change slightly to compare the output of PyErr_Warn()
with -1.
The "minor" patch is incorrect IMO; the code where the comment was
originally is indeed normalizing the exception in a spe
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
keywords: +26backport, easy
priority: -> low
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2380>
__
_
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Cleaned up and committed as r61489.
Thanks!!
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Sorry, I have lots of other things to do before I get to this. It's too
late for 2.5.2; 2.5.3 won't be out until September or October 2008.
Please ping before then.
--
components: +Library (Lib) -Extension Module
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Sorry this missed the 2.5.2 release. I'll try to look again before
2.5.3 is imminent.
--
components: +Extension Modules -Library (Lib)
__
Tracker <[EMAIL PROTECTED]>
<ht
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Georg, can you whip up a bit of documentation for this? (Of course you
may find that the docs for io.py are lacking more than just this nit...)
--
assignee: gvanrossum -> georg.brandl
components: +Documentation -Lib
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Christian, I still see __file__ point to a .pyc file:
guido-macbookpro:~/p3 guido$ ./python.exe
Python 3.0a3+ (py3k:61464M, Mar 17 2008, 16:36:53)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "cop
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
This has now been included in the sandbox code for 2to3 and is slated
for inclusion in the Python trunk (and the py3k branch). Closing this
patch.
--
resolution: -> accepted
status: open -> closed
title: Elemen
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Brett, perhaps you can consider this with your integration of
import-rewritten-in-Python? I think it's fine to leave this alone for 2.6.
--
assignee: gvanrossum -> brett.cannon
components: +Interpreter C
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Let's make this a catch-all bug to remind us to ensure the build is
warning-free on as many platforms as possible.
--
priority: low -> critical
title: compiler warnings (gcc 2.96) -> compiler warnings
versions: +P
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
__cmp__ is not coming back.
--
priority: low -> normal
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
Due to blocked merges etc. I expect that some names appearing in the 2.6
ACKS file aren't in the 3.0 ACKS file. And possible the other way
around where backports are involved. I like this file to be as
inclusive as possible (
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Making sure I look at this at least once carefully before releasing.
--
assignee: -> gvanrossum
priority: -> critical
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Perhaps, though I'm not sure if that doesn't slow things down further
due to the complicated protocol for calling it. Also, there's a
recursion check in the built-in implementation.
_
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I know nothing about asyncore. Does this problem still exist in the
trunk (2.6)?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Yeah, but tp_ slots are expensive themselves (mostly in the amount of
code that needs to be changed -- see typeobject.c).
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Let's tentatively say this needs to go into 2.6. Bill, if in the end
you decide against it, just reject the patch.
--
priority: -> critical
versions: +Python 2.6 -Python 2.5
__
T
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> Do you mean "skipping stuff merged from 2.6" ?
Yes :)
__
Tracker <[EMAIL PROTECTED]>
<http
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'm still resounding -1 on this.
Grouping types together because they happen to be implemented in C is a
silly thing to do. Groupings should be based on usage, not on
implementation style. I successfully argued against the i
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
There isn't anything actionable in this bug request. It makes much more
sense to start a discussion about requirements etc. on python-ideas.
--
resolution: -> out of date
status:
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
pyepoll for static names sounds fine (assuming you want some consistency).
Given all the rave reviews, what are the chances that you'll be checking
this in soon?
__
Tracker <[EMAIL PRO
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
No time to review, but making a function return something useful instead
of None seems a good idea.
--
assignee: gvanrossum ->
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
assignee: -> loewis
nosy: +loewis
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue799428>
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On Fri, Mar 21, 2008 at 3:03 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>
> Okay. How about we use this like it is for 2.x, and split it ou
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Go.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1657>
__
___
Python-bugs-list mailing list
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> Well, okay. I still think we should expose these core interpreter types
> somehow, so people can identify types easily. I don't want to be forced
> to finding the type of sys._getframe to tell if I have a frame o
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
The USTimeZone example class hasn't been updated for the new US DST
rules that went into effect in 2007. For a description of the new
rules, see:
http://wwp.greenwichmeantime.com/daylight-saving-time/usa/d
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Hi Daniel,
Can you change it so that the start and end values are chosen
dynamically based on the year? I.e. if year < 2007 use the old values
otherwise use the new ones. A tzinfo object is supposed to (within
reason) handle h
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'd be okay with only covering 1987 and later. But it's probably good
to have a table-based solution anway, to make it easy to handle future
changes -- I'm sure 2007 is not the last
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
In 2.x, \u and \U are interpreted as Unicode escapes in
raw Unicode strings. That was a mistake, but we can't fix it (except
when using "from __future__ import unicode_literals"). In 3.0, \u or
\U in a r
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
title: \u and \U in raw strings have reverted -> \u and \U in raw strings have
regressed in 3.0a4
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
components: +Interpreter Core
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2557>
__
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
The docs still need to be updated! An entry in what's new in 3.0 should
also be added.
--
assignee: -> georg.brandl
components: +Documentation -Unicode
nosy: +georg.brandl, gvanrossum
status:
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Instead of "ignored" (which might be read ambiguously) how about "not
treated specially"?
You also still need to add some words to whatsnew.
__
Tracker <[EMAIL PROTECTED]>
&
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
What's dict unpacking? I hope it's not an implementation of this sad
idea posted recently:
{'a': x, 'b': y} = {'a': 42, 'b': 'hello'} # Same as x, y = 42, 'hello'
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I don't like that the patch changes the API of a function in
test_support() (in particular changing the return type; adding optional
arguments is not a problem). This could trip up 3rd party users of this
API. I recommend cre
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Thanks, that's much better (though I'm not the authority on all details
of this patch).
__
Tracker <[EMAIL PROTECTED]>
<http://
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I think we should either get this into the 3.0a5 release planned for May
7, or wait for 3.1. I'd prefer to see some kind of PEP discussion on
the python-3000 list, rather than just a BDFL approval in a tracker
issue. I think it
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Assigning anything not related to Py3k design to me is a mistake; I
don't have the bandwidth to handle this, sorry.
--
assignee: gvanrossum ->
__
Tracker <[EMAIL PROTECTED]>
<
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Please don't add to a closed issue that old. If you still have an issue
with this, please open a new issue. If you have a patch, kindly upload
it to the issue.
Tracker <[EMAIL PRO
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
To be honest, I don't know what the uses are for that codec.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Hm, can you use lowercase for the local variable names dststart and
dstend? Otherwise looks good.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
We went over this before. *I* consider the 2.x behavior a mistake, and
a decision was made to change in 3.0. It got much worse in 3.0 because
all literals are Unicode (except byte literals).
To add a unicode value to a raw string
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Barry, this sounds like a file you weren't aware of. Too late for
3.0a4, but perhaps you can add this to the roster of files to be looked
at for each release?
--
assignee: gvanrossum -> barr
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
In 3.0, r'\u1234' is a string of 6 characters (\, u, 1, 2, 3, 4). In
2.6, after "from __future__ import unicode_literals" it is a string of
one character (code point 0x1234). IMO the 3.0 behavior should be
i
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Thanks, looks good. Since this is assigned to Georg, can you check it
in, Georg?
Should this be backported to 2.5 docs as well?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> Do I understand correctly that non-starred arguments are packed into
> intermediate tuples/sets in the presence of starred arguments so that
> {a,b,*c,d,e} is equivalent to {*{a,b},*c,*{d,e}}? This should not be a
>
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I agree with Thomas. The order in which __hash__() is evaluated
shouldn't matter to your app; if __hash__() isn't a pure function (apart
from possible caching) you've got worse trouble.
_
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1736190>
_
___
Python-bugs-list mailing list
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I don't think this ought to be changed in exec(). It ought to be done
by opening the file using universal newlines.
--
resolution: -> rejected
status: open -> closed
__
Tracker
1501 - 1600 of 5533 matches
Mail list logo
