This is a very long line.  I am wondering how it will be wrapped. What
will happen to this exceedingly long line? Will it be wrapped? Will it?
Really? What will happen?

Here's an example:

  def fact(n):
    if n > 1:
      return n * fact(n-1)
    else:
      assert n in (0, 1)
      return 1

What do you think of that?

Testing authorage

Does this still work?

More testing.

Testing 1..2..3

Reviewers: ,

Description:
"This is a very long line.  I am wondering how it will be wrapped. What
will happen to this exceedingly long line? Will it be wrapped? Will it?
Really? What will happen?

Here's an example:

   def fact(n):
     if n > 1:
       return n * fact(n-1)
     else:
       assert n in (0, 1)
       return 1

What do you think of that?"

Please review this at http://codereview.appspot.com/24075

Affected files:
   M     static/upload.py

Index: static/upload.py
===================================================================
--- static/upload.py	(revision 402)
+++ static/upload.py	(working copy)
@@ -61,7 +61,30 @@
  # Max size of patch or base file.
  MAX_UPLOAD_SIZE = 900 * 1024

+#python static/upload.py -R 2771 -F msg66272 --send_mail
+fields = {'issue':'title', 'msg':'content', 'file':'description', }
+def fetch_item(nodeid, kind='issue', tracker='http://bugs.python.org'):
+  query_tpl = [('@action', 'export_csv'), ('@filter', 'id'),
+  ('id', nodeid), ('@columns', fields[kind])]
+  item_url = '/%s?%s' % (kind, urllib.urlencode(query_tpl))
+  content = urllib.urlopen(tracker + item_url).read().split('\r\n')
+  if content[0] == 'title':
+    return '[issue%s] %s' % (nodeid, content[1].strip())
+  elif content[0] == 'content' or content[0] == 'description':
+    return content[1].strip()

+def fetch(nodeid, debug=True):
+  kind = 'issue'
+  if nodeid.startswith('msg'):
+    kind = 'msg'
+  elif nodeid.startswith('file'):
+    kind = 'file'
+  nodeid = nodeid.replace(kind, '')
+  result = fetch_item(int(nodeid), kind)
+  if debug:
+    logging.info('Fetched "%s: %s"' % (kind, result))
+  return result
+
  def GetEmail(prompt):
    """Prompts the user for their email address and returns it.

@@ -453,6 +476,14 @@
  group.add_option("--send_mail", action="store_true",
                   dest="send_mail", default=False,
                   help="Send notification email to reviewers.")
+# Link options
+group = parser.add_option_group("Link options")
+group.add_option("-R", "--roundup", action="store", dest="roundup",
+                 metavar="ROUNDUP", default=None,
+                 help="Python tracker issue number to link with.")
+group.add_option("-F", "--fetch_descr", action="store", dest="fetch_descr",
+                 metavar="FETCHDESCR", default=None,
+                 help="Tracker file or message to fetch description from.")

  def GetRpcServer(options):
@@ -1291,7 +1322,10 @@
      prompt = "Message describing this patch set: "
    else:
      prompt = "New issue subject: "
-  message = options.message or raw_input(prompt).strip()
+  if options.roundup:
+    message = fetch(options.roundup)
+  else:
+    message = options.message or raw_input(prompt).strip()
    if not message:
      ErrorExit("A non-empty message is required")
    rpc_server = GetRpcServer(options)
@@ -1307,11 +1341,16 @@
        if "@" in reviewer and not reviewer.split("@")[1].count(".") == 1:
          ErrorExit("Invalid email address: %s" % reviewer)
      form_fields.append(("reviewers", options.reviewers))
+  tracker_email = 'report@bugs.python.org,'
    if options.cc:
      for cc in options.cc.split(','):
        if "@" in cc and not cc.split("@")[1].count(".") == 1:
          ErrorExit("Invalid email address: %s" % cc)
-    form_fields.append(("cc", options.cc))
+    if options.roundup:
+      cc = tracker_email + options.cc
+    form_fields.append(("cc", cc))
+  elif options.roundup:
+    form_fields.append(("cc", tracker_email[:-1]))
    description = options.description
    if options.description_file:
      if options.description:
@@ -1319,6 +1358,9 @@
      file = open(options.description_file, 'r')
      description = file.read()
      file.close()
+  elif options.fetch_descr:
+    # XXX Add error handling as above
+    description = fetch(options.fetch_descr)
    if description:
      form_fields.append(("description", description))
    # Send a hash of all the base file so the server can determine if a copy

http://codereview.appspot.com/24075

Reviewers: ,

Description:
 From http://bugs.python.org/issue2771

"This is a very long line.  I am wondering how it will be wrapped. What
will happen to this exceedingly long line? Will it be wrapped? Will it?
Really? What will happen?

Here's an example:

   def fact(n):
     if n > 1:
       return n * fact(n-1)
     else:
       assert n in (0, 1)
       return 1

What do you think of that?"

Description fetched from: http://bugs.python.org/msg66272

Please review this at http://codereview.appspot.com/25076

Affected files:
   M     static/upload.py

Reviewers: ,

Description:
 From http://bugs.python.org/issue2771

Testing 1..2..3

Description fetched from: http://bugs.python.org/msg82496

Please review this at http://codereview.appspot.com/22062

Affected files:
   M     static/upload.py

Testing how email handles quotes.

[mailgw]

# Keep email citations when accepting messages.
# Setting this to "no" strips out "quoted" text from the message.
# Signatures are also stripped.
# Allowed values: yes, no
# Default: yes
keep_quoted_text = yes

# Preserve the email body as is - that is,
# keep the citations _and_ signatures.
# Allowed values: yes, no
# Default: no
leave_body_unchanged = no

Dumb whole message quote.

On Tue, Apr 7, 2009 at 11:51 AM, Daniel Diniz <report@bugs.python.org> wrote:
>
> Daniel Diniz <ajaksu@gmail.com> added the comment:
>
> Testing how email handles quotes.
>
> [mailgw]
>
> # Keep email citations when accepting messages.
> # Setting this to "no" strips out "quoted" text from the message.
> # Signatures are also stripped.
> # Allowed values: yes, no
> # Default: yes
> keep_quoted_text = yes
>
> # Preserve the email body as is - that is,
> # keep the citations _and_ signatures.
> # Allowed values: yes, no
> # Default: no
> leave_body_unchanged = no
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue2771>
> _______________________________________
>

Nested quotes.

On Tue, Apr 7, 2009 at 11:53 AM, Daniel Diniz <report@bugs.python.org> wrote:
>
> Daniel Diniz <ajaksu@gmail.com> added the comment:
>
> Dumb whole message quote.
>
> On Tue, Apr 7, 2009 at 11:51 AM, Daniel Diniz <report@bugs.python.org> wrote:
>>
>> Daniel Diniz <ajaksu@gmail.com> added the comment:
>>
>> Testing how email handles quotes.
>>
>> [mailgw]
>>
>> # Keep email citations when accepting messages.
>> # Setting this to "no" strips out "quoted" text from the message.
>> # Signatures are also stripped.
>> # Allowed values: yes, no
>> # Default: yes
>> keep_quoted_text = yes
>>
>> # Preserve the email body as is - that is,
>> # keep the citations _and_ signatures.
>> # Allowed values: yes, no
>> # Default: no
>> leave_body_unchanged = no
>>
>> ----------
>>
>> _______________________________________
>> Python tracker <report@bugs.python.org>
>> <http://bugs.python.org/issue2771>
>> _______________________________________
>>
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue2771>
> _______________________________________
>

>>> Testing how email handles quotes.
>>>
>>> [mailgw]
>>>
>>> # Keep email citations when accepting messages.
>>> # Setting this to "no" strips out "quoted" text from the message.
>>> # Signatures are also stripped.
>>> # Allowed values: yes, no
>>> # Default: yes
>>> keep_quoted_text = yes
>>>
>>> # Preserve the email body as is - that is,
>>> # keep the citations _and_ signatures.
>>> # Allowed values: yes, no
>>> # Default: no
>>> leave_body_unchanged = no
>>>

Bottom posting, less hints about quotes.

> The reason I noticed this is that since they compare and hash equal, if
> you put two such methods into a set, you end up with a set with one
> method.  Currently, this is preventing me from running two test methods
> because the method itself is defined on a base class and two subclasses
> which customize several other methods inherit it.  I can only run one
> test at a time.

But you acknowledge they are really the same method attached to
different classes, right? The notion of "unbound method" is mostly an
implementation detail. The term occurs only 4 times in the whole Python
documentation (according to Google). And in py3k they are gone. (*)

Moreover, you say you want them to compare unequal because you
*explicitly* want the same method called separately for each class it is
defined on. Is there anything preventing you to have a set of (class,
method) tuples instead? Because it sounds like the logical thing to do
in your case.

> Having them compare unequal means you can't actually trust unbound
> method comparison, nor using unbound methods as keys in a dictionary.

"Trust" is a strong word. You can trust the comparison operator if you
agree with its semantics, you cannot trust it if you want different
semantics. But that doesn't mean it is generally trustworthy or
untrustworthy.

Really, this is the same as with numbers:

'b'

There are probably use cases where the above is annoying. But,
conversely, there are probably use cases where a stricter behaviour
would be annoying too.

> This means some other mapping structure is required if you want to keep
> around a bunch of methods and arguments to pass to them.

I disagree. The general use case of keeping a bunch of callables with
their respective arguments implies storing bound, not unbound, methods.
(how often do you feed an unbound method to an addCallback() ?)

> It also means
> that any time you want to check two methods against each other with the
> goal of eventually calling one or both of them, you need to use
> something other than `==´.

I don't think there are lots of use cases for comparing *unbound*
methods. One such use case is checking for redefinition of inherited
methods, and the current __eq__ semantics look fine for that.

(*)
Python 3.0b2+ (py3k, Jul 29 2008, 20:37:34)
[GCC 4.3.1 20080626 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
...  def f(): pass
...
>>> type(A.f)
<class 'function'>
>>> a = A()
>>> type(a.f)
<class 'method'>
>>> def g(): pass
...
>>> class B:
...  g = g
...
>>> B.g is g
True

> Having them compare unequal means you can't actually trust unbound
> method comparison, nor using unbound methods as keys in a dictionary.

"Trust" is a strong word. You can trust the comparison operator if you
agree with its semantics, you cannot trust it if you want different
semantics. But that doesn't mean it is generally trustworthy or
untrustworthy.

Really, this is the same as with numbers:

'b'

> Quote

Unquote

code snippet:

'b'

Attach some file

testing autonosy for release managers with release blockers

Works fine. Now release managers will be added automatically to the nosy list when the priority of an issue is set to 'release blocker'.
See http://psf.upfronthosting.co.za/roundup/meta/issue363

Testing legacy svn references here r88479 and new hg references here 284026e00342.

test the roundup hook
http://hg.python.org/cpythonb48aeb097432

test the roundup hook again
http://hg.python.org/cpython/dfc4a58fc2d4

test the roundup hook another time
http://hg.python.org/cpython/65f5077e877b

test the roundup hook another time
http://hg.python.org/cpython/8f21aec26226

test the roundup hook another time
http://hg.python.org/cpython/cf074b297bf9

test the roundup hook another time
http://hg.python.org/cpython/502f0683b161

: test the refactored roundup hook.
http://hg.python.org/cpython/cd21195d07ca

re bug 2771 -- testing the roundup hook.
http://hg.python.org/cpython/c37da7946f2b

finally fixing issue 2771: yay!
http://hg.python.org/cpython/440238c16a7a

> re bug 2771 -- testing the roundup hook.
> http://hg.python.org/cpython/c37da7946f2b

Looks like this URL misses the "/rev/" before the changeset id.

Changeset b92334d06445 by Antoine Pitrou <solipsis@pitrou.net>:
Issue #2771: fixing frobnicator\nI hope this works

New changeset ef6738f4ba2e by Antoine Pitrou <solipsis@pitrou.net>:
Issue #2771: fixing frobnicator again!

New changeset ef6738f4ba2e by Antoine Pitrou:
Issue #2771: fixing frobnicator again!

New changeset ef6738f4ba2e by Antoine Pitrou:
Issue #2771: fixing frobnicator again!

New changeset ef6738f4ba2e by Antoine Pitrou:
Issue #2771: fixing frobnicator again!

New changeset ef6738f4ba2e by Antoine Pitrou:
Issue #2771: fixing frobnicator again!
http://hg.python.org/cpython/rev/ef6738f4ba2e

New changeset ef6738f4ba2e by Antoine Pitrou:
Issue #2771: fixing frobnicator again!
http://hg.python.org/cpython/rev/ef6738f4ba2e

New changeset ef6738f4ba2e by Antoine Pitrou:
Issue #2771: fixing frobnicator again!
http://hg.python.org/test/rev/ef6738f4ba2e

New changeset ef6738f4ba2e by Antoine Pitrou in branch 'default':
Issue #2771: fixing frobnicator again!
http://hg.python.org/test/rev/ef6738f4ba2e

New changeset ef6738f4ba2e by Antoine Pitrou in branch 'default':
Issue #2771: fixing frobnicator again!
/rev/ef6738f4ba2e

New changeset ef6738f4ba2e by Antoine Pitrou in branch 'default':
Issue #2771: fixing frobnicator again!
http://hg.python.org/test/rev/ef6738f4ba2e

New changeset ef6738f4ba2e by Antoine Pitrou in branch 'default':
Issue #2771: fixing frobnicator again!
http://hg.python.org/test/rev/ef6738f4ba2e

New changeset a25e4c9f7b3a by éléphant in branch 'default':
Issue #2771: héhé
http://hg.python.org/test/rev/a25e4c9f7b3a

New changeset 93a15af3a8ce by Antoine Pitrou in branch 'default':
fixes #2771
http://hg.python.org/test/rev/93a15af3a8ce

New changeset acd842ea10e6 by Antoine Pitrou in branch 'default':
closes #2771
http://hg.python.org/test/rev/acd842ea10e6

New changeset e51cd925a89a by Ezio Melotti in branch 'default':
Test hook (closes #2771).
http://hg.python.org/test/rev/e51cd925a89a

testing nosy

testing again

testing nosy

Testing

New changeset 90586887032e by Ezio Melotti in branch 'default':
test: change the content of the p file so
http://hg.python.org/test/rev/90586887032e

Testing.

testing

adsfaf

test attachments

test attachments

test attachments

Adding 

# ignore html part of multipart/alternative
ignore_alternatives = yes

to the config.ini seems to get rid of the "unnamed" attachments.

New changeset 0e94d9bef251 by Ezio Melotti in branch 'default':
Closes #2771. #13388 now needs to be updated.
http://hg.python.org/test/rev/0e94d9bef251

New changeset e4fcac92a80a by Ezio Melotti in branch 'default':
Closes #2771. #13388 now needs to be updated.
http://hg.python.org/test/rev/e4fcac92a80a

New changeset fc1e01fe7f30 by Antoine Pitrou in branch 'default':
test hook with issue #2771.
http://hg.python.org/test/rev/fc1e01fe7f30

Let’s link to branches other than default: Lib/fileinput.py, Python/bltinmodule.c:42

Testing links:
http://bugs.python.org/issue2771
http://bugs.python.org/issue2771.
http://bugs.python.org/issue2771,
http://bugs.python.org/issue2771;
http://bugs.python.org/issue2771:
http://bugs.python.org/issue2771!
(http://bugs.python.org/issue2771)
[http://bugs.python.org/issue2771]
{http://bugs.python.org/issue2771}
<http://bugs.python.org/issue2771>

This is a test email reply with no MIME header.

New changeset b449118653fe by Antoine Pitrou in branch 'default':
some new tést (issue #2771)
http://hg.python.org/test/rev/b449118653fe

New changeset b4af3925bda6 by Antoine Pitrou in branch 'default':
some new tést (issue #2771)
http://hg.python.org/test/rev/b4af3925bda6

New changeset 3e4513003ded by Antoine Pitrou in branch 'default':
some new tést (issue #2771)
http://hg.python.org/test/rev/3e4513003ded

New changeset b449118653fe by Antoine Pitrou in branch 'default':
some new tést (issue #2771)
http://hg.python.org/test/rev/b449118653fe

New changeset 99fbc7dfb076 by Antoine Pitrou in branch 'default':
some new tést (issue #2771)
http://hg.python.org/test/rev/99fbc7dfb076

New changeset b4af3925bda6 by Antoine Pitrou in branch 'default':
some new tést (issue #2771)
http://hg.python.org/test/rev/b4af3925bda6

New changeset 76da38684c9d by Antoine Pitrou in branch 'default':
some other test (issue #2771)
http://hg.python.org/test/rev/76da38684c9d

test

test issue linking: issue1528167 issue 1528167 #1528167

testing irker

Another irker test

Another irker test

ᚠᚡᚢᚣᚤᚥᚦᚧᚨᚩᚪᚫᚬᚭᚮᚯᚰᚱᚲᚳᚴᚵᚶᚷᚸᚹᚺᚻᚼᚽᚾᚿᛀᛁᛂᛃᛄ

ᚠᚡᚢᚣᚤᚥᚦᚧᚨᚩᚪᚫᚬᚭᚮᚯᚰᚱᚲᚳᚴᚵᚶᚷᚸᚹᚺᚻᚼᚽᚾᚿᛀᛁᛂᛃᛄ

another test

test

another test

testing the new version of irker

another test

test

test

another test

another test

test

another test

final test

New changeset 47ae836aa221 by Antoine Pitrou in branch 'default':
Issue #2771: !!
http://hg.python.org/test/rev/47ae836aa221

irker test

Test new irker.

test

test

msg137617
message 137617
message #137617

testing

Lib/smtplib.py#l226
Lib/smtplib.py:l226
Lib/smtplib.py#226
Lib/smtplib.py:226

Ping.

test after roundup upgrade

test message via email

another test

Ping.

mail pong

test

New changeset 8510224e05dc by Georg Brandl in branch 'default':
Closes #2771: test.
http://hg.python.org/test/rev/8510224e05dc

New changeset e79d1244d887 by Georg Brandl in branch 'default':
#2771: test baseurl change.
https://hg.python.org/test/rev/e79d1244d887

ping

test after roundup upgrade

test message via email

Test

Testing PR linking

Testing that the link to PR 46 works.
Pull Request 46 should also be a link.
PullRequest 46 too.
Generally you should just use PR46.

testing github integration

another test

test

test pr status

test

𝔹𝔹

test

test

test

test

A test comment from nedbat

test comment

Also a test.

another test

mail test

test comment

> I think I have seen this bug reported elsewhere but can't find it now.

Sorry, I was referring to issue6028 and issue32570 that I thought were similar to the original report.

Testing after hosting migration completion

test message via email

comment on test issue to test the request time.

test comment

test mail sending

should be fast send.

test

notifying a lot of people

irc pong

Test Email Notification

Test Notification

test comment

test comment

test comment

test IRC bot

Close (test IRC bot). Test is successful!

"09:18 < irker301> vstinner #2771/Test issue: [open] test IRC bot https://bugs.python.org/issue2771" logged on #python-dev-infras

https://github.com/python/psf-salt/issues/208#event-4790301517

Test IRC

Testing GitHub mentions, please ignore: @serhiy-storchaka

So long, and thanks for all the bugs.