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
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue29324>
___
___
Python-bugs-list mailing list
Unsubscribe:
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.
--
___
Pyth
Changes by Barry A. Warsaw :
--
versions: +Python 3.3, Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue22807>
___
___
Python-bugs-list m
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
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
comi
Changes by Barry A. Warsaw :
--
assignee: -> barry
___
Python tracker
<http://bugs.python.org/issue22807>
___
___
Python-bugs-list mailing list
Unsubscrib
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
Changes by Barry A. Warsaw :
--
pull_requests: +98
___
Python tracker
<http://bugs.python.org/issue22807>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
+1
Probably ought to reconfigure .travis.yml to use the new targets too, if
possible.
--
___
Python tracker
<http://bugs.python.org/issue29
On 17.02.2017 13:06, STINNER Victor wrote:
>> Alternatively, sysconfig data could be made available via a C lookup
>> function; with the complete dictionary only being created on demand.
>> get_config_var() already is such a lookup API which could be used as
>> front
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/8c130d7f8114158f5b94749032ec0c
Changes by Barry A. Warsaw :
--
resolution: -> fixed
___
Python tracker
<http://bugs.python.org/issue22807>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Barry A. Warsaw :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue22807>
___
___
Python-bugs-list
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`
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 usef
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
Changes by Barry A. Warsaw :
--
keywords: -security_issue
___
Python tracker
<http://bugs.python.org/issue22807>
___
___
Python-bugs-list mailing list
Unsub
Changes by Barry A. Warsaw :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue22807>
___
___
Python-bugs-list
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
<http://bugs.py
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.unknow
Changes by Barry A. Warsaw :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue29546>
___
___
Barry A. Warsaw added the comment:
I think this bug has been fixed.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
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 aiosmt
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue29642>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
pull_requests: +246
___
Python tracker
<http://bugs.python.org/issue25008>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
pull_requests: +248
___
Python tracker
<http://bugs.python.org/issue25008>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
pull_requests: +249
___
Python tracker
<http://bugs.python.org/issue25008>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
pull_requests: +250
___
Python tracker
<http://bugs.python.org/issue25008>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
released) will
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:
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
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/
Changes by Barry A. Warsaw :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker
<http://bugs.python.org/issu
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
Barry A. Warsaw added the comment:
Thanks for the patch!
--
___
Python tracker
<http://bugs.python.org/issue27187>
___
___
Python-bugs-list mailing list
Unsub
e of where this
> was rather disastrous.)
Thanks, Theodore, for this paper reference. It provides convincing
arguments that going back to the Python 3.4 behavior is indeed not
a good idea - even though I'm still not convinced that the main
use case for os.urandom() is cryptography. Most people will
Barry A. Warsaw added the comment:
Thanks Ian. I'm going to apply that, but rephrase it a bit.
--
___
Python tracker
<http://bugs.python.org/issue27187>
___
___
Changes by Barry A. Warsaw :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue27066>
___
___
Python-bugs-list
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&
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 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 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 po
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:
Jürgen A. Erhard added the comment:
To add to this (without looking at the patch): I just to my astonishment
learned that a ZipExtFile doesn't even support tell(). I can understand the
seek being nontrivial... but the tell? It's a bytestream, and there is (isn't
there?) a c
Barry A. Warsaw added the comment:
I don't really think much more needs to be done other than agree on this
tracker issue that it's something we want, and that Ethan's implementation is
good enough. It's been a while since I looked that the code but it seemed good
to me
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 global and
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 t
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 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:
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 i
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
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue27814>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
versions: +Python 3.6 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue18139>
___
___
Python-bugs-list mailin
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).
Barry A. Warsaw added the comment:
I meant .items()
--
___
Python tracker
<http://bugs.python.org/issue18139>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Enrique A Tobis:
import logging
f = logging.StrFormatStyle('{asctimer}')
print(f.usesTime())
f = logging.PercentStyle('%(astimer)s')
print(f.usesTime())
prints
True
False
and I think it should print
False
False
--
components: Library (Lib)
m
Changes by Enrique A Tobis :
--
keywords: +patch
Added file: http://bugs.python.org/file29054/mywork.patch
___
Python tracker
<http://bugs.python.org/issue17
Enrique A Tobis added the comment:
Thanks! Got it. Sorry for the noise.
--
___
Python tracker
<http://bugs.python.org/issue17199>
___
___
Python-bugs-list mailin
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue17170>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Feb 19, 2013, at 07:24 PM, Serhiy Storchaka wrote:
>Can this be the same ImportError but with special flag?
Like an attribute on the exception? +1
--
___
Python tracker
<http://bugs.python.org/issu
Barry A. Warsaw added the comment:
On Feb 19, 2013, at 07:49 PM, Brett Cannon wrote:
>Serihy & Barry: no. We do that now and it's already a nasty little hack. It
>would be better to let people catch an exception signaling that an import
>didn't happen because some module
Barry A. Warsaw added the comment:
Does the 2.x patch apply cleanly to 2.6? If so, then I think it should be
applied (though I'd like to review it first). 2.6 is still under security
maintenance until October 2013. I'm thinking we'll probably do one last
security release a
Changes by Barry A. Warsaw :
--
versions: +Python 2.6
___
Python tracker
<http://bugs.python.org/issue16248>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
Release blocking for 2.6.9 (oh how I wish we could release block for specific
Python versions).
--
nosy: +georg.brandl, larry
priority: normal -> release blocker
___
Python tracker
<http://bugs.pyth
Changes by Barry A. Warsaw :
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/issue17258>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue17258>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue17186>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
versions: +Python 2.6
___
Python tracker
<http://bugs.python.org/issue16037>
___
___
Python-bugs-list mailin
Changes by Barry A. Warsaw :
--
nosy: +barry
versions: +Python 2.6
___
Python tracker
<http://bugs.python.org/issue16043>
___
___
Python-bugs-list mailin
Barry A. Warsaw added the comment:
I'm working on applying the 2.x patch to 2.6, but one thing interesting of
note: sudo, at least on Debian and derivatives going back at least to Squeeze,
generally reset the environment by default (i.e. env_reset). So you'd have to
either hav
Barry A. Warsaw added the comment:
I think this has now been applied to all of 2.6, 2.7, 3.1, 3.2, 3.3, and 3.4.
So, closing.
--
___
Python tracker
<http://bugs.python.org/issue16
Barry A. Warsaw added the comment:
On Feb 22, 2013, at 06:54 PM, Charles-François Natali wrote:
>Charles-François Natali added the comment:
>
>> Barry advised me to open this issue as it's a functional regression from
>> Python 2.
>
>But it was relying on a private
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue16801>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue16997>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue17330>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue14266>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
As I mentioned on python-dev, having a `pyunit` script is nice (whatever it's
called), but we need to keep the `-m invocation` which will probably be the
recommendation on distros such as Debian which provide multiple versions of
Python. We're no
Barry A. Warsaw added the comment:
On Mar 04, 2013, at 07:45 PM, Antoine Pitrou wrote:
>
>Antoine Pitrou added the comment:
>
>> We're not going to want to install all possible flavors of
>> `pyunit2.6`, `pyunit2.7`, `punit2.6-dbg`, `pyunit-3.2-dbg`, etc. etc.
>
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue17379>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Mar 07, 2013, at 03:58 PM, Antoine Pitrou wrote:
>Disagreed. This is the kind of sentence that cannot be correctly
>understood without the (missing) original context.
Plus, we fear change. ;)
--
___
Barry A. Warsaw added the comment:
On Mar 09, 2013, at 03:30 AM, Terry J. Reedy wrote:
>I think you are, in effect, asking for expansion of the 'PEP Header Preamble'
>section of PEP-0001. I have added some of the PEP editors listed in the PEP
>as nosy. I will let them decid
Barry A. Warsaw added the comment:
It seems to me that the right thing to add a related PEPs section to any PEP
which needs it, but I don't think we need an official header for it. Thus, I'm
closing this PEP as Won't Fix. Feel free to open new bugs for any specific PEP
that n
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue15806>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue15805>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue3982>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Barry A. Warsaw:
This came up at the Pycon 2013 Python 3 porting clinic. There are many cases
in the stdlib that claim (either explicitly or implicitly) to accept bytes or
strings, but that don't return the type of the arguments they accept. An
examp
Barry A. Warsaw added the comment:
On Mar 17, 2013, at 03:10 PM, R. David Murray wrote:
>There was a long thread about this on python-dev that might be worth going
>back over, where I had the same misconception (that functions should always
>return the same type as their arguments).
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue17527>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue17565>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue15867>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
You also end up with this nice bit of inconsistency:
>>> x = myint(7)
>>> from operator import index
>>> range(10)[6:x]
range(6, 7)
>>> range(10)[6:x.__index__()]
range(6, 8)
>>> range(10)[6:index(x)]
range(6, 7)
New submission from Barry A. Warsaw:
operator.index() is just a thin wrapper around PyNumber_Index(). The
documentation for operator.index() claims that it is equivalent to calling
obj.__index__() but for subclasses of int, this is not true. In fact,
PyNumber_Index() first does (e.g. in
Changes by Barry A. Warsaw :
--
title: PyNumber_Index() is not int-subclass friendly -> PyNumber_Index() is not
int-subclass friendly (or operator.index() docos lie)
___
Python tracker
<http://bugs.python.org/issu
Barry A. Warsaw added the comment:
On Mar 30, 2013, at 12:29 AM, Eric Snow wrote:
>Would it be okay to do a check on __index__ after the PyLong_Check()
>succeeds? Something like this:
>
>if (PyLong_Check(item) &&
>item->ob_type->tp_as_number->nb_inde
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue17579>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Apr 01, 2013, at 07:40 PM, Brett Cannon wrote:
>Barry, Eric: can you clarify why you made module_repr an abstractmethod and
>thus require its overloading?
Maybe Eric can, but I can't. ;) I honestly don't remember why we made it
abstract
Barry A. Warsaw added the comment:
On Apr 01, 2013, at 09:04 PM, Brett Cannon wrote:
>If Eric doesn't have anything to add then I would like to change
>importlib.abc.Loader.module_repr() to no longer be abstract and the default
>to be defined as ``return repr(module)``. Els
Barry A. Warsaw added the comment:
On Apr 02, 2013, at 11:32 AM, Eric V. Smith wrote:
>My suggestion is to have format() be an alias for
>format_string(). Deprecating format() is an optional step, but may not be
>worth the hassle.
Agreed on bo
2101 - 2200 of 2582 matches
Mail list logo
