[issue1883] Adapt pydoc to new doc system
Humberto Diogenes [EMAIL PROTECTED] added the comment: It looks like there are no automated tests for pydoc; it's even listed in test_sundry.py. There's only one file Lib/test/pydocfodder.py which defines Something just to look at via pydoc, but isn't used anywhere (I grepped and found nothing). I've attached a patch just to document one point where pydoc behavior differs from 2.5 to 3.0: describe() used to return 'instance of ClassX', now it returns only 'ClassX' (which means this test will pass in 2.5 but not in 3.0). Functions main and test_main were copied from test_modulefinder. -- keywords: +patch nosy: +hdiogenes Added file: http://bugs.python.org/file10082/py3k-test_pydoc.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1883 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1883] Adapt pydoc to new doc system
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: It's not a difference between versions, but a difference between old-style and new-style classes (which derive from object). In 3.0, all classes are new-style... -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1883 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2677] Argument rules in callables do not apply when function uses PyArg_ParseTuple
New submission from Ludovico Gardenghi [EMAIL PROTECTED]: (It seems strange to me that this issue hasn't been raised in the past, maybe I just failed to find it in the BTS. In that case please excuse me and please point me to the original discussion.) The Language Reference, section 5.3.4, states that, for every callable object: [...] If keyword arguments are present, they are first converted to positional arguments, as follows. First, a list of unfilled slots is created for the formal parameters. [...] Next, for each keyword argument, the identifier is used to determine the corresponding slot (if the identifier is the same as the first formal parameter name, the first slot is used, and so on). [...] This is not true if the function is defined using the C function PyArg_ParseTuple, and this happens a lot in the standard library. I discovered it trying to call os.open(filename, flag=os.O_RDONLY), just to make an example. In this case it seems useless to specify the keyword, but I have to write a generic wrapping function that takes a function name and its arguments (as keyword arguments) and call the original function after having changed the content of some of the arguments. Apart from the reason, I believe that this behavior is inconsistent with the language definition and should be fixed. I'm very new to Python, but maybe the format string of ParseTuple should be extended in order to accept also the name of the positional arguments? Or something like ParseTupleAndKeywords should be used instead? I tried only on Python 2.4 and 2.5 but I took a look at the source code of 2.6 and 3.0 and I believe the issue is still there. -- components: Library (Lib) messages: 65712 nosy: garden severity: normal status: open title: Argument rules in callables do not apply when function uses PyArg_ParseTuple type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2677 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2677] Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple
Martin v. Löwis [EMAIL PROTECTED] added the comment: I fail to see the problem. The open function really doesn't have a named parameter called flags; the positional parameters are unnamed. So there is no violation of the language reference, AFAICT. Perhaps it would be useful to point out that some parameters are available only for positional passing, as they are unnamed. -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2677 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2677] Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple
Changes by Ludovico Gardenghi [EMAIL PROTECTED]: -- title: Argument rules in callables do not apply when function uses PyArg_ParseTuple - Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2677 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2677] Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple
Ludovico Gardenghi [EMAIL PROTECTED] added the comment: I'd believe you when you say positional parameters are unnamed, but: - the language reference contains terms such as first formal parameter name. This means that positional parameters *may* have a name but may also have no name? - if you define a python function as def f(a, b, c): you can call it using keyword arguments instead of positional (e.g. f(1, c=3, b=2)). Could you please explain me what I'm still missing? (I repeat - I met python for the first time 2 weeks ago, so it may very well be the case that I'm completely wrong) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2677 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2677] Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple
Martin v. Löwis [EMAIL PROTECTED] added the comment: I'd believe you when you say positional parameters are unnamed, but: - the language reference contains terms such as first formal parameter name. This means that positional parameters *may* have a name but may also have no name? Correct (although that is actually my interpretation of the implementation; it's probably not a feature of the language itself). - if you define a python function as def f(a, b, c): you can call it using keyword arguments instead of positional (e.g. f(1, c=3, b=2)). Unnamed positional parameters are only available in C code. You cannot write a function with unnamed parameters in Python. Could you please explain me what I'm still missing? (I repeat - I met python for the first time 2 weeks ago, so it may very well be the case that I'm completely wrong) It's just how PyArg_ParseTuple works: it doesn't receive any parameter names for the positional parameters, so it can't possibly do the matching that the language prescribes for positional parameters. Instead, PyArg_ParseTuple operates *just* by position, hence it effectively implements unnamed positional parameters. You are not completely wrong. It's just that this detail is something most people recognize at some point and accept as a fact, regardless of what the language specification says (and, as I claim, that text isn't incorrect - or the implementation isn't incorrect -- it's just underspecified, failing to mention a detail specific to CPython) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2677 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2677] Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple
Ludovico Gardenghi [EMAIL PROTECTED] added the comment: You are not completely wrong. It's just that this detail is something most people recognize at some point and accept as a fact, regardless of what the language specification says (and, as I claim, that text isn't incorrect - or the implementation isn't incorrect -- it's just underspecified, failing to mention a detail specific to CPython) Ok. I think I'll end up accepting it as a fact, too :) and work around the issue. IMHO it would be perfectly acceptable to say if you use CPython and extend python with some C functions you must expect this behavior, but it's slightly less acceptable that different modules from the standard library have different behaviors (depending on which language has been used to implement them): - open(mode='r', name='filename') works - os.open(flag=os.O_RDONLY, filename='filename') does not work - calendar.weekday(2008, day=24, month=4) works - math.fmod(x=10, y=3) does not work - ... From the point of view of someone who writes python code there should be no difference between the behavior of these calls, as long as they are included in the standard python library. IMHO, again. Maybe yes, the easier but probably harmless solution is to change the documentation and point out that in general, you can't. Maybe this somehow leans towards promoting a bug to the rank of feature? ;-) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2677 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2677] Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple
Martin v. Löwis [EMAIL PROTECTED] added the comment: Maybe yes, the easier but probably harmless solution is to change the documentation and point out that in general, you can't. Maybe this somehow leans towards promoting a bug to the rank of feature? ;-) The language spec is stuck between saying what the abstract Python language is supposed to do, and describing what CPython precisely does. You shouldn't use keyword arguments to pass non-optional positional arguments, IMO, but the text describes precisely what happens if you do - for Python functions. The more vague specification then shouldn't say you can't (because that would indicate that you get an exception when you try), but it's unspecified, then going on to say what CPython happens to do in some release. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2677 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2677] Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple
Ludovico Gardenghi [EMAIL PROTECTED] added the comment: At present, unspecified is surely better than you can't, that's a good point. I understand the difficulties of balancing the reference between the abstract definition and the actual implementation. But I still believe that this should not be an unspecified behavior, either in one direction or another. At least somewhere in the future. Anyway, thanks for the explanation :) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2677 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2677] Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple
Martin v. Löwis [EMAIL PROTECTED] added the comment: Making it a documentation issue; I don't think the implementation should change. Georg, if you don't see the need for action, feel free to close it. -- assignee: - georg.brandl components: +Documentation -Library (Lib) nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2677 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2678] hmac performance optimization
New submission from Nikolay Kim [EMAIL PROTECTED]: i removed lambda in _strxor function -- components: Library (Lib) files: hmac.py.diff keywords: patch messages: 65720 nosy: fafhrd severity: normal status: open title: hmac performance optimization type: performance versions: Python 2.5 Added file: http://bugs.python.org/file10083/hmac.py.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2678 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2650] re.escape should not escape underscore
Russ Cox [EMAIL PROTECTED] added the comment: The loop in escape should really use enumerate instead of for i in range(len(pattern)). It needs i to edit s[i]. Instead of using a loop, can't the test just use self.assertEqual(re.esacpe(same), same)? Done. Also, please add tests for what re.escape should escape. That's handled in the existing test over all bytes 0-255. Added file: http://bugs.python.org/file10084/re.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2650 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2679] email.feedparser regex duplicate
New submission from Jim Jewett [EMAIL PROTECTED]: feedparser defines four regexs for end-of-line, but two are redundant. NLCRE checks for the three common line endings. NLCRE_crack also captures the line ending. NLCRE_eol also adds a $ to ensure it is at the end. NLCRE_bol ... is identical to NLCRE_crack. It should either use a ^ to insist on line-start, or be explicitly the same. (e.g., NLCRE_bol=NLCRE_crack.) (It gets away with not listing the ^ because the current code only uses NLCRE_bol.match. (Actually, if the regexes are considered private, then the current code could just use the bound methods directly ... setting NLCRE_bol to the .match method, NLCRE_eol to the .search method, and NLCRE_crack to the .split method.) -- components: Library (Lib) messages: 65723 nosy: jimjjewett severity: normal status: open title: email.feedparser regex duplicate versions: Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2679 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1496032] test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha
Mark Dickinson [EMAIL PROTECTED] added the comment: There are some current math and cmath test failures on the Debian alpha buildbots (2.6 and 3.0), and I think there's a good possibility that adding -mieee to BASECFLAGS would fix these. I'm struggling to find the right way to do this in configure.in. I've found the GCC specific section for BASECFLAGS (around line 800), but I don't know how to write a test for an alpha CPU (rather than a test for a specific operating system). Any hints or pointers? -- nosy: +marketdickinson _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1496032 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.6 (modifications to current re 2.2.2)
Jim Jewett [EMAIL PROTECTED] added the comment:
These features are to bring the Regexp code closer in line with Perl 5.10
Why 5.1 instead of 5.8 or at least 5.6? Is it just a scope-creep issue?
as well as add a few python-specific
because this also adds to the scope.
2) Make named matches direct attributes
of the match object; i.e. instead of m.group('foo'),
one will be able to write simply m.foo.
3) (maybe) make Match objects subscriptable, such
that m[n] is equivalent to m.group(n) and allow slicing.
(2) and (3) would both be nice, but I'm not sure it makes sense to do
*both* instead of picking one.
5) Add a well-formed, python-specific comment modifier,
e.g. (?P#...);
[handles parens in comments without turning on verbose, but is slower]
Why? It adds another incompatibility, so it has to be very useful or
clear. What exactly is the advantage over just turning on verbose?
9) C-Engine speed-ups. ...
a number of Macros are being eliminated where appropriate.
Be careful on those, particular on str/unicode and different compile options.
--
nosy: +jimjjewett
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2636
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.6 (modifications to current re 2.2.2)
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: These features are to bring the Regexp code closer in line with Perl 5.10 Why 5.1 instead of 5.8 or at least 5.6? Is it just a scope-creep issue? 5.10.0 comes after 5.8 and is the latest version (2007/12/18)! Yes it is confusing. -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2636 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.6 (modifications to current re 2.2.2)
Jeffrey C. Jacobs [EMAIL PROTECTED] added the comment:
Thanks Jim for your thoughts!
Armaury has already explained about Perl 5.10.0. I suppose it's like
Macintosh version numbering, since Mac Tiger went from version 10.4.9 to
10.4.10 and 10.4.11 a few years ago. Maybe we should call Python 2.6
Python 2.06 just in case. But 2.6 is the known last in the 2 series so
it's not a problem for us! :)
as well as add a few python-specific
because this also adds to the scope.
At this point the only python-specific changes I am proposing would be
items 2, 3 (discussed below), 5 (discussed below), 6 and 7. 6 is only a
documentation change, the code is already implemented. 7 is just a
better behavior. I think it is RARE one compiles more than 100 unique
regular expressions, but you never know as projects tend to grow over
time, and in the old code the 101st would be recompiled even if it was
just compiled 2 minutes ago. The patch is available so I leave it to
the community to judge for themselves whether it is worth it, but as you
can see, it's not a very large change.
2) Make named matches direct attributes
of the match object; i.e. instead of m.group('foo'),
one will be able to write simply m.foo.
3) (maybe) make Match objects subscriptable, such
that m[n] is equivalent to m.group(n) and allow slicing.
(2) and (3) would both be nice, but I'm not sure it makes sense to do
*both* instead of picking one.
Well, I think named matches are better than numbered ones, so I'd
definitely go with 2. The problem with 2, though, is that it still
leaves the rather typographically intense m.group(n), since I cannot
write m.3. However, since capture groups are always numbered
sequentially, it models a list very nicely. So I think for indexing by
group number, the subscripting operator makes sense. I was not
originally suggesting m['foo'] be supported, but I can see how that may
come out of 3. But there is a restriction on python named matches that
they have to be valid python and that strikes me as 2 more than 3
because 3 would not require such a restriction but 2 would. So at least
I want 2, but it seems IMHO m[1] is better than m.group(1) and not in
the least hard or a confusing way of retrieving the given group. Mind
you, the Match object is a C-struct with python binding and I'm not
exactly sure how to add either feature to it, but I'm sure the C-API
manual will help with that.
5) Add a well-formed, python-specific comment modifier,
e.g. (?P#...);
[handles parens in comments without turning on verbose, but is slower]
Why? It adds another incompatibility, so it has to be very useful or
clear. What exactly is the advantage over just turning on verbose?
Well, Larry Wall and Guido agreed long ago that we, the python
community, own all expressions of the form (?P...) and although I'd be
my preference to make (?#...) more in conformance with understanding
parenthesis nesting, changing the logic behind THAT would make python
non-standard. So as far as any conflicting design, we needn't worry.
As for speed, the this all occurs in the parser and does not effect the
compiler or engine. It occurs only after a (?P has been read and then
only as the last check before failure, so it should not be much slower
except when the expression is invalid. The actual execution time to
find the closing brace of (?P#...) is a bit slower than that for (?#...)
but not by much.
Verbose is generally a good idea for anything more than a trivial
Regular Expression. However, it can have overhead if not included as
the first flag: an expression is always checked for verbose
post-compilation and if it is encountered, the expression is compiled a
second time, which is somewhat wasteful. But the reason I like the
(?P#...) over (?#...) is because I think people would more tend to assume:
r'He(?# 2 (TWO) ls)llo' should match Hello but it doesn't.
That expression only matches He ls)llo, so I created the (?P#...) to
make the comment match type more intuitive:
r'He(?P# 2 (TWO) ls)llo' matches Hello.
9) C-Engine speed-ups. ...
a number of Macros are being eliminated where appropriate.
Be careful on those, particular on str/unicode and different
compile options.
Will do; thanks for the advice! I have only observed the UNICODE flag
controlling whether certain code is used (besides the ones I've added)
and have tried to stay true to that when I encounter it. Mind you,
unless I can get my extra 10% it's unlikely I'd actually go with item 9
here, even if it is easier to read IMHO. However, I want to run the new
engine proposal through gprof to see if I can track down some bottlenecks.
At some point, I hope to get my current changes on Launchpad if I can
get that working. If I do, I'll give a link to how people can check out
my working code here as well.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2636
__
[issue2680] gotcha: _fields_ is final but accepts lists
New submission from Carlos Scheidegger [EMAIL PROTECTED]:
When creating ctypes.Structure classes dynamically, there's a gotcha.
_fields_ is final, but it takes a list that can be appended to. I'm not
sure this is a bug, but I would argue it is a lot more surprising than
it could be:
Python 2.5.2 (r252:60911, Apr 21 2008, 11:17:30)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type help, copyright, credits or license for more information.
import ctypes
class Foo(ctypes.Structure):
... _fields_ = [('dim', ctypes.c_int)]
...
x = Foo()
x.dim = 1
x.dim = '123' # This is ok, and expected
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: an integer is required
class Bar(ctypes.Structure):
... pass
...
x._fields_ = []
x._fields_.append(('dim', ctypes.c_int))
x = Bar()
x.dim = '123' # This, however, is strange
This was somewhat foreseen, since _fields_ is final:
class Baz(ctypes.Structure):
... pass
...
Baz._fields_ = []
Baz._fields_ = [('dim', ctypes.c_int)]
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: _fields_ is final
Would it not make sense for _fields_ to require a tuple, so that it
cannot be mutated? I realize this is a big change. Currently, ctypes
accepts tuples as the input to _fields_. Maybe a warning should be
issued when a list is assigned to _fields_?
--
assignee: theller
components: ctypes
messages: 65728
nosy: cscheid, theller
severity: normal
status: open
title: gotcha: _fields_ is final but accepts lists
type: behavior
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2680
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2681] octal literals beginning with 8 don't raise a SyntaxError
New submission from Lukas Meuser [EMAIL PROTECTED]: Octal literals containing an 8 or a 9 should raise a SyntaxError, but 8 ist accepted as the first character of such a literal (e.g., 0o8 or 0o876, but not 0o678). Those literals evaluate to 0.0. The fix for this is trivial, a patch against current SVN (r62479) is attached. -- components: Interpreter Core files: octal_literals.diff keywords: patch messages: 65729 nosy: lukas.meuser severity: normal status: open title: octal literals beginning with 8 don't raise a SyntaxError type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file10085/octal_literals.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2681 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2680] gotcha: _fields_ is final but accepts lists
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: The __slots__ member of a class object has the same behavior. You may mutate it (even replace it) but this has no effect: only the value available when the class statement was executed is relevant. -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2680 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2681] octal literals beginning with 8 don't raise a SyntaxError
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Corrected as r62480.
I changed your patch a little bit: it seemed more logical to use
(c '0' || c = '8')
As it is the exact counterpart of
('0' = c c '8')
used a few lines below.
Thanks for the report!
--
nosy: +amaury.forgeotdarc
resolution: - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2681
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2680] gotcha: _fields_ is final but accepts lists
Thomas Heller [EMAIL PROTECTED] added the comment: The __slots__ member of a class object has the same behavior. You may mutate it (even replace it) but this has no effect: only the value available when the class statement was executed is relevant. The rules in ctypes are a little bit more complicated (but thanks for the __slots__ example, Amaury): The _fields_ sequence is used when the class statement is executed (if _fields_ are given), or when _fields_ are assigned to the class. The third case appears when an instance of a structure class without _fields_ is actually *used*: by creating an instance of the class, by using the class in another structure _fields_ definition; in this case the structure class is built with an empty _fields_ list. To answer the OP quetsions: Yes, disallowing lists as _fields_ would break too much code. Also, I think tuples in lists are easier to read than nested tuples. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2680 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2655] Create ctypes instances from buffer interface
Thomas Heller [EMAIL PROTECTED] added the comment: The suggestion by Lenard Lindstrom was an additional method named 'from_buffer_copy'. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2655 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2672] speed of set.update(
John Arbash Meinel [EMAIL PROTECTED] added the comment: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Belopolsky wrote: Alexander Belopolsky [EMAIL PROTECTED] added the comment: This has nothing to do with set.update, the difference is due to the time to setup the generator: $ python -m timeit -s 'x = set(range(1)); y = []' 'x.update(y)' 100 loops, best of 3: 0.38 usec per loop $ python -m timeit -s 'x = set(range(1)); y = (i for i in [])' 'x.update(y)' 100 loops, best of 3: 0.335 usec per loop -- nosy: +belopolsky __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2672 __ That is true, though if I just force a generator overhead: % python -m timeit -s 'x = set(range(1)); y = []' 'x.update(y)' 100 loops, best of 3: 0.204 usec per loop % python -m timeit -s 'x = set(range(1)); y = (i for i in [])' 'x.update(y)' 1000 loops, best of 3: 0.173 usec per loop % python -m timeit -s 'x = set(range(1)); l = []' 'x.update(i for i in l)' 100 loops, best of 3: 0.662 usec per loop python -m timeit -s 'x = set(range(1)); l = []; y = (i for i in l)' '(i for i in l); x.update(y)' 100 loops, best of 3: 1.87 usec per loop So if you compare consuming a generator multiple times to creating it each time, it is 0.662 usec - 0.173 usec = 0.489 usec to create a generator. So why does: (i for i in l); x.update(y) take an additional 1.208 usec. (I'm certainly willing to believe that set.update() is generator/list agnostic, but something weird is still happening.) John =:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIENAoJdeBCYSNAAMRAk2yAJ4okAalR6zWD0/E5XHei/ckce+L7QCgstEQ l+6+bl7oAJMhdJ70viqicnQ= =pLX6 -END PGP SIGNATURE- -- title: speed of set.update([]) - speed of set.update( __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2672 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.6 (modifications to current re 2.2.2)
Jim Jewett [EMAIL PROTECTED] added the comment: Python 2.6 isn't the last, but Guido has said that there won't be a 2.10. Match object is a C-struct with python binding and I'm not exactly sure how to add either feature to it I may be misunderstanding -- isn't this just a matter of writing the function and setting it in the tp_as_sequence and tp_as_mapping slots? Larry Wall and Guido agreed long ago that we, the python community, own all expressions of the form (?P...) Cool -- that reference should probably be added to the docs. For someone trying to learn or translate regular expressions, it helps to know that (?P ...) is explicitly a python extension (even if Perl adopts it later). Definately put the example in the doc. r'He(?# 2 (TWO) ls)llo' should match Hello but it doesn't. Maybe even without the change, as doco on the current situation. Does VERBOSE really have to be the first flag, or does it just have to be on the whole pattern instead of an internal switch? I'm not sure I fully understand what you said about template. Is this a special undocumented switch, or just an internal optimization mode that should be triggered whenever the repeat operators don't happen to occur? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2636 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2682] cyclic reference in ctypes CFunctionType objects
New submission from Thomas Heller [EMAIL PROTECTED]: Zachary Pincus posted a message about this cyclic reference in ctypes CFunctionType objects. The reference has the problem that these objects are cleaned up later than expected. The attached patch fixes this problem by removing the cyclic reference. -- assignee: theller components: ctypes files: cthunk.patch keywords: patch messages: 65733 nosy: theller severity: normal status: open title: cyclic reference in ctypes CFunctionType objects type: resource usage versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10086/cthunk.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2682] cyclic reference in ctypes CFunctionType objects
Martin v. Löwis [EMAIL PROTECTED] added the comment: Can you please elaborate your (apparent) concerns about this patch? IOW, why did you not check it in? -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2680] gotcha: _fields_ is final but accepts lists
Thomas Heller [EMAIL PROTECTED] added the comment: Closing as won't fix. -- resolution: - wont fix status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2680 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2682] cyclic reference in ctypes CFunctionType objects
Thomas Heller [EMAIL PROTECTED] added the comment: Can you please elaborate your (apparent) concerns about this patch? IOW, why did you not check it in? I have no concerns about the patch, and I am currently committing it. I'm uploading so that I can points others to it, and (hopefully) to test it before some alpha release. It is part of my workflow: I develop a patch, test it locally, upload it and eventually commit it sonner or later, sometimes changing things depending on feedback I get. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2682] cyclic reference in ctypes CFunctionType objects
Thomas Heller [EMAIL PROTECTED] added the comment: Fixed in trunk and py3k, committed as rev 62481 (trunk), rev 62484 (py3k). I'll leave this open until the decision about backporting to release25-maint is made. -- resolution: - accepted __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2672] speed of set.update(
Alexander Belopolsky [EMAIL PROTECTED] added the comment: On Thu, Apr 24, 2008 at 2:23 PM, John Arbash Meinel [EMAIL PROTECTED] wrote: .. So if you compare consuming a generator multiple times to creating it each time, it is 0.662 usec - 0.173 usec = 0.489 usec to create a generator. So why does: (i for i in l); x.update(y) take an additional 1.208 usec. (I'm certainly willing to believe that set.update() is generator/list agnostic, but something weird is still happening.) I've seen a similar strangeness in timings: $ python -m timeit '(i for i in [])' 10 loops, best of 3: 4.16 usec per loop but $ python -m timeit -s 'x = set()' 'x.update(i for i in [])' 100 loops, best of 3: 1.31 usec per loop on the other hand, $ python -m timeit -s 'x = []' 'x.extend(i for i in [])' 10 loops, best of 3: 4.54 usec per loop How can x.update(i for i in []) take *less* time than simply creating a genexp? Note that there is no apparent bytecode tricks here: 1 0 LOAD_CONST 0 (code object genexpr at 0xf7e88920, file stdin, line 1) 3 MAKE_FUNCTION0 6 BUILD_LIST 0 9 GET_ITER 10 CALL_FUNCTION1 13 RETURN_VALUE dis(lambda:x.update(i for i in [])) 1 0 LOAD_GLOBAL 0 (x) 3 LOAD_ATTR1 (update) 6 LOAD_CONST 0 (code object genexpr at 0xf7e88920, file stdin, line 1) 9 MAKE_FUNCTION0 12 BUILD_LIST 0 15 GET_ITER 16 CALL_FUNCTION1 19 CALL_FUNCTION1 22 RETURN_VALUE __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2672 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2683] subprocess.Popen.communicate takes bytes, not str
New submission from Lenard Lindstrom [EMAIL PROTECTED]:
subprocess.Popen.communicate is documented as taking a string as the
input argument. Instead is accepts only a binary stream (bytes).
Python 3.0a4 (r30a4:62126, Apr 3 2008, 15:34:18) [MSC v.1500 32 bit
(Intel)] on
win32
Type help, copyright, credits or license for more information.
from subprocess import Popen, PIPE
p = Popen('command.com', stdin=PIPE)
p.communicate(dir\n)
Traceback (most recent call last):
File stdin, line 1, in module
File C:\Python30\lib\subprocess.py, line 588, in communicate
self.stdin.write(input)
File C:\Python30\lib\io.py, line 844, in write
raise TypeError(can't write str to binary stream)
TypeError: can't write str to binary stream
--
components: Extension Modules
messages: 65740
nosy: kermode
severity: normal
status: open
title: subprocess.Popen.communicate takes bytes, not str
versions: Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2683
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2684] Logging Module still failing for %(filename)s, __init__
New submission from Charles Merriam [EMAIL PROTECTED]: About same as problem in 2.4 Issue1470422 closed without a test case on MacOS X/Python 2.4. Also same as http://mail.python.org/pipermail/python-bugs-list/2004-July/024111.html and so on back for years. What happens: [EMAIL PROTECTED]:~/py$ cat x.py import logging logging.basicConfig(level=logging.DEBUG, format=%(levelname)s:%(pathname)s:%(lineno)d:%(message)s) from logging import debug if __name__ == __main__: debug(Hello) [EMAIL PROTECTED]:~/py$ python x.py DEBUG:logging/__init__.py:1327:Hello What should happen: It should print DEBUG: x.py:3:Hello Why it fails: Because logging guesses that the right sys._getframe(level) should be level 3 in __init__.py:71, in currentFrame if hasattr(sys, '_getframe'): currentframe = lambda: sys._getframe(3) What should happen: It shouldn't guess. In Python 2.5, the lambda might count. In any case, the level is off by one (4). I suggest that it get set by walking up the stack from until it exits the stack frame. -- components: Library (Lib) messages: 65743 nosy: CharlesMerriam severity: normal status: open title: Logging Module still failing for %(filename)s, __init__ type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2684 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2684] Logging Module still failing for %(filename)s, __init__
Charles Merriam [EMAIL PROTECTED] added the comment: oops, last line should be exits the stack frames for the logging module. This should be a once-per-program-execution event Hmm.. tracker should have a preview button. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2684 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2471] imp.get_magic() should return bytes, not bytearray
Benjamin Peterson [EMAIL PROTECTED] added the comment: This was fixed as r62484. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2471 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2471] imp.get_magic() should return bytes, not bytearray
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Oops, sorry for missing the tracker item. The change was sleeping in my workspace for some time... Thanks for closing it. -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2471 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue799428] tk_focusNext() fails
Changes by Guilherme Polo [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9938/bugfix_and_revamp_nametowidget.diff Tracker [EMAIL PROTECTED] http://bugs.python.org/issue799428 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue799428] tk_focusNext() fails
Guilherme Polo [EMAIL PROTECTED] added the comment: There was a problem with my previous patch if the widget name was just '.' New patch attached Added file: http://bugs.python.org/file10087/bugfix_and_revamp_nametowidget.diff Tracker [EMAIL PROTECTED] http://bugs.python.org/issue799428 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue799428] tk_focusNext() fails
Changes by Guilherme Polo [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10087/bugfix_and_revamp_nametowidget.diff Tracker [EMAIL PROTECTED] http://bugs.python.org/issue799428 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue799428] tk_focusNext() fails
Guilherme Polo [EMAIL PROTECTED] added the comment: Sorry for the previous patch, correct one attached now Added file: http://bugs.python.org/file10088/bugfix_and_revamp_nametowidget.diff Tracker [EMAIL PROTECTED] http://bugs.python.org/issue799428 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.6 (modifications to current re 2.2.2)
Changes by Russ Cox [EMAIL PROTECTED]: -- nosy: +rsc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2636 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2537] re.compile(r'((x|y+)*)*') should fail
Changes by Russ Cox [EMAIL PROTECTED]: -- nosy: +rsc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2537 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1160] Medium size regexp crashes python
Changes by Russ Cox [EMAIL PROTECTED]: -- nosy: +rsc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1160 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1662581] the re module can perform poorly: O(2**n) versus O(n**2)
Changes by Russ Cox [EMAIL PROTECTED]: -- nosy: +rsc _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1662581 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue433030] SRE: Atomic Grouping (?...) is not supported
Changes by Russ Cox [EMAIL PROTECTED]: -- nosy: +rsc Tracker [EMAIL PROTECTED] http://bugs.python.org/issue433030 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1693050] \w not helpful for non-Roman scripts
Changes by Russ Cox [EMAIL PROTECTED]: -- nosy: +rsc _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1693050 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1883] Adapt pydoc to new doc system
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Humberto, I added your test file in trunk. I added some other tests: now pydocfodder.py is used by a basic smoke test. The tests revealed two bugs in python3.0... Thanks! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1883 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1647489] zero-length match confuses re.finditer()
Changes by Russ Cox [EMAIL PROTECTED]: -- nosy: +rsc _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1647489 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1297193] Search is to long with regex like ^(.+|dontmatch)*$
Changes by Russ Cox [EMAIL PROTECTED]: -- nosy: +rsc _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1297193 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2685] Add -mieee to compile flags, when available
New submission from Mark Dickinson [EMAIL PROTECTED]: test_math and test_cmath currently fail on Debian/alpha, apparently due to mishandling of subnormal numbers. I have high hopes that this can be fixed by compiling with -mieee. The attached patch modifies the configure script to always use the -mieee option on gcc, when available. -- components: Build files: mieee.patch keywords: patch messages: 65750 nosy: marketdickinson severity: normal status: open title: Add -mieee to compile flags, when available type: feature request versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10089/mieee.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2685 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1721518] Small case which hangs
Changes by Russ Cox [EMAIL PROTECTED]: -- nosy: +rsc _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1721518 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue433024] SRE: (?flag) isn't properly scoped
Changes by Russ Cox [EMAIL PROTECTED]: -- nosy: +rsc Tracker [EMAIL PROTECTED] http://bugs.python.org/issue433024 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2672] speed of set.update(
Raymond Hettinger [EMAIL PROTECTED] added the comment: John, when y=[], the update method has to create a new list iterator on each invocation. But when y is a genexp, it is self-iterable (iow, iter (y) will return self, not a new object). Also, when doing timings, it can be helpful to factor-out the attribute lookup: python -m timeit -s 'x=set(range(1)); y=[]; xu=x.update' 'xu(y)' __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2672 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2672] speed of set.update(
John Arbash Meinel [EMAIL PROTECTED] added the comment: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Raymond Hettinger wrote: Raymond Hettinger [EMAIL PROTECTED] added the comment: John, when y=[], the update method has to create a new list iterator on each invocation. But when y is a genexp, it is self-iterable (iow, iter (y) will return self, not a new object). Also, when doing timings, it can be helpful to factor-out the attribute lookup: python -m timeit -s 'x=set(range(1)); y=[]; xu=x.update' 'xu(y)' __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2672 __ Sure, I wasn't surprised at the set.update(y) versus set.update([]) What I was surprised at is the time for: (i for i in []) being about 4x longer than set.update(i for i in []) Anyway, the original issue is probably closed, whether we want to track into the generator stuff or not is probably a different issue. John =:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIEP4EJdeBCYSNAAMRAq+MAKC6tLjEtIBX7YgLNoYEfqjRKB4DzACglXjh cEVLEP5Hu3vpeVgVYdTbAVc= =94ja -END PGP SIGNATURE- __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2672 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2686] Any chance we could double the height of the 'Comment:' text area on tracker?
New submission from Trent Nelson [EMAIL PROTECTED]: I'd give my left arm for the comment box to be at least double its current height. Once you've written more than a paragraph, it becomes a nuisance having to scroll up and down to re-read what you've written before typing more. Quick win? -- assignee: loewis components: None messages: 65754 nosy: Trent.Nelson, loewis severity: normal status: open title: Any chance we could double the height of the 'Comment:' text area on tracker? type: feature request __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2686 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2686] Any chance we could double the height of the 'Comment:' text area on tracker?
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: +1 But you should file this in the Meta-Tracker; click Report Tracker Problem at the bottom of the left bar. -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2686 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] performance problem in socket._fileobject.read
Gregory P. Smith [EMAIL PROTECTED] added the comment: available for an easy side by side review here: http://codereview.appspot.com/212 Also, yes I think you're right Ralf. With these changes I should be able to return that to a max() within the while True: for sized reads and things will work as desired. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of RefGuide
bob gailer [EMAIL PROTECTED] added the comment: I find a Reference Manual and a Library Reference. I presume you are referring to the Reference Manual. True? I might be interested in helping create the shorter friendlier guide. I suggest we create some guidelines or specifications for it. This might be a task for several of us, each taking a section, or some other form of collaboration. -- nosy: +bgailer _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1376292 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer [EMAIL PROTECTED] added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. -- title: Write user's version of RefGuide - Write user's version of Added file: http://bugs.python.org/file10090/unnamed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1376292 _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.BRBRBob Gailer in Chapel Hill NC.BRBRBR___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer [EMAIL PROTECTED] added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10091/unnamed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1376292 _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.BRBRBob Gailer in Chapel Hill NC.BRBRBR___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer [EMAIL PROTECTED] added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10092/unnamed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1376292 _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.BRBRBob Gailer in Chapel Hill NC.BRBRBR___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer [EMAIL PROTECTED] added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10093/unnamed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1376292 _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.BRBRBob Gailer in Chapel Hill NC.BRBRBR___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer [EMAIL PROTECTED] added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10094/unnamed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1376292 _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.BRBRBob Gailer in Chapel Hill NC.BRBRBR___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer [EMAIL PROTECTED] added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10095/unnamed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1376292 _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.BRBRBob Gailer in Chapel Hill NC.BRBRBR___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer [EMAIL PROTECTED] added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10096/unnamed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1376292 _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.BRBRBob Gailer in Chapel Hill NC.BRBRBR___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer [EMAIL PROTECTED] added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10097/unnamed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1376292 _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.BRBRBob Gailer in Chapel Hill NC.BRBRBR___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer [EMAIL PROTECTED] added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10098/unnamed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1376292 _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.BRBRBob Gailer in Chapel Hill NC.BRBRBR___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer [EMAIL PROTECTED] added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10099/unnamed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1376292 _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.BRBRBob Gailer in Chapel Hill NC.BRBRBR___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer [EMAIL PROTECTED] added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10100/unnamed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1376292 _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.BRBRBob Gailer in Chapel Hill NC.BRBRBR___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1376292] Write user's version of
bob gailer [EMAIL PROTECTED] added the comment: My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008. Bob Gailer in Chapel Hill NC. Added file: http://bugs.python.org/file10101/unnamed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1376292 _My new email address is bgailer at gmail dot com (not google dot com). Please update your address book, and change the above into the form [EMAIL PROTECTED] The old address will expire at the end of 2008.BRBRBob Gailer in Chapel Hill NC.BRBRBR___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2687] SSL example script fails mysteriously on MacOS
New submission from A.M. Kuchling [EMAIL PROTECTED]:
On my MacOS 10.4.11 machine, the example SSL server and client in the
documentation don't work, and they fail with a mysterious error 0. The
attached tarball contains my slightly-modified version of the scripts
and the test key/cert I'm using.
When I run the server, and then the client, the output of the server is:
[EMAIL PROTECTED]:~/source/p/python$ ./python.exe server.py
Waiting for connection...
Connection received from ('127.0.0.1', 61915)
Traceback (most recent call last):
File server.py, line 16, in module
certfile='cert.pem')
File /Users/amk/source/p/python/Lib/ssl.py, line 466, in wrap_socket
ssl_version=ssl_version, ca_certs=ca_certs)
File /Users/amk/source/p/python/Lib/ssl.py, line 103, in __init__
cert_reqs, ssl_version, ca_certs)
ssl.SSLError: [Errno 8] _ssl.c:429: EOF occurred in violation of protocol
And the client is:
[EMAIL PROTECTED]:~/source/p/python$ ./python.exe client.py
Traceback (most recent call last):
File client.py, line 10, in module
ssl_sock.connect(('', 9000))
File /Users/amk/source/p/python/Lib/ssl.py, line 204, in connect
self.ca_certs)
ssl.SSLError: [Errno 0] _ssl.c:327: error::lib(0):func(0):reason(0)
[EMAIL PROTECTED]:~/source/p/python$
The error 0 is very puzzling.
Perhaps I generated the key and cert incorrectly, and parsing them is
failing in this strange way?
--
assignee: janssen
components: Extension Modules
files: ssl-example.tgz
messages: 65770
nosy: akuchling, janssen
priority: high
severity: normal
status: open
title: SSL example script fails mysteriously on MacOS
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10102/ssl-example.tgz
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2687
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1496032] test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha
Neal Norwitz [EMAIL PROTECTED] added the comment: I think `uname -m` will be equal to alpha in this case. There are several uses of `uname -m` in configure.in. You might need to add a new section. It might also be possible to clean up various special cases to make a generic `uname -m` section. I didn't look too closely though. -m is the machine type BTW, -m works on Tru64. I also tested on Ubuntu and it reported x86_64, on Debian it reported sparc. On OSX.4, it reported Power Macintosh. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1496032 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
