[issue44605] functools.total_ordering doesn't work with metaclasses
Glyph Lefkowitz added the comment: My preference would be to fix it one way or another; the stdlib should be correct before it's performant. If, as you say, it's better to write the methods longhand anyway for ease of debugging, then it makes sense to write them out for performance, too. -- ___ Python tracker <https://bugs.python.org/issue44605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44605] functools.total_ordering doesn't work with metaclasses
Glyph Lefkowitz added the comment: > We could do that and not incur performance issues. However, it would expand > the API and double the size of the code. If the preference is to not support this use-case, then I'd rather the decorator simply raise an exception and tell me this is going to be a problem so I can eagerly implement the workaround. > It seems like a rare niche use case, and the workaround is simple. It does seem like there are various times that one might want to make classes orderable, for example if they are bound to IDL objects or database tables; the use-case where I ran into this was something like that. > For production code, I usually recommend writing out the other three methods > (that is less magical, runs faster, easier to test, has fewer dependencies, > and makes the tracebacks more readable. Wait, is the suggestion here that @total_ordering is not suitable for production? -- ___ Python tracker <https://bugs.python.org/issue44605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44605] functools.total_ordering doesn't work with metaclasses
Glyph Lefkowitz added the comment: > Do you all have preference for 1) expanding the range of use cases to cover > metaclasses but incurring a performance hit for common cases, or 2) leaving > it as-is and documenting that it doesn't work for metaclasses? If we do need the slow approach for the meta-type case, (i.e.: type(self).__lt__(other)) then why not decide on implementation at decoration time? The decorator has enough information to know if this strategy is necessary and can put different special methods in place. (But also, wouldn't 'from operator import lt ... lt(self, other)' be a bit faster, and also more general, just because it's doing specialized dispatch in C rather than an additional Python function call / method dispatch? I have not benchmarked myself, so please ignore if you've already tested this.) -- ___ Python tracker <https://bugs.python.org/issue44605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44605] functools.total_ordering doesn't work with metaclasses
Glyph Lefkowitz added the comment: Adding versions after confirming the bug is the same on 3.10 -- versions: +Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue44605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44605] functools.total_ordering doesn't work with metaclasses
New submission from Glyph Lefkowitz : Consider the following example that attempts to make a series of types sortable by their class name: from functools import total_ordering @total_ordering class SortableMeta(type): def __new__(cls, name, bases, ns): return super().__new__(cls, name, bases, ns) def __lt__(self, other): if not isinstance(other, SortableMeta): pass return self.__name__ < other.__name__ def __eq__(self, other): if not isinstance(other, SortableMeta): pass return self.__name__ == other.__name__ class B(metaclass=SortableMeta): pass class A(metaclass=SortableMeta): pass print(A < B) print(A > B) This should just print "True", "False", but instead the second comparison raises this exception: Traceback (most recent call last): File "total_ordering_metaclass.py", line 27, in print(A > B) File "lib/python3.9/functools.py", line 91, in _gt_from_lt op_result = self.__lt__(other) TypeError: expected 1 argument, got 0 The problem here is that functools considers .__special__ to be equivalent to operator.special. I'm pretty sure this should be invoking "self < other" rather than self.__lt__(other). -- components: Library (Lib) messages: 397278 nosy: glyph priority: normal severity: normal stage: needs patch status: open title: functools.total_ordering doesn't work with metaclasses type: behavior versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8084] pep-0370 on osx duplicates existing functionality
Glyph Lefkowitz added the comment: For what it's worth, I've long since adapted to the status quo here, so I'm happy for this to just be closed :-). (Apple seems to have mostly given up on "domains" as a user-facing or even developer-facing concept, so searching /Network seems like it is not relevant any more. /System is now read-only even for root and they're deprecating the Python installed there; still, the up-to-date reference for the relevant API is https://developer.apple.com/documentation/foundation/nsfilemanager/1407726-urlsfordirectory?language=objc# ) -- ___ Python tracker <https://bugs.python.org/issue8084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41987] singledispatchmethod raises an error when relying on a forward declaration
Glyph Lefkowitz added the comment: The behavior is the same with a traditional quoted forward declaration, so it’s not specific to the __future__ import; I just phrased the example that way to show how it’s going to look in the future and to illustrate how it might crop up in a way which is maximally confusing to users less familiar with the internals of type annotations. -- ___ Python tracker <https://bugs.python.org/issue41987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41987] singledispatchmethod raises an error when relying on a forward declaration
New submission from Glyph Lefkowitz :
This example:
from __future__ import annotations
from functools import singledispatchmethod
class Comparable:
@singledispatchmethod
def compare(self, arg: object):
raise NotImplementedError("what")
@compare.register
def _(self, arg: Comparable):
return "somewhat similar"
print(Comparable().compare(Comparable()))
Produces this result:
File
"/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/typing.py",
line 518, in _evaluate
eval(self.__forward_code__, globalns, localns),
File "", line 1, in
NameError: name 'Comparable' is not defined
It seems like perhaps singledispatchmethod should defer its type evaluation to
its first invocation?
--
components: Library (Lib)
messages: 378346
nosy: glyph
priority: normal
severity: normal
stage: needs patch
status: open
title: singledispatchmethod raises an error when relying on a forward
declaration
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue41987>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39679] functools: singledispatchmethod doesn't work with classmethod
Glyph Lefkowitz added the comment: I also just discovered this. I thought it must have regressed at some point but I see the docs say "new in 3.8" and I'm using 3.8. Is there a "no CI for examples in the docs" issue that this could be linked to? -- nosy: +glyph ___ Python tracker <https://bugs.python.org/issue39679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27035] Cannot set exit code in atexit callback
Glyph Lefkowitz added the comment: gwk, I absolutely agree; at this point that's the main thing I'm looking for. But it would be great if whoever adds that documentation could include the rationale for this behavior too. It still seems "obvious" to me that it should change the exit code, and every time I bump into this behavior I am freshly confused and have to re-read these bugs. If I had a better intuition for what the error-handling *model* of atexit was, I think it might stick to memory a bit better. -- ___ Python tracker <https://bugs.python.org/issue27035> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27035] Cannot set exit code in atexit callback
Glyph Lefkowitz added the comment: This bug has been filed several times: issue1257 issue11654 and it's tempting to simply close this as a dup, but this ticket mentions the documentation, which is slightly confusing: https://docs.python.org/3.8/library/atexit.html#atexit.register It's not *wrong* exactly; 3.8's behavior matches the letter of the documentation, but "the last exception to be raised is re-raised" *implies* a change in exit code, since that is what would normally happen if an exception were re-raised at the top level. So would it be a good idea to change the documentation? -- ___ Python tracker <https://bugs.python.org/issue27035> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11654] errors in atexit hooks don't change process exit code
Glyph Lefkowitz added the comment: I hope nobody will mind if I close: It's a duplicate of issue1257 so future discussion, if any, should probably happen there. -- nosy: +glyph resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue11654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30392] default webbrowser fails on macOS Sierra 10.12.5
Changes by Glyph Lefkowitz <gl...@twistedmatrix.com>: -- status: open -> pending ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30392> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30392] default webbrowser fails on macOS Sierra 10.12.5
Changes by Glyph Lefkowitz <gl...@twistedmatrix.com>: -- nosy: +glyph status: pending -> open ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30392> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22559] [backport] ssl.MemoryBIO
Glyph Lefkowitz added the comment: For what it's worth, it would still be great if this could be merged. It could help a lot with 2/3 migrations of async code that uses Twisted and wants to adopt some asyncio parts. Right now the stdlib SSL module is de-facto useless in those scenarios and depending on pyOpenSSL is pretty much the only choice, and the lack of availability of a memory BIO on 2.x is the biggest blocker. -- nosy: +glyph ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22559> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27035] Cannot set exit code in atexit callback
Glyph Lefkowitz added the comment: I just bumped into this myself. If this really is only fixable in a major release, there ought to at least be a minor release for the *documentation* to update it to be correct. -- nosy: +glyph ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27035> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Glyph Lefkowitz added the comment: OK, cool. So, long term, there will be a way to do this (suspend within a generator expression). Thanks for the pointer. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Glyph Lefkowitz added the comment: (As far as awaiting on int, yes, I know how await works, I was focusing on the syntax.) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Glyph Lefkowitz added the comment: >>> async def foo(): ... bar = [await x for x in range(10)] File "", line 2 SyntaxError: 'await' expressions in comprehensions are not supported -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Glyph Lefkowitz added the comment: Is the fact that 'await' produces a syntax error in this context the same bug or a new one? -- nosy: +glyph ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27706] Random.seed, whose purpose is purportedly determinism, behaves non-deterministically with strings due to hash randomization
Glyph Lefkowitz added the comment: For what it's worth, I don't much care whether this is fixed or not; I ended up wanting to leak less information from the RNG output anyway so I wrote this: https://gist.github.com/glyph/ceca96100a3049fefea6f2035abbd9ea but I felt like it should be reported. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27706] Random.seed, whose purpose is purportedly determinism, behaves non-deterministically with strings due to hash randomization
Glyph Lefkowitz added the comment: Changing the affected version to just 2.7. -- versions: -Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27706] Random.seed, whose purpose is purportedly determinism, behaves non-deterministically with strings due to hash randomization
Glyph Lefkowitz added the comment:
It does seem to be stable on python 3, but on python 2.7 it's definitely a
problem:
$ python -Rc "import random; r=random.Random('abc'); print(''.join(map(str,
(r.randrange(10) for x in range(10, hash('abc'))"
('9553343809', -1972659830997666042)
$ python -Rc "import random; r=random.Random('abc'); print(''.join(map(str,
(r.randrange(10) for x in range(10, hash('abc'))"
('5519010739', 5520208254012363023)
$ python -Rc "import random; r=random.Random('abc'); print(''.join(map(str,
(r.randrange(10) for x in range(10, hash('abc'))"
('7519888435', 3560222494758569319)
$ python -Rc "import random; r=random.Random('abc'); print(''.join(map(str,
(r.randrange(10) for x in range(10, hash('abc'))"
('9612648103', 4134882069837806740)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27706>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27706] Random.seed, whose purpose is purportedly determinism, behaves non-deterministically with strings due to hash randomization
New submission from Glyph Lefkowitz:
The purpose of 'seeding' a random number generator is usually to supply a
deterministic sequence of values starting from a known point. This works fine
if you seed random.Random with an integer. Often (for example, see Minecraft's
map generation interface) one wants to begin with a human-memorable string as
the seed, and superficially it would seem that passing a string to Random.seed
would serve exactly this use-case. In fact in its original incarnation it did.
However, since the introduction of PYTHONHASHSEED in 2.6.8, it's possible that
strings now hash to different values, and on 3.2+, they'll _always_ hash to
different values unless otherwise configured (which, as per the reason for
introducing this feature in the first place, is a security flaw).
Right now the way to work around this is to get some deterministic hash from
your string; one mechanism being a truncated SHA256 hash, for example, like
this:
Random(struct.unpack("!I", sha256(seed.encode("utf-8")).digest()[:4])[0])
but this strikes me as an obscure trick to require of someone just trying to
get their D character generator to produce the same values twice in a row for
unit testing.
I'm not sure what the resolution should be, but I figured I should report this
since I tripped over it.
--
components: Library (Lib)
messages: 272137
nosy: glyph
priority: normal
severity: normal
status: open
title: Random.seed, whose purpose is purportedly determinism, behaves
non-deterministically with strings due to hash randomization
type: behavior
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27706>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7175] Define a standard location and API for configuration files
Glyph Lefkowitz added the comment: XDG_CONFIG_HOME is not generally set to anything; the default of ~/.config is usually fine. However, the point is that you _can_ set it to point at a different location. The relevant specification is here: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html The biggest reason I strongly believe we should follow a specification is that Python is not the only software on the system. If I am an ops person that has to deal with Python and Ruby and Java and C software all the time, *any* consistency is a big help. We don't have to follow *this* specification, but we should follow *some* specification (although this specific one looks like a good one to me). The Python community has no special expertise deciding on locations for configuration files, and so we should not be trying to invent a new and better place for them. 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), users can easily switch between configuration environments by switching the XDG environment variables (both XDG_CONFIG_DIRS and XDG_CONFIG_HOME), which would be a handy way of ignoring both user-specified config files _and_ system-specified ones, to get a pristine virtualenv-like separation between different config files. Given that they are going to need to set these env vars anyway to redirect spec-compliant libraries that their application may be using, it would be nice to just have _one_ set of meta-configuration variables rather than one for Python and one for C and one for Ruby and so on. Consider the fact that distutils respects "CFLAGS", and did not feel the need to invent "DISTUTILS_FLAGS_FOR_THE_C_COMPILER". -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22187] commands.mkarg() buggy in East Asian locales
Glyph Lefkowitz added the comment: Would simply replacing this function with pipes.quote resolve the issue? -- nosy: +glyph ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22187 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21965] Add support for Memory BIO to _ssl
Changes by Glyph Lefkowitz gl...@twistedmatrix.com: -- nosy: -glyph ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21965 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21965] Add support for Memory BIO to _ssl
Glyph Lefkowitz added the comment: I don't have a whole lot to add. I strongly recommended that this be done this way twice, once when ssl was added to Python and once when ssl was added to tulip, so I'm glad to see it's happening now. Regarding the specific implementation I am unlikely to have the interest in reviewing the code because I already have a working TLS implementation which does this. Nevertheless, if it works to get the proactor interfaces to support SSL, then it is almost certainly adequate. It would be great to eliminate the dependency on OpenSSL's writing-to-a-socket code entirely; Python already knows how to write to a socket, and it probably knows how to do it better than OpenSSL does. My only further input is that this code should all be deleted and replaced with pyOpenSSL or at least a separate thin wrapper over PyCA's Cryptography bindings. My Cassandra complex and I look forward to this advice becoming obvious to everyone else in 5-7 years :-). In the meanwhile, I will de-nosy myself. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21965 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21669] Custom error messages when print exec are used as statements
Glyph Lefkowitz added the comment: Just my 2¢ here: rather than debating cases in the abstract, it would be interesting to 'pip install' a couple of popular 2.x-only packages and see if the error message is an improvement. My experience is that learners don't hit this so much by writing their own code wrong, but by loading a dependency with incorrect metadata on the wrong Python. (Which suggests to me that a URL in the error message telling you how to download a different version of Python would be very helpful as well.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21669 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Glyph Lefkowitz added the comment: Tempting as it is to reply to the comment about 'buffer' not existing, we're way off topic here. Let's please keep further comments on this bug to issues about a 'format' methods on the 'bytes' object. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Glyph Lefkowitz added the comment: On Oct 8, 2013, at 8:10 AM, Augie Fackler rep...@bugs.python.org wrote: Hah. Probably too slow for anything beyond a proof of concept, no? It should perform acceptably on PyPy ;-). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Glyph Lefkowitz added the comment: On Oct 8, 2013, at 2:35 PM, Eric V. Smith wrote: What proposal is actually on the table here? Sorry Eric, you're right, there is too much discussion here. This issue ought to be about .format, like the title says. There should be a separate ticket for %-formatting, since it seems to be an almost wholly unrelated task. While I'm sympathetic to Mercurial's issues, they're somewhat different from Twisted's, in that we're willing to adopt the one new way to do things in order to achieve compatibility whereas that would be too hard for Mercurial. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Glyph Lefkowitz added the comment: On Oct 8, 2013, at 3:19 PM, Augie Fackler wrote: No, I'm not. In Mercurial, all end-user data is OPAQUE BYTES, and must remain that way. The PEP 383 technique for handling file names is completely capable of round-tripping exact bytes, given one encoding for both input and output. You can still handle file names this way internally in Mercurial and not risk disturbing any observable output. You do not need to change that in order to do what Victor suggests. We should get together in some other forum and discuss file-name handling though, since you can't actually round-trip opaque bytes through a *filesystem* and not disturb your output. Ouch. Is there any way to write things to stderr and stdout without decoding and hopelessly breaking user data? You can use sys.stdout.buffer.write. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18391] socket.fromfd()'s API is difficult or impossible to use correctly in general
Glyph Lefkowitz added the comment: It would be nice for this to be fixed in a 2.7.x release too, if possible, since the workaround involves a ton of extra system calls and there's no other way to construct a socket object directly. -- nosy: +glyph versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18391 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17496] OS X test for Tk availability in runtktests.py doesn't work
Glyph Lefkowitz added the comment: Wouldn't it be better to check for the actual problem, that is use subprocess to start a small Tcl script that creates a window and check if that crashes? Yes, this sounds great. Doing it with Tcl means that we're not invoking any of the problematic code in question. It sounds like this check could be done on other platforms as well, in lieu of looking for e.g. $DISPLAY. If a tcl script can make tk windows, so should a Python script be able to. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17496 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17496] OS X test for Tk availability in runtktests.py doesn't work
Glyph Lefkowitz added the comment: Hi Ned, It seems from your comment that you didn't read the patch. Alex added a simpler check via launchctl, rather than by framework symbol groveling :). He didn't remove the check. It should be functionally identical to what's there now, but much shorter and without having to depend on ctypes. -glyph -- nosy: +glyph ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17496 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17298] Twisted test failure triggered by change in 2.7 branch
Glyph Lefkowitz added the comment: Confirmed. Thanks very much for addressing it promptly. -- resolution: - duplicate status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17298] Twisted test failure triggered by change in 2.7 branch
New submission from Glyph Lefkowitz: As reported in Twisted: https://twistedmatrix.com/trac/ticket/6314 and as seen on the Twisted buildbot: https://buildbot.twistedmatrix.com/builders/lucid32-py2.7maint/builds/2327/steps/trial/logs/problems The tip of the 2.7 branch is now failing Twisted's test suite. The nature of the bug is not immediately obvious, but it looks like certain previously-working pickles are now raising MemoryError when we attempt to load them. -- components: Library (Lib) messages: 182993 nosy: benjamin.peterson, glyph priority: release blocker severity: normal stage: needs patch status: open title: Twisted test failure triggered by change in 2.7 branch type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17298] Twisted test failure triggered by change in 2.7 branch
Glyph Lefkowitz added the comment: Yes; perhaps that change should be rolled back until a fix for the regression can be added? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Glyph Lefkowitz added the comment:
On Jan 22, 2013, at 11:27 PM, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou added the comment:
The ASCII superset commands part is clearly separated from the binary
data part. Your own LineReceiver is able to switch between raw mode
and line mode; one is text and the other is binary.
This is incorrect. Lines are just CRLF (0x0D0A) separated chunks of data.
For example, SMTP is always in line-mode, but messages (data lines) may
contain arbitrary 8-bit data.
This is a non-sequitur. You can fully well (...)
So, yes, it is reasonably possible, and it even makes sense.
I concede it is possible to implement what you're talking about, but it still
requires encoding things which are potentially 8-bit data. Yes, there are many
corners of protocols where said data looks like text, but it is an optical
illusion.
even disregarding compatibility with a 2.x codebase, b''.join() and
b'' + b'' and (''.format()).encode('charmap') are all slower _and_
more awkward than simply b''.format() or b''%.
How can existing constructions be slower than non-existing constructions
that don't have performance numbers at all?
Sorry, in 2.x :).
Besides, if b''.join() is too slow, it deserves to be improved. Or
perhaps you should try bytearray instead, or even io.BytesIO.
As others have noted, b''.join is *not* slower than b''.format for simply
assembling strings; b''.join is indeed faster at that and I didn't mean to say
it wasn't. The performance improvement shows up when you are assembling
complex messages that contain a smattering of ints, floats, and other chunks of
bytes; mostly in that you can avoid a bunch of python code execution and python
function calls when formatting those values. The trouble with cooking up an
example of this is that it starts to involve a bunch of additional code
complexity and it requires careful framing to make sure the other complexity
isn't what's getting in the way. I will try to come up with one, maybe doing
so will prove even this contention wrong.
But, the main issue here is expressiveness, not performance.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3982
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Glyph Lefkowitz added the comment: On Jan 22, 2013, at 11:31 PM, Martin v. Löwis rep...@bugs.python.org wrote: I admit that it is puzzling that string interpolation is apparently the fastest way to assemble byte strings. It involves parsing the format string, so it ought to be slower than anything that merely concatenates (such as cStringIO). (I do understand why + is inefficient, as it creates temporary objects) You're correct about this; see my previous comment. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Glyph Lefkowitz added the comment: On Jan 23, 2013, at 1:58 AM, Antoine Pitrou rep...@bugs.python.org wrote: Numbers currently don't have a __bytes__ method: (5).__bytes__() Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'int' object has no attribute '__bytes__' They do have some rather odd behavior when passed to the builtin though: bytes(10) b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' It would be much more convenient for me if bytes(int) returned the ASCIIfication of that int; but honestly, even an error would be better than this behavior. (If I wanted this behavior - which I never have - I'd rather it be a classmethod, invoked like bytes.zeroes(n).) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Glyph Lefkowitz added the comment: On Jan 23, 2013, at 11:02 AM, Antoine Pitrou rep...@bugs.python.org wrote: I would agree with you, but it's probably too late to change... Understandable, and, in any case, out of scope for this ticket. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12411] cgi.parse_multipart is broken on 3.x
Changes by Glyph Lefkowitz gl...@twistedmatrix.com: -- nosy: +glyph ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12411 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Changes by Glyph Lefkowitz gl...@twistedmatrix.com: -- nosy: +glyph ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15958] bytes.join() should allow arbitrary buffer objects
Changes by Glyph Lefkowitz gl...@twistedmatrix.com: -- nosy: +glyph ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Glyph Lefkowitz added the comment:
On Jan 22, 2013, at 11:39 AM, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou added the comment:
I agree with the idea that the feature set should very limited, actually
perhaps more limited than what you just said. For example, I think any kind
of implicit str-bytes conversion is a no-no (including the r and a
format codes).
Twisted doesn't particularly need str-bytes conversion in this step, implicit
or otherwise, so I have no problem with leaving that out.
Still, IMO even a simple feature set warrants a PEP, because we want to
devise something that's generally useful, not just something which makes
porting easier for Twisted.
Would it really be so bad to add features that would make porting Twisted
easier? Even if you want porting Twisted to be as hard as possible, there are
plenty of other Python applications that don't use Twisted which nevertheless
need to emit formatted sequences of bytes. Twisted itself is a good proxy for
this class of application; I really don't think that this is overly specific.
I also kind of expect Twisted to have worked around the issue before 3.4 is
out, anyway.
The problem is impossible to work around in the general case. While we can
come up with clever workarounds for things internal to buffering
implementations or our own protocols, Twisted exposes an API that allows third
parties to write protocol implementations, which quite a few people do. Every
one of those implementations (and every one of Twisted's internal
implementations, none of which are ported yet, just the core) faces a series of
frustrating implementation choices where the old style of b'x' % y or
b'x'.format(y) resulted in readable, efficient value interpolation into
protocol messages, but the new style of b''.join([b'x1', y_to_bytes(y),
b'x2']) requires custom functions, inefficient copying, redundant bytes-text
transcoding, and harder-to-read protocol framing literals. This interacts even
more poorly with oddities like bytes(int) returning zeroes now, so there's not
even a reasonable 2-3 compatible way of, say, setting an HTTP content-length
header; b'Content-
length: {}\r\n'.format(length) is now b''.join([b'Content-length: ', (bytes if
bytes is str else str)(length).encode('ascii'), b'\r\n']).
This has negative readability, performance, and convenience implications for
the code running on both 2.x and 3.x and it would be really nice to see fixed.
Honestly, it would still be a porting burden to have to use .format(); if you
were going to do something _specifically_ to help Twisted, the thing to do
would be to make both .format and .__mod__ work; most of our protocol code
currently uses % to do its formatting. However, upgrading to a modern API is
not an insurmountable burden for Twisted, and I can understand the desire to
trade off that work for the simplicity of having less code to maintain in
Python core (and less to write for this feature), as long as the modern API
is actually functional enough to make very common operations close to
equivalently convenient.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3982
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Glyph Lefkowitz added the comment: On Jan 22, 2013, at 1:46 PM, STINNER Victor rep...@bugs.python.org wrote: 2013/1/22 Guido van Rossum rep...@bugs.python.org: Twisted still would like to see this. Sorry, but this argument doesn't convince me. A better argument is that bytes+bytes+...+bytes is inefficient: it creates a lot of temporary objects instead of computing the final size directly, or using realloc. Uh, yes. That's one of the reasons (given above) that Twisted would still like to see this. It seemed to me that Guido was stating a fact there, not making an argument. The Twisted project *would* like to see this, I can assure you, regardless of whether you're convinced or not :). str%args and str.format() uses realloc() and overallocates its internal buffer to avoid too many calls to realloc(). More importantly, it's fairly easy to add many optimizations of this type to an API in the style of .format(), even if it's not present in the first round; optimizing bytes + bytes + bytes requires slightly scary interactions with refcounting and potentially GC, like the += optimization. The API just has more information to go on, and that's a good thing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Glyph Lefkowitz added the comment:
Antoine Pitrou added the comment:
The fact that there are plenty of other Python applications that don't
use Twisted which nevertheless need to emit formatted sequences of
bytes is *precisely* a good reason for this to be discussed more
visibly.
I don't think anyone is opposing discussing it. I don't personally think such
a discussion would be useful, lots of points of view are represented on this
ticket, but please feel free to raise it in whatever forum that you feel would
be helpful. (Even if I did object to that I don't see how I could stop you :)).
I'm not sure what the general case is.
The general case that I'm referring to is the case of an application writing
some protocol logic in terms of constructing some bytes objects and passing
them to Twisted. In other words, Twisted relied upon Python to provide a
convenient way to assemble your bytes into protocol messages, and that was
removed in 3.x. We never provided one ourselves and I don't think it would be
a particularly good idea to build that kind of basic string-manipulation
functionality into Twisted rather than Python.
What I know from Twisted is there are many specific cases where, indeed,
binary protocol strings are formed by string formatting, e.g. in the FTP
implementation (and for good reason since those protocols are either ASCII
or an ASCII superset).
These protocols (SMTP, SIP, HTTP, IMAP, POP, FTP), are not ASCII (nor are they
an ASCII superset); they are ASCII commands interspersed with binary data.
It makes sense to treat them as bytes, not text. In many cases - such as when
expressing a length, or a checksum - you _must_ treat them as bytes, or you
will emit incorrect data on the wire. By the time you're dealing with text -
if you ever are - you're already somewhere in the body of the protocol,
decorated with appropriate metadata.
But my point about the general case is that when implementing a *new*
protocol with ASCII commands, or maintaining an existing one, bytes-object
formatting is a convenient, expressive and performant way to express the
interpolation of values in the protocol stream.
As a workaround, it would probably be reasonable to make
these protocols use str objects at the heart, and only convert to bytes
after the formatting is done.
Protocols like SMTP (c.f. 8-bit MIME) and HTTP put binary data in-line; do
you suggest that gzipped content be encoded as latin1 so it can squeeze into
python 3's str type? I thought the whole point of the porting pain here was to
get a clean separation between bytes and text. This is exactly why I do not
particularly want bytes.format() to allow the presence of strs as formatted
values, although that *would* make porting certain things easier. It makes
sense to do your encoding first, then interpolate.
Code running on both 2.x and 3.x will *by construction* have some
performance pessimizations inside it. It is inherent to that strategy.
Not saying this is necessarily a problem, but you should be aware of it.
This is certainly true *now*, but it doesn't necessarily have to be.
Enhancements like this one could make this performance division go away. In
any case, the reason that ported code suffers from a performance penalty is
because python 3 has no efficient way of doing this type of bytes construction;
even disregarding compatibility with a 2.x codebase, b''.join() and b'' + b''
and (''.format()).encode('charmap') are all slower _and_ more awkward than
simply b''.format() or b''%.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3982
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3982] support .format for bytes
Glyph Lefkowitz added the comment: On Jan 22, 2013, at 3:34 PM, Terry J. Reedy rep...@bugs.python.org wrote: I presume this would mean adding 'if py3: out = out.encode()' after the formatting. As I said before, this works much better in 3.3+ than in 3.2-. Some actual numbers: I'm glad that this operation has been optimized, but treating blocks of protocol data as text is a hackish workaround that still doesn't perform as well (even on 3.3+) as bytes formatting in 2.7. [If speed is really an issue, we could make binary file/socket write methods unicode implementation aware. They could directly access the ascii (or latin-1) bytes in a unicode object, just as they do with a bytes object, and the extra copy could be skipped.] Yes, speed is really an issue - this kind of message construction is on the critical path of many of the more popular protocols implemented with Twisted. But trying to work around the performance issue by pretending that strings are bytes will just give new life to old bugs. We've been loudly rejecting unicode from sockets I think for as long as Python has had unicode, and that's the way it should remain. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3982 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15945] memoryview + bytes fails
Glyph Lefkowitz added the comment: It's worth noting that the buffer() built-in in Python2 had this behavior, and it enabled a copy-reduction optimization within Twisted's outgoing transport buffer. There are of course other ways to do this, but it seems like it would be nice to restore this handy optimization; it seems like a bug, or at least an oversight, that the convenience 'bytes+memoryview' (which cannot provide a useful optimization) works, but 'memoryview+bytes' (which would be equally helpful from a convenience perspective _could_ provide a reduction in copying) doesn't. Despite the bytes.join optimization (which, don't get me wrong, is also very helpful, almost necessary) this remains very useful. -- nosy: +glyph ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15945] memoryview + bytes fails
Glyph Lefkowitz added the comment: Le Oct 11, 2012 à 12:13 PM, Antoine Pitrou rep...@bugs.python.org a écrit : Antoine Pitrou added the comment: I'm not sure what you're talking about since: b = buffer(abc) b + xyz 'abcxyz' (b + xyz) is b False ... doesn't look like it avoid copies to me. The case where copies are avoided is documented here: http://twistedmatrix.com/trac/browser/trunk/twisted/internet/abstract.py?rev=35733#L20 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15945] memoryview + bytes fails
Glyph Lefkowitz added the comment: Yes, it would be *possible* to fix it with that alone, but that still makes it a pointless 'gotcha' in differing behavior between memoryview and buffer, especially given that bytes+memoryview does something semantically different than memoryview+bytes for no reason. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Glyph Lefkowitz gl...@twistedmatrix.com added the comment: Charles-François: Also, I must admit I'm quite skeptical about the real benefit of explicit probes for user-land, especially for CPython which isn't used for performance-critical systems... I beg to differ. CPython is totally used on performance-critical systems, and I know I'm not the only user who thinks that. Performance-critical doesn't necessarily mean goes as fast as it ever possibly can, clearly PyPy is the place to go for that, but can process at least X work in Y time. Meeting performance goals with CPython is already challenging enough, please don't make it artificially hard by refusing to integrate tools which help users understand and improve performance. Benjamin: I'm -1 on this patch for essentially the same reasons as Charles-François. It introduces a lot of code (and hacks!) in critical pathways of the interpreter. Someone would have to be constantly maintaining and testing it. In return, what do we get? You get support for a highly sophisticated and low-impact profiling and tracing technology which provides support for illuminating performance problems *as well as* complicated behavioral problems that only happen under load, without slowing down the interpreter as a whole. Not to mention possible integration with a whole slew of tools that know how to deal with data from that system. I'm not saying that this is necessarily worth the maintenance burden; your analysis of the tradeoff may ultimately be correct. I can't presume to know that because I am not intimately familiar with all the code it touches. But it's definitely not nothing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13405 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12944] setup.py upload to pypi needs to work with specified files
Glyph Lefkowitz gl...@twistedmatrix.com added the comment: This has been a serious annoyance in the Twisted and pyOpenSSL release processes; it effectively prevents us from timely uploads of win32 binaries of any kind. -- nosy: +glyph ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12944 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7175] Define a standard location and API for configuration files
Glyph Lefkowitz gl...@twistedmatrix.com added the comment: I would still prefer ~/.local/something-parallel-to-where-it's-usually-installed for its ease of documentation. But ~/.python/X.Y isn't terribly objectionable. A minor point about Michael Foord's fallback proposal: I don't know why everyone is so keen to stuff things into ~/Library on the mac, but dotfiles don't go in ~/Library/Preferences. While that directory isn't exclusively populated with plist files, it's pretty close. If you want to try for consistency with platform convention, 'org.python.distutils.cfg' would be a better name for it, but I've never hand-edited a text file in that directory either and I get the impression one isn't meant to. But, since framework builds of Python already has ~/Library/Python/X.Y directories that they look in for other things, that location should probably be recycled if one wishes to have a fallback. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7175 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7175] Define a standard location and API for configuration files
Glyph Lefkowitz gl...@twistedmatrix.com added the comment: I agree with Michael Foord; my comment on issue 8404 http://bugs.python.org/issue8084#msg122935 may be of interest to anyone looking at this as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7175 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ANNOUNCE] Twisted 10.2.0 Released
Twisted 10.2.0, the third Twisted release of 2010, has emerged from the mysterious depths of Twisted Matrix Labs, as so many releases before it. Survivors of the release process - what few there were of them - have been heard to claim that this version is awesome, even more robust, fun-sized and oven fresh. Crossing several things that shouldn't ought to be, including the streams and the rubicon, I have assumed the triple responsibilities of feature author, project leader, *and* release manager for 10.2: with this dark and terrible power - a power which no man ought to wield alone - I have wrought a release which contains many exciting new features, including: - A plug-in API for adding new types of endpoint descriptions. http://tm.tl/4695 - A new, simpler, substantially more robust CoreFoundation reactor. http://tm.tl/1833 - Improvements to the implementation of Deferred which should both improve performance and fix certain runtime errors with long callback chains. http://tm.tl/411 - Deferred.setTimeout is (finally) gone. To quote the author of this change: A new era of peace has started. http://tm.tl/1702 - NetstringReceiver is substantially faster. http://tm.tl/4378 And, of course, nearly one hundred smaller bug fixes, documentation updates, and general improvements. See the NEWS file included in the release for more details. Look upon our Twisted, ye mighty, and make your network applications event-driven: get it now, from: http://twistedmatrix.com/ ... or simply install the 'Twisted' package from PyPI. Many thanks to Christopher Armstrong, for his work on release-automation tools that made this possible; to Jonathan Lange, for thoroughly documenting the process and thereby making my ascent to the throne of release manager possible, and to Jean-Paul Calderone for his tireless maintenance of our build and test infrastructure as well as his help with the release. Most of all, thanks to everyone who contributed a patch, reported a bug or reviewed a ticket for 10.2. Not including those already thanked, there are 41 of you, so it would be a bit tedious to go through everyone, but you know who you are and we absolutely couldn't do it without you! Thanks a ton! -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
[issue8084] pep-0370 on osx duplicates existing functionality
Glyph Lefkowitz gl...@twistedmatrix.com added the comment: Would it be possible to have this reverted for 2.7.2 / 3.2.1, and restore ~/.local _and_ ~/Library as equally valid locations for python code? As I tried to explain on the mailing list, this change basically introduces a regression, and nothing else. Sorry I did not comment on the ticket at the time. Previously it was possible to maintain a single ~/.pydistutils.cfg for UNIX-like OSes, which would allow 'python setup.py install', 'pip install' and 'easy_install' to function without adding a 'sudo' in front of them, or any command-line options. This is important since easy_install doesn't expose a '--user'. Now, there needs to be a specific, separate config file for OS X installs. Also, it was previously possible to pass a sane value for '--prefix', but now there is no such value. This makes it much more difficult to, for example: cd my-c-dependency ./configure --prefix ~/.local cd my-python-project python setup.py install --prefix ~/.local since Python code with C dependencies will sometimes attempt to discover the location of include files and the like via the install prefix. 'setup.py install --user' (the only remaining installation mechanism which actually works out of the box on a mac) will now place scripts into ~/Library/Python/x.y/bin, which seems a singularly unhelpful location. Again, if there are C and Python programs which interact, I now need 2 locations on my $PATH instead of one. I don't understand what this change buys anyone. If you're treating the Mac python as a UNIX-like environment, it just spuriously breaks things. But if you're treating it as a Mac-like environment (i.e. not using a terminal), the right place to put your Python code is _inside a (framework or application) bundle_, not lying around your home directory. Also, if there is interest in properly honoring Mac filesystem conventions, there are APIs for doing that, as documented here: http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFileSystem/Articles/Domains.html. Manually enumerating the user domain while ignoring, for example, the network domain, seems half-hearted and arbitrary. -- nosy: +glyph ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8084 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ANNOUNCE] Twisted 10.2.0 Released
Twisted 10.2.0, the third Twisted release of 2010, has emerged from the mysterious depths of Twisted Matrix Labs, as so many releases before it. Survivors of the release process - what few there were of them - have been heard to claim that this version is awesome, even more robust, fun-sized and oven fresh. Crossing several things that shouldn't ought to be, including the streams and the rubicon, I have assumed the triple responsibilities of feature author, project leader, *and* release manager for 10.2: with this dark and terrible power - a power which no man ought to wield alone - I have wrought a release which contains many exciting new features, including: - A plug-in API for adding new types of endpoint descriptions. http://tm.tl/4695 - A new, simpler, substantially more robust CoreFoundation reactor. http://tm.tl/1833 - Improvements to the implementation of Deferred which should both improve performance and fix certain runtime errors with long callback chains. http://tm.tl/411 - Deferred.setTimeout is (finally) gone. To quote the author of this change: A new era of peace has started. http://tm.tl/1702 - NetstringReceiver is substantially faster. http://tm.tl/4378 And, of course, nearly one hundred smaller bug fixes, documentation updates, and general improvements. See the NEWS file included in the release for more details. Look upon our Twisted, ye mighty, and make your network applications event-driven: get it now, from: http://twistedmatrix.com/ ... or simply install the 'Twisted' package from PyPI. Many thanks to Christopher Armstrong, for his work on release-automation tools that made this possible; to Jonathan Lange, for thoroughly documenting the process and thereby making my ascent to the throne of release manager possible, and to Jean-Paul Calderone for his tireless maintenance of our build and test infrastructure as well as his help with the release. Most of all, thanks to everyone who contributed a patch, reported a bug or reviewed a ticket for 10.2. Not including those already thanked, there are 41 of you, so it would be a bit tedious to go through everyone, but you know who you are and we absolutely couldn't do it without you! Thanks a ton! -- http://mail.python.org/mailman/listinfo/python-list
Re: [pyOpenSSL] [ANN] pyOpenSSL 0.11 released
On Nov 1, 2010, at 6:43 PM, exar...@twistedmatrix.com wrote: I'm happy to announce the release of pyOpenSSL 0.11. Congratulations, JP! It's great to see this effort coming together.-- http://mail.python.org/mailman/listinfo/python-list
[issue7175] unify pydistutils.cfg and distutils.cfg and use .local
Glyph Lefkowitz gl...@twistedmatrix.com added the comment: Well, that makes it the user-specific equivalent of /usr or /usr/local. Do you put your configuration files in /usr/local ? Why put them in .local ? Yes, software built for /usr/local will often respect /usr/local/etc in addition to /etc. Also, many desktop Linux applications put state into ~/.local/share/$appname. I am not sure about configuration files, (apps that use ~/.local will typically use ~/.config for configuration, but that is a different thing entirely) but autotools applications built with '--prefix ~/.local' will often respect ~/.local/etc. I agree with Ned that neither ~/.local nor /etc are a good fit for OSX, sadly enough I wasn't paying attention when ~/.local was added as python already had a per-user directory on OSX: ~/Library/Python. I argued loudly for consistency in treatment of UNIX-like OSes when this decision was being made, and I stand by that position. Why would you want to break software that works fine on BSD and Linux by requiring that it specifically test for OS X, and do the exact same thing, but in a different directory? (See http://en.wikipedia.org/wiki/Single_UNIX_Specification#Mac_OS_X_and_Mac_OS_X_Server) The addition of a per-user directory on OS X when there were no similar directories on other platforms was a weird oversight. The user site directory in Python 2.5 and earlier does not use any features of OS X and refers to ~/Library/Python only by convention. Plus, that convention didn't support the distutils properly anyway: if you put your library code into ~/Library/Python, where are you supposed to tell 'setup.py install' to put script files? With ~/.local, it's obvious: ~/.local/bin. The real OS X convention is to put your code _into your application bundle_, after all, not into random directories in ~/Library. If you don't have an application or framework bundle, you have one foot in UNIX-land already. The point of honoring platform conventions is to provide a consistent experience to users; some users on OS X will be expecting UNIX-like behavior, some will be expecting Framework-like behavior, and there is really no reason not to provide both. There is no reason not to consider /etc, for that matter. PHP, for example, still reads /etc/php.ini on OS X. -- nosy: +glyph ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7175 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add Systemtap/DTrace probes
Changes by Glyph Lefkowitz gl...@divmod.com: -- nosy: +glyph ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5753] CVE-2008-5983 python: untrusted python modules search path
Glyph Lefkowitz gl...@divmod.com added the comment: It suggests to me that somewhere there's some documentation, or an example, that says this is the right way to embed python, call this function. If the right thing to do is to just not call the function at all, we need to get that knowledge out there into the embedding community and publicize this issue. Perhaps a doc bug? PySys_SetArgvEx seems like it might be a good idea for applications which do still want to set the argument list without the sys.path implications, but a quick perusal of the sources of plugins for the affected applications suggests that none of them need it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5753] CVE-2008-5983 python: untrusted python modules search path
Glyph Lefkowitz gl...@divmod.com added the comment: IOW, I *really* want to understand what's happening before fixing it. This is a security issue, after all. Agreed. Does anyone currently subscribed to this ticket know the author of such an application? It would be very helpful to have them involved in the discussion. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5753] CVE-2008-5983 python: untrusted python modules search path
Glyph Lefkowitz gl...@divmod.com added the comment: Antoine, The problem is that apparently every program that embeds Python calls PySys_SetArgv and does not understand the consequences of doing so. For example, a user running 'gedit' to edit some files in a potentially insecure directory may not expect that starting the program there will cause it to load python files from that directory. The 'python' executable itself is not really vulnerable in quite the same way, because if you (i.e. a developer) start 'python' in some directory, you *do* typically expect that it will load code from that directory. For applications written *in* python, that have scripts in, let's say, /usr/bin, the directory added to the path is /usr/bin, not the application's working directory. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5753] CVE-2008-5983 python: untrusted python modules search path
Changes by Glyph Lefkowitz gl...@divmod.com: -- nosy: +glyph ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5571] new TestCase.skip method causes all tests to skip under trial (Twisted's test runner)
New submission from Glyph Lefkowitz gl...@divmod.com: c.f. this Twisted ticket: http://twistedmatrix.com/trac/ticket/3703 Twisted's test tool has an extended TestCase which uses the 'skip' attribute, on both tests and methods, to determine whether to skip them. You can see the implementation here: http://twistedmatrix.com/trac/browser/trunk/twisted/trial/unittest.py?rev=26043#L655 The addition of the new 'skip' method in unittest.py therefore causes trial, twisted's test tool, to unconditionally skip all tests. I've set the priority to release blocker because I'd like it to be determined whether this is really python's fault, or twisted's fault for subclassing TestCase. If the new 'skip' method of TestCase is renamed to something else, say skipTest, this won't be a problem. While I understand that this is technically a compatible change (the addition of an attribute) I'd appreciate it if this changed on Python's side of things, because leaving it up to Twisted means we need to go through a deprecation cycle on a long-standing, stable public interface that a lot of test code is using. -- assignee: benjamin.peterson components: Library (Lib) messages: 84198 nosy: benjamin.peterson, glyph priority: release blocker severity: normal status: open title: new TestCase.skip method causes all tests to skip under trial (Twisted's test runner) type: behavior versions: Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5571 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3780] No way to write unit tests for warnings
Glyph Lefkowitz [EMAIL PROTECTED] added the comment: Looks like we just misunderstood the way the warnings filter works, and catch_warnings' interaction with it. Thanks for the priority bump, guido, and sorry for the false alarm! -- nosy: +glyph status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3780 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3780] No way to write unit tests for warnings
Changes by Glyph Lefkowitz [EMAIL PROTECTED]: -- resolution: - invalid ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3780 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3780] No way to write unit tests for warnings
Glyph Lefkowitz [EMAIL PROTECTED] added the comment: The use of the term filter is pretty confusing. I would normally say it was just me, but a bunch of other Twisted hackers seemed to interpret it the same way: a filter is something that has an opportunity to remove something else. For example, the python builtin function filter. Experimentation with the filters list seems to confirm this impression, since later filters do not have an opportunity to access the warnings that earlier filters have removed. The intuitive leap there is to assume that inserting a filter at the head of the list won't do anything different than inserting it at the tail, since a later filter will remove it. I can't think of an obvious recommendation to improve the text for the filter system itself, because upon reading it in more depth, it's fairly clear. Maybe the heading could be changed to something more like intercepting warnings or controlling the way that warnings are emitted? Something attention-grabbing that describes its purpose and doesn't use the word filter. Even a sub-heading which simply described how to use 'always' filter to cause every warning to be emitted would be helpful. The biggest improvement to the documentation for catch_warnings would be to put it in a section of its own, How To Test Your Code Which Uses Warnings, not as a footnote in Available Classes. (Also, as a minor note to be taken at your discretion: should catch_warnings be named PEP 8 style as a class, since it is one? I don't really want to open that can of worms after reading the interminable threading.Event thread, but it seemed worth saying as long as was talking about this...) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3780 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2235] __eq__ / __hash__ check doesn't take inheritance into account
Glyph Lefkowitz [EMAIL PROTECTED] added the comment: As barry said, this should have been a release blocker for the first beta... ;-) -- nosy: +glyph priority: critical - release blocker ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2235 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2705] incompatible change to warnings.showwarning
Glyph Lefkowitz [EMAIL PROTECTED] added the comment: pitrou: You're missing a few steps. If you are maintaining project X, which depends on library Y, that adds a showwarning hook for some reason, you need to: * check out a development version of library Y, which you do not normally maintain * change the hook's signature to the new one * submit a patch to library Y * make a local fork of library Y so that you can verify the rest of your code under 2.6 * send out an email to your mailing list explaining that they cannot run with python 2.6 without this patch (linking to the patch in library Y) * write a FAQ entry because 200 people show up asking why it does not work on python 2.6 * if library Y's development is slow, do a new release of project X which includes monkeypatching to allow running project X on 2.6 These steps may be unavoidable if library Y has been unmaintained for a long enough time, but it would be nice to be able to avoid this with a single new Python release. -- nosy: +glyph __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2705 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments
Glyph Lefkowitz [EMAIL PROTECTED] added the comment: I don't understand your objection. It sounds like you're objecting, but then suggesting an implementation? The line you suggest might just as easily be present in py3k's default site.py and it would work fine. As I understand it, sites don't need this feature, developers do. Let's say I'm working on a typical system with stock python2 and python3 packages installed. Maybe it's a multi-user system, I don't have control over site.py. Normally what I'd do to manipulate sys.path dynamically between different versions would be to install a sitecustomize.py on my one PYTHONPATH entry that detected the version and reacted appropriately. However, writing a program that is both valid python 2 and python 3 is, as I understand it, both tricky and unsupported. Will this specific case be supported so that developers don't need to have root and modify the system python in order to do 2-3 migrations? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2375 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments
Glyph Lefkowitz [EMAIL PROTECTED] added the comment: The idea is that PYTHON3PATH will be honored in preference to PYTHONPATH, but PYTHONPATH will still be honored. It's exposed only to people who specifically need it. However, I think it's misleading to call the Python 3 transition a transient problem. If we're lucky, it's going to be a decade of slow progress. If we're not, it will never end. Try, for example, compiling your system C library without gets, and see what happens. (And that's been an issue for more than 10 years!) The biggest way to shorten this problem is to provide tools and idioms for developers to use when porting. Specifically like this feature. As far as version specific file extensions - I'd be very happy with that but Guido has said several times that he doesn't like it. Feel free to discuss that with him, but this change is far less invasive. Users who don't need it will simply never know about it. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2375 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments
New submission from Glyph Lefkowitz [EMAIL PROTECTED]: Currently if you have both Python 3 and Python 2 installed, there's no way to indicate that .py files in one area are Python 2 syntax and in another area are Python 3 syntax. Being able to distinguish between these would be nice for heterogeneous deployment environments, but is particularly important for developers who are working on Python 3 conversions. It would be good to have a PYTHON3PATH which, if present, would be honored instead of PYTHONPATH. PYTHONPATH could still be honored if PYTHON3PATH was not present, so this is purely a new feature and shouldn't have much impact on compatibility. -- components: Interpreter Core messages: 63820 nosy: glyph severity: normal status: open title: PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2375 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
