Thomas Lotze wrote:
I'm still going to move the zope.publisher.contenttype functionality to
zope.contenttype which will ease some packages' dependencies,
JFTR: I've done that now, including updates to packages which used to
import from zope.publisher.contenttype.
--
Thomas
Thomas Lotze wrote:
I'm still going to move the zope.publisher.contenttype functionality to
zope.contenttype which will ease some packages' dependencies, and I'll try
to move some appropriate bits of code from zope.mimetype to
zope.contenttype.
Before doing so, however, I'd like to release
On Wed, Oct 7, 2009 at 5:03 PM, Thomas Lotze t...@gocept.com wrote:
So as a first step, I'd like to release the current code of
zope.publisher, zope.server, zope.app.authentication and zope.app.i18n.
Can somebody please grant me PyPI rights for these packages? Thank you
very much.
Granted :)
On Wed, Oct 7, 2009 at 11:10 AM, Hanno Schlichting ha...@hannosch.eu wrote:
If someone would document srichter's magic grant-all-powerful PyPi
script, I'd run it :)
That's a horrible thing to do to somebody!
Note that I'm not smiling, either. It's too easy to grant people
access to way too
On Wed, Oct 7, 2009 at 5:17 PM, Fred Drake fdr...@gmail.com wrote:
On Wed, Oct 7, 2009 at 11:10 AM, Hanno Schlichting ha...@hannosch.eu wrote:
If someone would document srichter's magic grant-all-powerful PyPi
script, I'd run it :)
That's a horrible thing to do to somebody!
Note that I'm
Fred Drake wrote:
On Wed, Oct 7, 2009 at 11:10 AM, Hanno Schlichting ha...@hannosch.eu
wrote:
If someone would document srichter's magic grant-all-powerful PyPi
script, I'd run it :)
That's a horrible thing to do to somebody!
Note that I'm not smiling, either. It's too easy to grant
On Wed, Oct 7, 2009 at 11:27 AM, Thomas Lotze t...@gocept.com wrote:
OTOH, even with good usability I'd rather not have rights for packages I'm
not interested in, just to be able to deny responsibility if anything goes
wrong with one of them.
It's entirely reasonable for maintainers to have
Thomas Lotze wrote:
At present, zope.contenttype doesn't have any dependencies within the ZTK,
and zope.mimetype depends on zope.configuration, zope.component and
zope.interface. zope.publisher.contenttype doesn't import any zope code.
- Switching packages that depend on zope.mimetype would
Thomas Lotze wrote:
- zope.contenttype: parsing of MIME-type identifiers, guessing the MIME
type of file contents, preferrably without dependencies within the ZTK
Can I suggest that we use a different name? 'content type' to me sounds
like CMS-y functionality. We have interfaces like
Martin Aspeli wrote:
Thomas Lotze wrote:
- zope.contenttype: parsing of MIME-type identifiers, guessing the MIME
type of file contents, preferrably without dependencies within the ZTK
Can I suggest that we use a different name? 'content type' to me sounds
like CMS-y functionality. We
On Tue, Oct 6, 2009 at 11:56 AM, Martin Aspeli optilude+li...@gmail.com wrote:
Thomas Lotze wrote:
- zope.contenttype: parsing of MIME-type identifiers, guessing the MIME
type of file contents, preferrably without dependencies within the ZTK
Can I suggest that we use a different name?
Hanno Schlichting wrote:
On Tue, Oct 6, 2009 at 11:56 AM, Martin Aspeli optilude+li...@gmail.com
wrote:
Thomas Lotze wrote:
- zope.contenttype: parsing of MIME-type identifiers, guessing the MIME
type of file contents, preferrably without dependencies within the ZTK
Can I suggest that we
Following up to Martijn's observations on the ZTK, I'd like to propose a
clean-up of how we handle content types. There are several unrelated
pieces of code concerned with content types, these include at least
zope.contenttype, zope.mimetype and zope.publisher.contenttype.
- zope.contenttype does
Thomas Lotze wrote:
Following up to Martijn's observations on the ZTK, I'd like to propose a
clean-up of how we handle content types. There are several unrelated
pieces of code concerned with content types, these include at least
zope.contenttype, zope.mimetype and zope.publisher.contenttype.
Tres Seaver wrote:
Thomas Lotze wrote:
Following up to Martijn's observations on the ZTK, I'd like to propose a
clean-up of how we handle content types. There are several unrelated
pieces of code concerned with content types, these include at least
zope.contenttype, zope.mimetype and
On Thu, Oct 1, 2009 at 4:44 PM, Thomas Lotze t...@gocept.com wrote:
I also wonder whether it might make sense to utilise the /etc/mime.types
database (or the system's equivalent) for guessing based on the file-name
extension, and libmagic (if available) for magic-number tests based on
file
Thomas Lotze wrote:
I also wonder whether it might make sense to utilise the /etc/mime.types
database (or the system's equivalent) for guessing based on the file-name
extension,
The Python mimetypes module already uses that file in any of the
standard Unix locations.
and libmagic (if
Hello,
That sounds impressing.
Definitely something to watch in the refactoring process is having all
this working on win32 ;-)
Thursday, October 1, 2009, 5:11:10 PM, you wrote:
HS For mime type information it looks at:
HS - all information found in the
HS
18 matches
Mail list logo
