Changes by Barry A. Warsaw <ba...@python.org>:
--
versions: +Python 3.7 -Python 3.2
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.o
Barry A. Warsaw added the comment:
I'll preface that it's not a major issue that I feel *has* to be fixed, but
given that assert *can* be compiled away, does it make sense to use abort()
instead? E.g.
1 file changed, 2 insertions(+), 2 deletions(-)
Python/compile.c | 4 ++--
modified
Changes by Barry A. Warsaw <ba...@python.org>:
--
pull_requests: +3325
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31337>
___
_
Barry A. Warsaw added the comment:
As it's barely worth fixing, it's not worth backporting.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Barry A. Warsaw:
There is a very minor opportunity for NULL dereference in compile.c.
compiler_subdict() does not check the return value of get_const_value(), which
could be NULL. This was found by Kirit Sankar Gupta.
This is not a security issue in practice, since
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30761>
___
__
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31280>
___
__
New submission from Barry A. Warsaw:
The devguide does touch on how to build Python from source using homebrew
installed libraries on macOS, although I found it to be 1) a bit incomplete; 2)
not so easy to discover.
It might make sense to modify configure to autodetect homebrew, or to have
Barry A. Warsaw added the comment:
It's probably fine, since it should be a rare occurrence, but it of course has
the potential to break things like tests (doc and otherwise). Unlikely, but it
should be pointed out. Still, I'm also fine with backporting it.
--
nosy: +barry
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29593>
___
__
Barry A. Warsaw added the comment:
I agree with everything @serhiy.storchaka said, including the questionable
utility of the l* methods in Python 3. ;)
Thanks also for updating the documentation. Reading the existing docs over
now, it's shocking how imprecise "the translation is ret
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30429>
___
__
Barry A. Warsaw added the comment:
Thanks for all the great detailed background, and the suggested approaches. I
think there are a couple of constraints that would be good to resolve.
* parsedate_to_datetime() is documented as "performing the same function as
parsedate()" with a
Barry A. Warsaw added the comment:
I'm not sure it would be any better, but what about defining something like a
DateFormatDefect and returning that?
--
___
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/issue30565>
___
__
Barry A. Warsaw added the comment:
This is now fixed in aiosmtpd HEAD (what will be 1.1)
I'm going to close this issue here even though smtpd.py isn't fixed since it's
unlikely that anybody wants to keep working on smtpd.py. Feel free to reopen
it if you do.
--
resolution: -> w
Barry A. Warsaw added the comment:
Adding Jim Fulton (for Zope) and Guido (for Pythonlabs). I don't know who owns
the former, but I'm fairly sure Guido owns the pythonlabs domain.
--
nosy: +gvanrossum, j1m
___
Python tracker <rep...@bugs.python.
Barry A. Warsaw added the comment:
I don't have much interest in working on this for smtpd.py any more. We have
an asyncio-based version that's much better, albeit Python 3 only.
https://github.com/aio-libs/aiosmtpd
This same issue is open over there; if you're still interested
Barry A. Warsaw added the comment:
On May 30, 2017, at 10:36 PM, Yury Selivanov wrote:
>Again, the natural way of something like Controller to end up in asyncio is
>to either go through full PEP process, or live some time on PyPI and prove to
>be useful.
A PEP feels like overkill;
Barry A. Warsaw added the comment:
On May 29, 2017, at 11:42 PM, Yury Selivanov wrote:
>- detailed logging or hooks to implement it
>- hooks on thread start / stop
>- coroutines to run before starting the server
>- coroutines to run before stopping the loop
>- custom undhan
Barry A. Warsaw added the comment:
On May 29, 2017, at 07:07 AM, Antoine Pitrou wrote:
>For example I might write a UDP server. Or a distributed system that listens
>to several ports at once, or launches a thread pool. etc.
Thanks, those are nice motivational ex
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30503>
___
__
Barry A. Warsaw added the comment:
Hi Antoine,
On May 28, 2017, at 11:07 AM, Antoine Pitrou wrote:
>I think the API is too specific.
Can you elaborate? What's too specific about it? Do you have in mind a use
case where you wouldn't need to provide hostname and port?
>Instead of req
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30479>
___
__
Barry A. Warsaw added the comment:
I'm very interested in this because, even though we do support STARTTLS in
aiosmtpd, it's a hack using non-public symbols, and we have a hidden traceback!
(I.e. one that doesn't cause the test suite to fail, but only shows up when
clients disconnect
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23749>
___
__
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30359>
___
__
Barry A. Warsaw added the comment:
On May 11, 2017, at 12:09 AM, STINNER Victor wrote:
>Why not starting by putting this class in a library to mature its API?
It's already part of aiosmtpd although not with the small amount of
generic-ness included here. It's been useful and stable.
Barry A. Warsaw added the comment:
On May 08, 2017, at 11:06 PM, Nathaniel Smith wrote:
>Looks interesting! What's the advantage over running the server and the test
>in the same loop? The ability to use blocking operations in the tests, and to
>re-use an expensive-to-start server over
Changes by Barry A. Warsaw <ba...@python.org>:
--
pull_requests: +1594
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30300>
___
_
New submission from Barry A. Warsaw:
Over in https://github.com/aio-libs/aiosmtpd we have a Controller class which
is very handy for testing and other cases. I realized that this isn't really
aiosmtpd specific, and with just a few tweaks it could be appropriate for the
stdlib.
I have
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30145>
___
__
Barry A. Warsaw added the comment:
For the archaeologists of the future, smtpd.py is also deprecated in favor of
aiosmtpd.
http://aiosmtpd.readthedocs.io/en/latest/
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Barry A. Warsaw added the comment:
I'd be very hesitant to add anything to 2.7 that changes (even broken) behavior
here. It might make more sense to backport the more strict checks to 3.5.
OTOH, we can save people from all programming errors, and if warnings are
basically ignored (plus
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30024>
___
__
Barry A. Warsaw added the comment:
On Apr 05, 2017, at 03:26 PM, Raymond Hettinger wrote:
>Barry, is this something that should go back to 2.7 or is that pretty much
>settled business at this point?
I think we should not backport this. It's a behavior change and my concern
Changes by Barry A. Warsaw <ba...@python.org>:
--
versions: +Python 3.7 -Python 2.7, Python 3.3, Python 3.4
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Barry A. Warsaw <ba...@python.org>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by Barry A. Warsaw <ba...@python.org>:
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by Barry A. Warsaw <ba...@python.org>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Barry A. Warsaw added the comment:
New changeset 9f74deba784fc8781d13ed564f69c02ed7c331bb by Barry Warsaw in
branch 'master':
Improve the documentation for template strings (#856)
https://github.com/python/cpython/commit/9f74deba784fc8781d13ed564f69c02ed7c331bb
Barry A. Warsaw added the comment:
New changeset 9f74deba784fc8781d13ed564f69c02ed7c331bb by Barry Warsaw in
branch 'master':
Improve the documentation for template strings (#856)
https://github.com/python/cpython/commit/9f74deba784fc8781d13ed564f69c02ed7c331bb
Barry A. Warsaw added the comment:
New changeset 9f74deba784fc8781d13ed564f69c02ed7c331bb by Barry Warsaw in
branch 'master':
Improve the documentation for template strings (#856)
https://github.com/python/cpython/commit/9f74deba784fc8781d13ed564f69c02ed7c331bb
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29929>
___
__
Barry A. Warsaw added the comment:
As this issue has been open for a long time, and I don't think it's worth
changing the implementation, I am changing this to a documentation bug and will
fix it along with the rewrites for bpo-19824 and bpo-20314
--
assignee: -> barry
compone
Changes by Barry A. Warsaw <ba...@python.org>:
--
pull_requests: +759
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20314>
___
_
Changes by Barry A. Warsaw <ba...@python.org>:
--
pull_requests: +758
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19824>
___
_
Changes by Barry A. Warsaw <ba...@python.org>:
--
assignee: docs@python -> barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Barry A. Warsaw added the comment:
I'll take this one, and see if I can address 20314 also.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Barry A. Warsaw <ba...@python.org>:
--
assignee: docs@python -> barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Barry A. Warsaw added the comment:
We should really restructure string.Template documentation to emphasize i18n.
That's always been its prime use case, and f-strings don't change that (because
f-strings are not really appropriate for translations). Before f-strings,
string.Template had
Barry A. Warsaw added the comment:
New changeset 1bc156430bad8177b5beecf57979628c1d071230 by Barry Warsaw
(Matthias Bussonnier) in branch 'master':
bpo-29546: Improve from-import error message with location (#103)
https://github.com/python/cpython/commit
Barry A. Warsaw added the comment:
New changeset f37b0cb230069481609b0bb06891b5dd26320504 by Barry Warsaw in
branch '3.4':
bpo-25008: Deprecate smtpd and point to aiosmtpd (#274) (#280)
https://github.com/python/cpython/commit/f37b0cb230069481609b0bb06891b5dd26320504
Barry A. Warsaw added the comment:
New changeset 66b5092fac4264efdc9c508a7dd425fa9833e147 by Barry Warsaw in
branch '3.5':
bpo-25008: Deprecate smtpd and point to aiosmtpd (#274) (#279)
https://github.com/python/cpython/commit/66b5092fac4264efdc9c508a7dd425fa9833e147
Barry A. Warsaw added the comment:
New changeset 0a1b656d8ce3da14f8acf947477b8e998e68ef3b by Barry Warsaw in
branch '3.6':
bpo-25008: Deprecate smtpd and point to aiosmtpd (#274) (#278)
https://github.com/python/cpython/commit/0a1b656d8ce3da14f8acf947477b8e998e68ef3b
Barry A. Warsaw added the comment:
On Mar 21, 2017, at 11:47 AM, STINNER Victor wrote:
>No, text please. Text is just more convenient in Python, and it's trivial to
>retrieve original bytes:
>
>raw_args_bytes = [os.fsencode(arg) for arg in sys._raw_args]
Well, "raw args
Barry A. Warsaw added the comment:
Is EHLO the only command sent in lower case? I think it might not be.
I suppose I'm a solid ±0 on changing this (how's that for a completely neutral
endorsement?). I won't do the change myself, but I'd review a pull request
Barry A. Warsaw added the comment:
As bytes?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29857>
___
___
Python-bugs-list
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29857>
___
__
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14208>
___
__
Barry A. Warsaw added the comment:
I was going to say that this is an API change, but given that without this,
folks would have to catch both exceptions and now only have to catch one of
them, it isn't.
--
nosy: +barry
___
Python tracker <
Barry A. Warsaw added the comment:
On Mar 12, 2017, at 11:42 AM, Chi Hsuan Yen wrote:
>That's a great feature! Here's a question: what should be CPython's behavior
>when PYTHONHISTORY is explicitly set to empty? Currently there's an error:
>
>$ PYTHONHISTORY= ./python
>
Barry A. Warsaw added the comment:
I don't think the Python envar has to follow the contraction from bash.
$PYTHONHISTORY reads very nicely.
I have similar code in my $PYTHONSTARTUP, but it would be nice to be able to
get rid of it and just let Python do the common thing
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29779>
___
__
Barry A. Warsaw added the comment:
bools are subclasses of int and False and True have integer equivalents:
https://docs.python.org/3/library/stdtypes.html#bltin-boolean-values
--
nosy: +barry
resolution: -> not a bug
stage: -> resolved
status: open -&g
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29729>
___
__
Barry A. Warsaw added the comment:
Shouldn't this at least also cover Python 3.7? And should it be officially
backported? I would think that if https://github.com/python/cpython/pull/296
gets accepted for 3.7, then distros that care can cherry pick it back into
whatever versions they still
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29708>
___
__
Changes by Barry A. Warsaw <ba...@python.org>:
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by Barry A. Warsaw <ba...@python.org>:
--
pull_requests: +250
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25008>
___
_
Changes by Barry A. Warsaw <ba...@python.org>:
--
pull_requests: +249
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25008>
___
_
Changes by Barry A. Warsaw <ba...@python.org>:
--
pull_requests: +248
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25008>
___
_
Changes by Barry A. Warsaw <ba...@python.org>:
--
pull_requests: +246
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25008>
___
_
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29642>
___
__
Barry A. Warsaw added the comment:
aiosmtpd is coming along nicely:
http://aiosmtpd.readthedocs.io/en/latest/
We'll soon have a 1.0 release. Still, I don't think it's worth pulling this
into the stdlib. But we could silently deprecate it and point to aiosmtpd in
the docs
Barry A. Warsaw added the comment:
I think this bug has been fixed.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Barry A. Warsaw <ba...@python.org>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Barry A. Warsaw added the comment:
On Feb 20, 2017, at 03:45 PM, STINNER Victor wrote:
>Can't we consider that UUID4 is always safe?
It's not a guarantee made by the underlying platform, so I chose to use the
default SafeUUID.unknown va
Barry A. Warsaw added the comment:
Oh, and because the fix is an API change, I don't believe it should be applied
to earlier versions. So I think adding the API in 3.7 is all the fix needed
here.
--
___
Python tracker <rep...@bugs.python.
Changes by Barry A. Warsaw <ba...@python.org>:
--
resolution: -> fixed
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Changes by Barry A. Warsaw <ba...@python.org>:
--
keywords: -security_issue
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Barry A. Warsaw added the comment:
On Feb 20, 2017, at 02:21 PM, STINNER Victor wrote:
>What am I supposed to do with an UUID with safe=False? Should I loop on the
>function until I get safe==True?
It would be an application dependent response. It might be that you would
check some
Barry A. Warsaw added the comment:
On Feb 20, 2017, at 12:03 AM, Fred L. Drake, Jr. wrote:
>Is there some special treatment you think should be given to specific enum
>values as well?
The only thing I thought about was optionally provide the enum item's value,
when that's useful. Usual
New submission from Barry A. Warsaw:
Over in https://github.com/python/cpython/pull/138 I noticed that we don't
currently have markup for enum types. While class:: is technically still
correct, it's not helpful because the html documentation should render this as
`Enum SafeUUID` not `class
Changes by Barry A. Warsaw <ba...@python.org>:
--
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Changes by Barry A. Warsaw <ba...@python.org>:
--
resolution: -> fixed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22807>
___
_
Barry A. Warsaw added the comment:
New changeset 8c130d7f8114158f5b94749032ec0c17dba96f83 by GitHub in branch
'master':
bpo-22807: Expose platform UUID generation safety information. (#138)
https://github.com/python/cpython/commit/8c130d7f8114158f5b94749032ec0c17dba96f83
Barry A. Warsaw added the comment:
+1
Probably ought to reconfigure .travis.yml to use the new targets too, if
possible.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Barry A. Warsaw <ba...@python.org>:
--
pull_requests: +98
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22807>
___
_
Barry A. Warsaw added the comment:
I changed my mind on whether this should affect older versions of Python. I
have a branch which adds an UUID.is_safe attribute that relays the platform
information about whether the UUID was generated safely or not, if available.
It's an enum named
Changes by Barry A. Warsaw <ba...@python.org>:
--
assignee: -> barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22807>
___
__
New submission from Barry A. Warsaw:
I haven't really thought about this deeply but I've observed that there are
lots of cases where a user will report getting an ImportError trying to import
a name from a module, where it turns out that the problem is that the module is
coming from
Barry A. Warsaw added the comment:
On Feb 12, 2017, at 05:42 PM, Brett Cannon wrote:
>That comment is poorly worded.
Pretty sure at one time it was accurately worded, but things have changed
since PEP 3147 so the comment could use an upd
Changes by Barry A. Warsaw <ba...@python.org>:
--
versions: +Python 3.3, Python 3.6, Python 3.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Barry A. Warsaw added the comment:
Confirmed that test_socket_aead_kernel49.patch fixes the problem for Ubuntu
17.04. It'll probably fix it for Debian Stretch too give its kernel version
number, but I haven't tested that yet.
--
___
Python tracker
Changes by Barry A. Warsaw <ba...@python.org>:
--
nosy: +barry
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29324>
___
__
Barry A. Warsaw added the comment:
On Feb 10, 2017, at 05:46 PM, Nick Coghlan wrote:
>Note that Fedora doesn't even rebuild all the extension modules when bumping
>CPython to a new maintenance release, let alone rebuilding and re-releasing
>all the pure Python ones. (RPM suppo
Barry A. Warsaw added the comment:
On Jan 18, 2017, at 03:57 PM, Matthias Klose wrote:
>I don't think we need a PEP for this
Correct. Generally we don't need PEPs for build system changes.
--
___
Python tracker <rep...@bugs.python.org&
Barry A. Warsaw added the comment:
On Jan 18, 2017, at 10:56 AM, Jeroen Van Goey wrote:
>sudo add-apt-repository ppa:jonathonf/python-3.6
>sudo apt-get update
>sudo apt-get install python3.6
>
>I made a string, using the new literal string interpolation, but I supplied
>
Barry A. Warsaw added the comment:
On Jan 05, 2017, at 11:11 AM, STINNER Victor wrote:
>I'm sure that many Linux, UNIX and BSD systems don't have the "C.UTF-8"
>locale. For example, HP-UX has "C.utf8" which is not exactly "C.UTF-8".
>
>I'm not sure that
601 - 700 of 2236 matches
Mail list logo
