Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28180>
___
__
Barry A. Warsaw added the comment:
On Dec 12, 2016, at 04:16 PM, Guido van Rossum wrote:
>So the proposal would be: prune=False -> empty strings stay, prune=True,
>empty strings are dropped, prune=None (default) use True if sep is None,
>False otherwise. Right?
Yep!
>
Barry A. Warsaw added the comment:
I really appreciate all the feedback. Here are some thoughts.
I'm well aware of the filter(), re, and other options, and certainly those can
be made to work, but they're non-obvious. The reason I suggested an
enhancement to str.split() is because I've seen
Barry A. Warsaw added the comment:
On Dec 11, 2016, at 03:57 PM, Serhiy Storchaka wrote:
>I meant adding boolean argument that changes the behavior when sep is None,
>not when it is not None.
Ah, I understand now, thanks. However, I'm not sure that addresses my
particular use case.
Barry A. Warsaw added the comment:
On Dec 11, 2016, at 03:32 PM, Serhiy Storchaka wrote:
>Current behavior is consistent with str.count():
>
>len(string.split(sep)) == string.count(sep) + 1
>
>and re.split():
>
>re.split(re.escape(sep), string) == string.split(sep)
New submission from Barry A. Warsaw:
This has finally bugged me enough to file an issue, although I wouldn't be able
to use it until Python 3.7. There's a subtle but documented difference in
str.split() when sep=None:
>>> help(''.split)
Help on built-in function split:
split(..
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28833>
___
__
Barry A. Warsaw added the comment:
On Nov 22, 2016, at 07:28 PM, Serhiy Storchaka wrote:
>The reason for disallowing some undefined escapes is the same as in pattern
>strings: this would allow as to introduce new special escape sequences.
I'll note that technically speaking, you can
Changes by Barry A. Warsaw <ba...@python.org>:
--
priority: release blocker -> normal
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Barry A. Warsaw added the comment:
I disagree that the documentation is at fault. This is known to break existing
code, e.g. http://bugs.python.org/msg281496
I think it's not correct to change the documentation but leave the
error-raising behavior for 3.6 because the deprecation was never
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +ned.deily
priority: normal -> release blocker
status: closed -> open
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Barry A. Warsaw added the comment:
On Nov 22, 2016, at 04:13 PM, Serhiy Storchaka wrote:
>Could Mailman be fixed? Undefined combinations of \ + ASCII emitted warnings
>in 3.5. And now they emit warnings even just in string literals
>(issue27364). If Mailman use undefined escape com
Barry A. Warsaw added the comment:
Specifically, point #2; undefined combinations of \ + ASCII becoming an error.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Barry A. Warsaw added the comment:
FWIW, this breaks Mailman 3.1 (and probably 2.1)
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Barry A. Warsaw added the comment:
On Oct 29, 2016, at 02:20 AM, Martin Panter wrote:
>Here is a patch to parse the version from the request in more cases. Since it
>is more of a cosmetic improvement for handling erroneous requests, I would
>probably only apply it to the next Pytho
Barry A. Warsaw added the comment:
On Oct 28, 2016, at 10:57 PM, Martin Panter wrote:
>Parsing the version from words[-1] rather than words[2] may be a minor
>improvement however.
Indeed; I thought about that too.
--
___
Python tracke
Barry A. Warsaw added the comment:
On Oct 28, 2016, at 10:42 PM, Martin Panter wrote:
>I think you should be able to reproduce this without Mailman or tox, by just
>running “python -m http.server”.
Yep, indeed.
>The problem is the “HTTP/0.9” protocol that Python is assuming does not
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26578>
___
__
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10721>
___
__
New submission from Barry A. Warsaw:
This might also affect other Python version; I haven't checked, but I know it
affects Python 3.5.
In Mailman 3, we have a subclass of WSGIRequestHandler for our REST API, and we
got a bug report about an error condition returning a 400 in the body
Barry A. Warsaw added the comment:
While I was reviewing
https://gitlab.com/mailman/mailman/merge_requests/197/diffs I noticed the
KeyError and it made me thing "hmm, I wonder if this should be turned into one
of the email package e
Barry A. Warsaw added the comment:
On Sep 24, 2016, at 05:06 PM, R. David Murray wrote:
>Barry, would you care to render an opinion on this proposed fix?
I think the general approach is probably the best you can do. I noticed a
couple of things though with RDM's v.2 patch.
First, I get t
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17218>
___
__
Barry A. Warsaw added the comment:
The workaround is to do something like:
group = parser.add_argument_group(title, description)
me_group = group.add_mutually_exclusive_group()
me_group.add_argument(...blah blah blah...)
--
___
Python tracker <
Barry A. Warsaw added the comment:
Hmm, it might be more complicated than that, so let's ignore 3.6
--
versions: -Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Barry A. Warsaw:
I'd love to sneak this into 3.6, but I can accept being too late. In any case,
_MutuallyExclusiveGroup.__init__() should accept title and description
arguments and pass them to the super class. Otherwise, you can't great a
mutually exclusive group
New submission from Barry A. Warsaw:
Sometimes we want to control the order of arguments printed by an argparse
defined cli. In practice, arguments are printed in the order in which they are
added via add_argument(), but I don't think this is documented and thus should
be considered
Barry A. Warsaw added the comment:
I'm -1 also, mostly on the grounds that it's not (IME) a very common need and
it does clutter up the API.
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28160>
___
__
Barry A. Warsaw added the comment:
Two things: is it worth fixing this bug given the impending move to github?
Also, why is this reported here and not the pydotorg tracker?
https://github.com/python/pythondotorg/issues
Given that the last comment was 2014, I'm going to go ahead and close
Barry A. Warsaw added the comment:
Thanks Steve! Closing.
--
nosy: +barry
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Barry A. Warsaw added the comment:
I think this bug actually is fixed now. I've tried my previously failing case
in Python 3.5 and 3.6 head and I don't get the error.
--
resolution: -> out of date
status: open -> closed
___
Python tracke
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28086>
___
__
Barry A. Warsaw added the comment:
On Sep 09, 2016, at 08:30 PM, Terry J. Reedy wrote:
>I think we should definitely fall back to using the .py file. A cache is an
>implementation convenience, not a language feature.
+1. If the cache is corrupt, it should be ignored and rec
Barry A. Warsaw added the comment:
LGTM +1
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27988>
___
___
Python-bugs-list
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27997>
___
__
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27921>
___
__
Barry A. Warsaw added the comment:
I meant .items()
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18139>
___
___
Python-bugs-
Barry A. Warsaw added the comment:
I've updated this to Python 3.6, but I don't know if there's time to design an
API and implementation in the time left before beta 1. But a use case has come
up, so I want to reboot this discussion (yes, it should go to email-sig too).
Apparently ARC
Changes by Barry A. Warsaw <ba...@python.org>:
--
versions: +Python 3.6 -Python 3.4
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27814>
___
__
Barry A. Warsaw added the comment:
Hey, I just realized that you can get pretty darn close with just a little bit
of extra typing, and existing stdlib:
from enum import Enum
from itertools import count
auto = count()
class Color(Enum):
red = next(auto)
green
Barry A. Warsaw added the comment:
Ethan, the suggestion has come up several times about using a dummy value such
as the empty tuple to do autonumbering, thus looking more Pythonic. I'm not a
huge fan of the empty tuple, and I'm still not sure whether we need this, but I
wonder if it would
Barry A. Warsaw added the comment:
On Jul 11, 2016, at 07:05 PM, Ethan Furman wrote:
>class BaseZeroEnum(Enum, start=0):
> "initial integer is 0"
> ...
>
>? Oh, and yes if you specify a starting number you also activate the
>AutoNumber feature.
I
Barry A. Warsaw added the comment:
On Jul 11, 2016, at 12:27 AM, Ethan Furman wrote:
>Not sure. At this point I have the stdlib enum, enum34 enum, and aenum enum.
>
>In terms of capability, aenum is the most advanced, followed by the stdlib
>enum, and finally enum34 (really the onl
Barry A. Warsaw added the comment:
On Jul 10, 2016, at 05:42 PM, Ethan Furman wrote:
>class Color(Enum, settings=AutoNumber):
[...]
>class Color(Enum, settings=AutoName):
I guess `settings` would take an AutoType enum. But that can't also be
autonumbered or it would be autos all the wa
Barry A. Warsaw added the comment:
On Jul 09, 2016, at 03:20 PM, Ethan Furman wrote:
>As far as I can tell there is only one "good" way around this:
>
>- store any names you don't want auto-numbered into an `_ignore_`
> attribute (this only needs to be glo
Barry A. Warsaw added the comment:
On Jun 13, 2016, at 08:34 AM, Berker Peksag wrote:
>Berker Peksag added the comment:
>
>> I think we just need to plumb a `policy` argument through to the ultimate
>> base class, email.message.Message
>
>That's already possible:
>
Barry A. Warsaw added the comment:
On Jun 13, 2016, at 06:38 AM, Berker Peksag wrote:
>I don't know if it's a good idea or API but can we add a 'policy' keyword
>argument to email.mime.base.MIMEBase? Right now, this is the only way to
>change the default policy without using h
Barry A. Warsaw added the comment:
On Jun 12, 2016, at 09:19 PM, Raymond Hettinger wrote:
>Would you consider raising an exception at least for the case of a "To:"
>header or perhaps a warning or someother failsafe.
No, not for compat32 policy. Seriously, I do not want to chan
Barry A. Warsaw added the comment:
On Jun 13, 2016, at 12:09 AM, Martin Panter wrote:
>I think I would support deprecating the __setitem__() etc methods, perhaps
>with a cleanup of the alternatives, e.g. add remove_all(). Also,
>__getitem__() is equivalent to get(), which does
Barry A. Warsaw added the comment:
On Jun 11, 2016, at 09:25 PM, Raymond Hettinger wrote:
>I think we should consider this as an API design bug and backport the fix.
No, it's deliberate, required, and expected in some cases as RDM explains.
Certainly for compat32 policy, this can't cha
Changes by Barry A. Warsaw <ba...@python.org>:
--
resolution: -> fixed
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Barry A. Warsaw added the comment:
Thanks Ian. I'm going to apply that, but rephrase it a bit.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Barry A. Warsaw added the comment:
Thanks for the patch!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27187>
___
___
Pyth
Barry A. Warsaw added the comment:
On Jun 04, 2016, at 07:47 PM, Zachary Ware wrote:
>So, +1 anyway. I think this would be rather worthwhile, especially in the
>stdlib.
Thanks!
I still like it and plan on continuing to use it in my code. I would
recommend you playing with the third
Changes by Barry A. Warsaw <ba...@python.org>:
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
New submission from Barry A. Warsaw:
PEP 8 says:
Put any relevant __all__ specification after the imports.
I don't remember why we wanted __all__ to go after imports. I think we should
relax that since other dunders can go before imports.
See related PYCQA issue: https://github.com/PyCQA
Barry A. Warsaw added the comment:
I'm going to go ahead and close this issue. There wasn't much positive
reception to @public in the Pycon 2016 language summit (where I presented it as
a lightning talk).
https://gitlab.com/warsaw/public
Some of the other ideas for changes to Python may
Barry A. Warsaw added the comment:
This is definitely not the right place to discuss this. Please use the Mailman
3 users mailing list or the Mailman Developers mailing list.
https://lists.mailman3.org/archives/list/mailman-us...@mailman3.org/
https://mail.python.org/mailman/listinfo/mailman
Barry A. Warsaw added the comment:
On May 28, 2016, at 12:26 AM, Rubén Rivero Capriles wrote:
>While: Installing mailman.
Which version of Mailman? Mailman 2.1 is not compatible with Python 3,
Mailman 3.0 is only compatible with Python 3.4, and Mailman 3.1 (not yet
relea
Barry A. Warsaw added the comment:
On May 25, 2016, at 07:56 AM, Franklin? Lee wrote:
>>AttributeError: 'tuple' object has no attribute 'append'
>>which seems pretty obvious.
>
>I don't think the C version shows a traceback, so it won't be clear that
>you're trying
Barry A. Warsaw added the comment:
On May 24, 2016, at 08:48 PM, R. David Murray wrote:
>Maybe we should blacklist MailmanProxy? I think we are planning to deprecate
>it but just haven't yet done the work. Looks fine otherwise.
It's probably not used much TBH. aiosmtpd has a generic
Barry A. Warsaw added the comment:
BTW, I may wait to commit this until after we've moved to GitHub. :)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Barry A. Warsaw added the comment:
On May 23, 2016, at 02:43 PM, Franklin? Lee wrote:
>I sometimes wrap functions that return iterators to make functions that
>return lists, because I work on the interpreter a lot. From there, it's not
>much of a stretch to imagine functi
Changes by Barry A. Warsaw <ba...@python.org>:
Added file: http://bugs.python.org/file42956/27066-2.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Barry A. Warsaw added the comment:
On May 22, 2016, at 11:30 PM, Martin Panter wrote:
>Here are two examples where publicly-documented module attributes are
>intentionally omitted from __all__:
>
>* Issue 26234: typing.re and typing.io
>* Issue 23439: HTTP st
Barry A. Warsaw added the comment:
On May 20, 2016, at 07:02 AM, Berker Peksag wrote:
>+1 for the idea. I saw a lot of different 'all' or 'public' decorators in the
>wild. It would be nice to have a complete solution in Python. It would be
>good to add a note to Doc/whatsne
Barry A. Warsaw added the comment:
On May 20, 2016, at 07:21 AM, Franklin? Lee wrote:
>I am iffy about using ``public`` to define other values. That part might be
>considered unpythonic.
It's a bit of a stretch. I like it for the convenience, and the
implementation is simple, but
Barry A. Warsaw added the comment:
Here's a proposed fix.
--
assignee: -> barry
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42907/27066-1.patch
___
Python tracker <rep...@bugs.python.o
Barry A. Warsaw added the comment:
On May 20, 2016, at 12:12 AM, ppperry wrote:
>Also, `OSError [Errno 0] Error` isn't the most helpful error message.
No, definitely not. ;)
--
___
Python tracker <rep...@bugs.python.org>
<http://bug
New submission from Barry A. Warsaw:
Let's say you use a custom opener, and that opener happens to return exactly
-1. You end up with a SystemError because NULL got returned without an
exception being set:
def negative(fname, flags):
return -1
with open('/tmp/foo.txt', 'w', encoding
Barry A. Warsaw added the comment:
I refer again to https://bugs.python.org/issue26632 :)
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Barry A. Warsaw added the comment:
aiosmtpd already defaults decode_data to False. We should consider pulling
this into 3.6 (not just for this reason of course).
http://aiosmtpd.readthedocs.io/en/latest/
--
___
Python tracker <
Barry A. Warsaw added the comment:
Now with docs and tests.
--
Added file: http://bugs.python.org/file42833/26632-in-c-5.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Barry A. Warsaw added the comment:
Wow Ethan, that's quite interesting. I'm not sure if I like it or not. :)
It's better than having to assign a dummy value to the enum items, and if we
did require that, I'd suggest just throwing away the values for autonumbering.
But not having to specify
Barry A. Warsaw added the comment:
On May 09, 2016, at 04:19 PM, Ethan Furman wrote:
>`from ... import *` should not be used with packages that do not have an
>__all__ unless they support that usage (check their docs).
Good idea; I added a warni
Barry A. Warsaw added the comment:
Here's a standalone version for older Python 3's:
http://public.readthedocs.io/en/latest/
https://pypi.python.org/pypi/atpublic
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Barry A. Warsaw added the comment:
One more diff. As I was working on tests, I realized that the decorator
version wasn't returning the thing it was decorating. Changing this also
allowed me to simplify the exit path.
I should be putting up a PyPI package soon which implements
Barry A. Warsaw added the comment:
Updated.
--
Added file: http://bugs.python.org/file42760/26632-in-c-3.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Barry A. Warsaw added the comment:
On May 06, 2016, at 03:41 PM, Eric V. Smith wrote:
>I agree it would be a 3.6 only change (and I've change the versions to
>reflect that).
The reason the other versions were included was because this was originally
reported as a documentation bug. It
Barry A. Warsaw added the comment:
I think I missed a decref. New diff.
--
Added file: http://bugs.python.org/file42758/26632-in-c-2.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Barry A. Warsaw added the comment:
Eric should chime in on the str.format() implications.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +eric.smith
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18531>
___
_
Barry A. Warsaw added the comment:
Agreed with Serhiy. Raymond's approach is nicer, but I'm still not convinced
about the use case. Closing.
If someone wants to run with this again, an updated patch would be needed, and
the issue could be reopened, but I also suggest following through
Barry A. Warsaw added the comment:
Here's a C implementation. I'm a bit under the weather so please do double
check my refcounting logic. ;)
No tests or docs yet, but those would be easy to add. Here's an example:
@public
class Foo:
pass
public(qux=3)
print(qux)
@public
def zzz
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26763>
___
__
Changes by Barry A. Warsaw <ba...@python.org>:
--
status: closed -> open
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25731>
___
_
Barry A. Warsaw added the comment:
On Apr 06, 2016, at 03:07 PM, Serhiy Storchaka wrote:
>I think in this particular case you are more interesting in the value of k
>than k.replace('.', '').replace('-', '').replace('_', '').
Possi
New submission from Barry A. Warsaw:
Too many times I hit failing assert statements, and have no idea what value is
causing the assertion to fail. Sure, you can provide a value to print (instead
of just the failing code) but it seems to be fairly rarely used. And it can
also lead to code
Barry A. Warsaw added the comment:
Here's my implementation based on eryksun's idea:
def public(thing=None, **kws):
mdict = (sys._getframe(1).f_globals
if thing is None
else sys.modules[thing.__module__].__dict__)
dunder_all = mdict.setdefault('__all__
Barry A. Warsaw added the comment:
On Mar 25, 2016, at 02:12 AM, Eryk Sun wrote:
>I added a prototype to Python/bltinmodule.c that gets or creates the __all__
>list from the current globals (i.e. PyEval_GetGlobals).
Hi Eryk. Can you post your diff to bltinmodule.c? I'd like to see you
Barry A. Warsaw added the comment:
On Mar 28, 2016, at 04:26 PM, Serhiy Storchaka wrote:
>There is a helper in test.support that helps to add a test for __all__, and
>we slowly add these test for all modules. So this is not large issue for the
>stdlib.
>
>New module level
Barry A. Warsaw added the comment:
On Mar 28, 2016, at 06:34 AM, Raymond Hettinger wrote:
>I have to agree with that part ;-) Sorry, but this feels "yucky" and is
>likely to cause more problems than it solves.
I've been experimenting with something like this in a Mailman bran
Barry A. Warsaw added the comment:
On Mar 25, 2016, at 12:14 AM, Ethan Furman wrote:
>public = Public(globals())
>
>@public
>def baz(a, b):
>#blah blah
>
>public('CONST1', 2)
I'm not crazy about that, plus I rather don't like the implicit binding of the
name. I suppos
Barry A. Warsaw added the comment:
On Mar 24, 2016, at 10:31 PM, Martin Panter wrote:
>FWIW I already invented this :) as written in Issue 22247. Although I think I
>only used it once or twice in my own personal librarie(s). So it’s a nice
>sign that we came up with the same @pu
Barry A. Warsaw added the comment:
On Mar 24, 2016, at 02:48 AM, Ethan Furman wrote:
>On the down side, you know somebody is going to @public a class' method --
>how do we check for that?
Do we need to? Consenting adults and __all__.
OT1H, you do get an AttributeError if you from-
Barry A. Warsaw added the comment:
Oh, and it should be a built-in
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26632>
___
___
New submission from Barry A. Warsaw:
This is probably terrible, but given how difficult it is to keep __all__'s up
to date, maybe something like this can be useful. I literally whipped this up
in about 5 minutes, so sit back and watch the bikeshedding!
import sys
def public(thing
Barry A. Warsaw added the comment:
I was thrown off a bit by the description below. it's not that the OP wants to
generate an Enum lazily (the functional API lets them do that), it's that the
OP wants to *extend* an Enum lazily.
Seems like a pretty obscure use case to me. I'd vote
701 - 800 of 2236 matches
Mail list logo
