John Dennis added the comment:
I think your basic approach is fine and it's O.K. to break backwards
compatibility. I'm not sure anyone was using the httponly and secure flags in
the past because it was so broken, the logic was completely contradictory, so
backwards compatibility should
John Dennis added the comment:
That's because #3073 never addressed the core problems, so yes I would expect
you would see failures. The point of the attached test is to illustrate the
deficiencies in Cookie.py, so apparently it's doing it's job :-)
FWIW, we wrote a new cookie library to get
New submission from John Dennis:
There are multiple problems with Cookie.py. Some of the issues are covered in
http://bugs.python.org/issue3073 which is still open (after 4.5 years).
In all honesty the API and the implementation are not great perhaps the best
thing would be to remove it from
John Dennis jden...@redhat.com added the comment:
The changesets are not in the release27-maint branch. sdist still does not
generate a correct archive for release, this is a very serious regression.
--
resolution: fixed -
status: closed - open
Changes by John Dennis jden...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11104
___
___
Python-bugs-list mailing
John Dennis jden...@redhat.com added the comment:
No, I don't think I'm going to turn the tarball into a unit test, etc. I didn't
break the code but I did report the problem, researched the history, provided a
clear explanation, a reproducer and a patch to fix the problem. I think I've
done
John Dennis jden...@redhat.com added the comment:
$ tar xzf distutils_bug.tar.gz
$ cd distutils_bug
$ ./setup.py sdist
$ ./setup.py sdist
running sdist
running check
warning: sdist: manifest template 'MANIFEST.in' does not exist (using default
file list)
not writing to manually maintained
New submission from John Dennis jden...@redhat.com:
The behaviour of sdist has changed dramatically in Python 2.7. Some projects
prefer to maintain their own manifest file instead of utilizing automatic
manifest generation from a template. The defined behaviour of sdist is to check
Changes by John Dennis jden...@redhat.com:
--
keywords: +patch
Added file: http://bugs.python.org/file20655/sdist.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11104
Changes by John Dennis jden...@redhat.com:
Added file: http://bugs.python.org/file20656/sdist_new
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11104
Changes by John Dennis jden...@redhat.com:
Removed file: http://bugs.python.org/file20655/sdist.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11104
Changes by John Dennis jden...@redhat.com:
Removed file: http://bugs.python.org/file20656/sdist_new
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11104
Changes by John Dennis jden...@redhat.com:
Added file: http://bugs.python.org/file20658/sdist.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11104
Changes by John Dennis jden...@redhat.com:
Added file: http://bugs.python.org/file20659/sdist_new
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11104
your
summer of code? You've got great ideas, but be realistic about what you
can actually accomplish and don't forget for those folks who dislike
pipermail one can with minimal effort use an external archiver.
--
John Dennis [EMAIL PROTECTED]
Red Hat Inc.
--
http://mail.python.org/mailman/listinfo
On Thu, 2006-07-06 at 14:17 -0400, John Dennis wrote:
... don't forget for those folks who dislike
pipermail one can with minimal effort use an external archiver.
Oh, and I should have added that one of the beefs with using an external
archiver is the disjoint UI between mailman
into Mailman lets define the interfaces which are
needed such that Mailman can operate cooperatively with any archiver
which supports a well defined API.
--
John Dennis [EMAIL PROTECTED]
Red Hat Inc.
--
http://mail.python.org/mailman/listinfo/python-list
17 matches
Mail list logo
