Changes by Barry A. Warsaw :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue23399>
___
___
Python-bugs-list
Barry A. Warsaw added the comment:
Let's just Won't Fix this. Use a contextlib.ExitStack.
--
___
Python tracker
<http://bugs.python.org/issue12782>
___
___
Changes by Barry A. Warsaw :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12782>
___
___
Python-bugs-
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue24305>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
So yeah, we don't want to deprecate string.Template. It has a very specific
use case that's used a lot, i.e. making strings dead simple to translate.
%(foo)s was very problematic. {foo} is a little better, but looks too weird
for most translat
Barry A. Warsaw added the comment:
I don't know what problems I might have run into previously, but it's working
now and seems fine to me. +1
--
nosy: +barry
___
Python tracker
<http://bugs.python.o
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue19699>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue24168>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
If you need a test case, try https://gitlab.com/warsaw/flufl.lock
--
___
Python tracker
<http://bugs.python.org/issue24
Barry A. Warsaw added the comment:
Rather than change the code, which strives to keep the "Simple" in PEP 292's
title, I'd rather just update the documentation to define what "identifier"
means here. E.g.
"
* ``$identifier`` names a substitution pl
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue24412>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24351>
___
___
Python-bugs-list
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue24454>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
Found my first 3.5 breakage which I think is due to this.
>>> from uuid import uuid4
>>> '%.32x' % uuid4()
--
nosy: +barry
___
Python tracker
<ht
Barry A. Warsaw added the comment:
Fix:
>>> '%.32x' % uuid4().int
--
___
Python tracker
<http://bugs.python.org/issue19995>
___
___
Pyth
Barry A. Warsaw added the comment:
I believe this change broke RFC 4954's AUTH command when the optional
initial-response is expected. $4 "The AUTH Command" says:
AUTH mechanism [initial-response]
...
initial-response: An optional initial client response. If present,
Barry A. Warsaw added the comment:
Here's a rough thought for a fix. Some auth_*() methods require a challenge,
but some don't, e.g. auth_plain(). Let's allow authobject() to be called with
challenge=None. If they allow an initial-response, then they can just return
the resp
Barry A. Warsaw added the comment:
Also, smtpd is not compatible with auth challenges because found_terminator()
doesn't know that the response its getting isn't a command but instead a
challenge response. So really we need another bug to track fixes to smtpd.py
to handle challenge
Barry A. Warsaw added the comment:
On Jun 22, 2015, at 10:00 PM, R. David Murray wrote:
>We change the authobj signature to challenge=None, then the first thing we do
>in auth is 'initial_response = authobj()'. The return value can be the empty
>string or a real initial val
Barry A. Warsaw added the comment:
Martin says: "I cannot see any particular circumstances where unencrypted
passwords for smtpd would be acceptable, given that there are perfectly
established technologies. So I remain -1 on this patch."
Here's a use case: a testing SMTP
Barry A. Warsaw added the comment:
FWIW, this broke the zope.testing doctests:
https://bugs.launchpad.net/zope.testing/+bug/1467644
I submitted a patch, which was reasonable given the normalization that
zope.testing does for doctest output, but people should be aware that this can
break
Barry A. Warsaw added the comment:
When I ported Mailman 3 to Python 3.5 I had to remove the check on
email.__version__ :)
--
___
Python tracker
<http://bugs.python.org/issue22
On 01.07.2015 00:16, Min RK wrote:
>
>> Just because a feature can be misused doesn't make it a bad feature.
>
> That's fair. I'm just not aware of any uses of this feature that aren't
> misuses, hence the patch.
I don't remember the details of why t
Barry A. Warsaw added the comment:
I have a patch to support initial-response, which I'll be posting here after a
bit of clean up and a full (local) test run, with documentation. I ended up
adding a keyword argument `initial_response_ok=True` to .login() and .auth().
The reason for th
Barry A. Warsaw added the comment:
Attached patch includes test, documentation, and implementation. While this is
technically a new feature, it fixes a regression in Python 3.5 w.r.t. 3.4.
I'll email python-dev with a request for beta exemption.
--
Added file: http://bugs.pytho
Barry A. Warsaw added the comment:
On Jul 07, 2015, at 05:59 PM, R. David Murray wrote:
>I don't see any need to add the is_initial_auth_ok flag. Either the auth
>method returns something that is not None (initial auth is OK), or it doesn't
>(initial auth is not OK).
I
Barry A. Warsaw added the comment:
Thanks!
--
___
Python tracker
<http://bugs.python.org/issue15014>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
assignee: -> barry
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15014>
___
___
Python-bugs-list
On 15.08.2015 22:41, Steve Dower wrote:
>
> Marc-Andre: there are a few concerns with including DLLs that aren't new with
> any of the 3.5 changes.
>
> * depending on another CRT version is fine *if* it is available (users may
> have to be told/helped to install the red
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue24941>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue24965>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I'm of mixed opinion. I personally don't like cluttering up my $HOME with a
jillion dotfiles so I appreciate the organization XDG_CONFIG_HOME offers. But
that also makes things less discoverable. Looking in XDG_CONFIG_HOME first
with a fallbac
Barry A. Warsaw added the comment:
On Sep 01, 2015, at 07:15 PM, Glyph Lefkowitz wrote:
>There are other advantages to following the XDG spec. If we follow it
>correctly (and not, like Barry suggested, start adding random other
>directories like ~/.python)
I was really just suggestin
Barry A. Warsaw added the comment:
Removing smtpd would definitely be a hardship for me right now, probably for
obvious reasons. I use it in testing frameworks, and even wrote a library
called lazr.smtptest that is built around smtpd. In Mailman, we have an LMTP
server built on smtpd that
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue25014>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Sep 04, 2015, at 08:55 PM, STINNER Victor wrote:
>Maybe it can be fun to rewrite the module using asyncio, but I'm not
>convinced that a SMTP server in the Python stdlib is super useful.
As I mentioned in issue25008, removing smtpd would be a h
Barry A. Warsaw added the comment:
On Sep 07, 2015, at 02:26 PM, STINNER Victor wrote:
>Can we modify the issue title to "Rewrite smtpd with asyncio"?
Sure, although I'm currently thinking it's best to go third party until the
API and imp
Barry A. Warsaw added the comment:
On Sep 09, 2015, at 11:57 PM, Eric V. Smith wrote:
>There's one nit where I accept 'f' and 'F', but the PEP just says 'f'. I'm
>not sure if we should accept the upper case version. I'd think not, but all
>
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue25061>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue25154>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I'm sympathetic, given that in Debian/Ubuntu (and maybe other distros) where we
have both Python 3.4 and 3.5, we have to install /usr/bin/pyvenv-3.4 and
pyvenv-3.5, and then use symlinks to provide the default ve
Changes by Barry A. Warsaw :
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/issue25154>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue25159>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I have a patch which will at least improve the error message when `python3 -m
venv` fails because python3-venv isn't installed on Debian/Ubuntu. I will work
with Doko on this.
--
___
Python tracker
Barry A. Warsaw added the comment:
I'm not expecting a change either, I was also just documenting observed
breakages. Given that I've ported a *ton* of code to 3.5 and only seen a
handful of failures related to this issue, I agree that it's better just to
provide information a
> varies among platforms.
tzname is set when the module is being loaded and not updated
afterwards (unless you call tzset()). I can't really see why you
would expect a module global in Python to follow the semantics
of a C global, unless this is explicitly documented.
Note: The fact tha
Changes by Andrej A Antonov :
--
nosy: +polymorphm
___
Python tracker
<http://bugs.python.org/issue24755>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue25296>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I'm liking RDM's port of smtpd.py. I've done some clean ups, bug fixes, and
added some debugging. See this branch over on gitlab:
https://gitlab.com/python-smtpd-hackers/aiosmtpd/tree/issue25508
Try `python3 server.py` then run clien
New submission from Barry A. Warsaw:
In Python 3.5, SMTPChannel.__init__() ensures that enable_SMTPUTF8 and
decode_data arguments are not both true. This even seems to be tested in
test_smtpd.py. But it's clearly bogus because the exception is never raised!
It just creates and throws
Barry A. Warsaw added the comment:
On Oct 08, 2015, at 08:44 PM, Mauro S. M. Rodrigues wrote:
>Python 3.5.0+ (3.5:1e99ba6b7c98, Oct 8 2015, 17:12:06)
>[GCC 4.8.4] on linux
>Type "help", "copyright", "credits" or "license" for more inf
Sebastian A. Brachi added the comment:
> I wrote a proposal to the board a while ago
I couldn't find that proposal, could you post a link to it? Thanks!
--
nosy: +Sebastian A. Brachi
___
Python tracker
<http://bugs.python.org
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue21159>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
Reopening because we're starting to see regressions caused by the fix for this
bug, e.g.: https://bugs.launchpad.net/configglue/+bug/1504288
--
keywords: +3.4regression, 3.5regression -patch
status: closed -&
Barry A. Warsaw added the comment:
The failure is in the configglue test suite, but apparently also kazan and
qutebrowser are also affected by this change. In the Launchpad bug there's a
link to a librarian build log result.
The problem is that doing the .get() requires that subcl
Barry A. Warsaw added the comment:
Re: platform_default - I'm not sure that's a good idea. It hides what's
actually happening in some hard to discover place (the code). Probably EIBTI
and just go with 'enable' and 'disable'.
--
___
Barry A. Warsaw added the comment:
On Oct 14, 2015, at 03:20 PM, Nick Coghlan wrote:
>The rationale behind "platform_default" relates to what we put in the default
>config file in the RPM. If enable/disable are the only options, then as soon
>as the first version ships wi
Barry A. Warsaw added the comment:
This has come along pretty well. The project is managed here:
https://gitlab.com/python-smtpd-hackers/aiosmtpd
and documentation here:
http://aiosmtpd.readthedocs.org/en/latest/
--
___
Python tracker
<h
Barry A. Warsaw added the comment:
On Oct 29, 2015, at 10:30 PM, Alex Gaynor wrote:
>Right now uuid4 can be implemented one of 3 ways:
If you're hacking on the uuid module, keep in mind issue22807
--
nosy: +barry
___
Python tracke
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue25649>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
Another example is the six.moves module, though I haven't looked at its
implementation approach.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue25698>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
This seems entirely reproducible in a local Xenial sbuild using the source
packages in https://launchpad.net/~doko/+archive/ubuntu/toolchain/+packages
Interestingly, inspection of the built artifacts in the schroot after all is
done yields:
# find . -name
Barry A. Warsaw added the comment:
First failure in test run afaict:
==
ERROR: test_recursive_dict_subclass_and_inst
(test.test_cpickle.cStringIOCPicklerFastTests
Barry A. Warsaw added the comment:
But if I just run test_cpickle.py, it succeeds!
--
___
Python tracker
<http://bugs.python.org/issue25698>
___
___
Python-bug
Barry A. Warsaw added the comment:
I set a breakpoint where the error occurs. I'm in test_cpickle.py dumps().
Doing cPickle.dumps(arg) in the bp, I get the error. arg is:
(Pdb) arg
{<__main__.H object at 0x7ff8e2a870d0>: None}
(Pdb) type(arg)
Look again at the AttributeE
Barry A. Warsaw added the comment:
I'm duping this one to issue25698 because while it came later, it has a lot
more information. They are clearly the same bug.
--
nosy: +barry
superseder: -> The copy_reg module becomes unexpectedly empty in test
Barry A. Warsaw added the comment:
Well, one thing I noticed is that init_stuff() in cPickle.c can leak the
copy_reg module object, if any of the subsequent PyObject_GetAttr*() calls
fail. They return -1 without decref'ing copyreg. Probably not a horrible leak
since it's probably
Barry A. Warsaw added the comment:
At the problematic breakpoint mentioned in msg255630, copy_reg is nearly empty.
(Pdb) sys.modules['copy_reg']
(Pdb) dir(sys.modules['copy_reg'])
['__builtins__', '__doc__', '__file__', '__name__', &
Barry A. Warsaw added the comment:
This just gets weirder. I've narrowed it down to running this command:
build-static/python Lib/test/regrtest.py test_doctest test_cpickle
fails every time. What's even weirder is that I hacked regrtest to print some
useful information before and
Barry A. Warsaw added the comment:
On Dec 01, 2015, at 06:26 PM, Barry A. Warsaw wrote:
>I'll note one other thing. Doko mentioned that in our build environment,
>cPickle is built in, not an extension.
Which may be relevant because in a from-hg-head build of Python 2.7, this
prob
Barry A. Warsaw added the comment:
On Dec 01, 2015, at 06:47 PM, Serhiy Storchaka wrote:
>Thanks Barry. Running test_cpickle after test_doctest I now can reproduce the
>problem in a from-hg-head build of Python 2.7.
That's interesting because I can't! (Neither from the 2
Barry A. Warsaw added the comment:
I added cPickle to Modules/Setup.local and rebuilt from hg. cPickle's a
built-in but I still can't reproduce the problem.
--
___
Python tracker
<http://bugs.python.o
Barry A. Warsaw added the comment:
On Dec 05, 2015, at 07:03 AM, Benjamin Peterson wrote:
>The underlying issue is classic: PyDict_SetItem returns NULL if the stack is
>too deep. This confuses import.
Thanks for digging into this Benjamin. I'm not able to investigate further
atm
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue25833>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I'm reopening this issue because we're starting to see a bunch of regressions
in Debian and Ubuntu we think is caused by the changes here. We've definitely
started seeing them with 3.5.1, where packages that use Cython built just fine
in 3.5
Barry A. Warsaw added the comment:
On Jan 06, 2016, at 10:13 PM, Serhiy Storchaka wrote:
>What return __reduce_ex__(4) for the NameAssignment instance in 3.5.0?
I'm not sure yet (it takes some time to set up the right environment to test
this), but I do know which TypeError is
Barry A. Warsaw added the comment:
Your explanation still doesn't entirely make sense to me yet because the crash
is happening in what seems to be a Cython implementation class, not a generated
class based on a .pyx in some other project using Cython.
I tried to search the Cython Tra
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue26036>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
You asked what reductor(4) returns in Python 3.5.0:
> /usr/lib/python3.5/copy.py(176)deepcopy()
-> rv = reductor(4)
(Pdb) reductor(4)
(, (,), None, None, None)
And this is completely reasonable:
(Pdb) p rv
(, (,), None, None, None)
(Pdb) p rv[0]
Barry A. Warsaw added the comment:
I added some debugging to the if(required) clause. This is interesting:
basicsize 16
slotnames 0 basicsize 16
tp_basicsize 80 basicsize 16
tp_basicsize comes in at 16 bytes. tp_dictoffset and tp_weaklistoffset must
both be 0, and while slotnames is not
Barry A. Warsaw added the comment:
So yeah, I guess Cython is doing something magical to boost the instance's
type's basicsize, but I can't tell what from the Python prompt. It also
clearly doesn't affect the un/picklability of the instance, so I think the
entire check i
Barry A. Warsaw added the comment:
I've verified that backing out the typeobject.c change allows kivy and pysam to
build. s3ql still fails but for other reasons, though its build does get past
the cython failure. This clinches it for me. I am going to remove the
typeobject.c clause
Barry A. Warsaw added the comment:
On Jan 11, 2016, at 05:50 PM, Serhiy Storchaka wrote:
>
>Therefore my guess was true. There is a bug in Cython. It creates classes
>that can't be correctly unpickled or copied.
I don't think that's necessarily true. Clearly the cla
Barry A. Warsaw added the comment:
On Jan 11, 2016, at 07:20 PM, Serhiy Storchaka wrote:
>I think we have to left this restriction in 3.6 (and Cython should fix its
>bug by providing either __getnewargs__/ __getnewargs_ex__, __getstate__ or
>__reduce__/__reduce_ex__). But in 2.7 a
Barry A. Warsaw added the comment:
BTW Serhiy, can you please file a bug with upstream Cython? I think you're the
right person to do it since you added this restriction. With reverting this in
2.7 and 3.5 it's not urgent, but we don't want to have to reopen this w
Barry A. Warsaw added the comment:
Thanks Stefan and Serhiy! I think this issue is now resolved.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
Barry A. Warsaw added the comment:
Is this a bug though? No guarantees of dict order exists, regardless of
whether the dict changes or not, right? Even if the implementation used to, or
in some circumstances still does, appear to preserve iteration order, you
shouldn't count
Barry A. Warsaw added the comment:
Tangentially, I'm kind of hoping we can get this into 3.6 as an asyncio
replacement for smtpd: https://gitlab.com/python-smtpd-hackers/aiosmtpd
--
___
Python tracker
<http://bugs.python.org/is
On 03.02.2016 18:05, STINNER Victor wrote:
>
>> python -m timeit "sum([x * x * 1 for x in range(100)])"
>
> If you only want to benchmark x*y, x+y and list-comprehension, you
> should use a tuple for the iterator.
... and precalculate that in the setup:
python -m
On 05.02.2016 16:14, STINNER Victor wrote:
>
> Please don't. I would like to have time to benchmark all these patches (there
> are now 9 patches attached to the issue :-)) and I would like to hear
> Serhiy's feedback on your latest patches.
Regardless of the performance, the fastint5.patch look
Barry A. Warsaw added the comment:
Thanks for digging deeply and fixing this!
--
___
Python tracker
<http://bugs.python.org/issue25698>
___
___
Python-bugs-list m
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue26408>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
assignee: docs@python -> barry
___
Python tracker
<http://bugs.python.org/issue26408>
___
___
Python-bugs-list mailing list
Un
Barry A. Warsaw added the comment:
Thanks! I like some of the changes, and may tweak a few others. Thanks for
the contribution.
--
___
Python tracker
<http://bugs.python.org/issue26
Barry A. Warsaw added the comment:
On Feb 22, 2016, at 02:20 PM, Georg Brandl wrote:
>Georg Brandl added the comment:
>
>-Consistency within one module or function is most important.
>+Consistency within one module or function is the most important.
>
>You left out "th
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue26176>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue26426>
___
___
Python-bugs-list mailing list
Unsubscribe:
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&
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):
2301 - 2400 of 2582 matches
Mail list logo