[issue11921] distutils2 should be able to compile an Extension based on the Python implementation version
dholth added the comment: Yes, putting implementation-specific environment markers in the Extensions section is the idea (instead of the haphazard and occasionally-applied 'Python code in setup.py appends to a list of extensions' method). An Extension can only be optional when there is equivalent and working Python code. This isn't likely to happen for libraries like PIL where the foreign code provides core functionality instead of a speedup. The reason I submitted this bug is that as Pypy's C API improves it can successfully compile Extensions to its detriment. Unlike Jython which IIRC has no C API, Pypy cannot patch Extension to always fail, but some of those Extensions are slower than the equivalent Python. I think there ought to be a declarative way to mark an extension as a. Required b. Optional and preferred c. Optional, not preferred depending on the Python implementation. For (b) and (c) it would also be quite cool to have a standard flag or runtime mechanism to switch between the C and Python implementation to see which one was really faster (could be done with an import hook?). -- ___ Python tracker <http://bugs.python.org/issue11921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11921] distutils2 should be able to compile an Extension based on the Python implementation version
New submission from dholth : It might be useful to be able to declare optional Extensions that for example won't attempt to compile on Jython or any implementation of Python for which the extension (a) doesn't work or (b) would be slower than the Python fallback. I suppose this could be accomplished without changing anything by packaging the extension separately and using the extant "; plat=win32" style dependency qualifiers? -- assignee: tarek components: Distutils2 messages: 134394 nosy: alexis, dholth, eric.araujo, tarek priority: normal severity: normal status: open title: distutils2 should be able to compile an Extension based on the Python implementation version versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue11921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11880] add a {dist-info} category to distutils2
New submission from dholth :
In distutils2 there is currently no way to add files such as egg_info.txt that
should be part of the package metadata. A new category named the same as the
.dist-info directory would be a nice way to do it.
distutils2 should raise an error if any of the reserved files are overwritten
with this feature or it should just copy these first overwriting with the
reserved names.
It might be a good idea to disallow subdirectories in dist-info.
--
assignee: tarek
components: Distutils2
messages: 134077
nosy: alexis, dholth, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: add a {dist-info} category to distutils2
type: feature request
___
Python tracker
<http://bugs.python.org/issue11880>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module should allow DDL statements in transactions
dholth added the comment: Torsten basically you are suggesting that PRAGMA would never work at all with my 'do not strcmp() the sql at all, always begin a transaction' approach? -- ___ Python tracker <http://bugs.python.org/issue10740> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11624] distutils should support a custom list of exported symbols for Windows dlls.
New submission from dholth : I would like to be able to use distutils to compile a shared library with a different set of exported symbols than the default. In Windows, distutils only exports certain symbols needed for the Python module initialization API when it compiles a shared module. It does this by passing a file to the C compiler that lists those symbols. In Linux all symbols are exported/visible by default because that's just how the linker has traditionally worked. I would like to be able to override or augment this list of symbols. Probably by just providing my own 'symbols to export' file. distutils is definitely the poor man's compiler frontend but this feature would make it easier for me to support Windows (Python's secret shame.) -- assignee: tarek components: Distutils2 messages: 131677 nosy: alexis, dholth, eric.araujo, tarek priority: normal severity: normal status: open title: distutils should support a custom list of exported symbols for Windows dlls. type: feature request versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue11624> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9924] sqlite3 SELECT does not BEGIN a transaction, but should according to spec
dholth added the comment: What should this option be called? connect(strict=True) ? -- nosy: +dholth ___ Python tracker <http://bugs.python.org/issue9924> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module should allow DDL statements in transactions
dholth added the comment: I want transactional DDL too. I was tremendously surprised that I could not duplicate the way sqlite3 behaves on the command line from witin pysqlite. Instead of this patch, I would rather be able to instruct pysqlite to always begin a transaction for any kind of statement (I hear this is a requirement for DB-API compliance) and never perform an implicit commit for any reason. For example, someone on the google code project had a complaint that 'SAVEPOINT' (create a subtransaction) automatically commits because pysqlite doesn't know about it. I tried to trick pysqlite into doing what I wanted by prepending /* update */ to every CREATE TABLE statement but it didn't seem to quite work. Instead, I would prefer a pysqlite that does not strcmp(statement) at all. -- nosy: +dholth ___ Python tracker <http://bugs.python.org/issue10740> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8713] multiprocessing needs option to eschew fork() under Linux
dholth added the comment: +1 -- nosy: +dholth ___ Python tracker <http://bugs.python.org/issue8713> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7791] Python 2.6 standard library "sees also" something not in the standard library
dholth added the comment: Also ipaddr.BaseIP.packed is a property, not a method, so no () -- ___ Python tracker <http://bugs.python.org/issue7791> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7791] Python 2.6 standard library "sees also" something not in the standard library
New submission from dholth : I thought it was really odd that the standard library documentation references ipaddr, a module from pypi, not something else in the standard library. The documentation should explain that the referenced package is not a standard part of Python. http://docs.python.org/library/socket.html#socket.inet_pton See also ipaddr.BaseIP.packed() Platform-independent conversion to a packed, binary format. -- assignee: georg.brandl components: Documentation messages: 98384 nosy: dholth, georg.brandl severity: normal status: open title: Python 2.6 standard library "sees also" something not in the standard library versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue7791> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7748] unicode supported in distutils register but not distutils upload
New submission from dholth :
# -*- encoding: utf-8 -*-
# Will not 'python setup.py upload':
setup(name='acute_e', version='0.1', description=u'é')
It looks like someone fixed this for register but forgot to copy it into upload:
+# Build up the MIME payload for the POST data
boundary = '--GHSKFJDLGDS7543FJKLFHRE75642756743254'
sep_boundary = '\n--' + boundary
end_boundary = sep_boundary + '--'
body = StringIO.StringIO()
for key, value in data.items():
# handle multiple entries for the same name
-if type(value) not in (type([]), type( () )):
+if type(value) != type([]):
value = [value]
for value in value:
-value = unicode(value).encode("utf-8")
+if type(value) is tuple:
+fn = ';filename="%s"' % value[0]
+value = value[1]
+else:
+fn = ""
+value = str(value)
body.write(sep_boundary)
body.write('\nContent-Disposition: form-data; name="%s"'%key)
+body.write(fn)
body.write("\n\n")
body.write(value)
if value and value[-1] == '\r':
--
assignee: tarek
components: Distutils
messages: 98109
nosy: dholth, tarek
severity: normal
status: open
title: unicode supported in distutils register but not distutils upload
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue7748>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
