Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Just to demonstrate there is really a problem with the gcc installation
(gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)), here is the
linker line:
gcc -m64 -shared
build/temp.solaris-2.10-sun4u-2.5/net/tb0/home/loewis/25/M
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> How about PyUnicode_GetUTF8Buffer() or just PyUnicode_UTF8() ?!
-1
> Note that the function *must* check the UTF-8 buffer for embedded
> NUL bytes and then raise an exception if it finds one. Otherwise,
> the API wo
New submission from Martin v. Löwis <[EMAIL PROTECTED]>:
sys.getsizeof doesn't take the actual length of the Unicode string into
account:
py> sys.getsizeof(u"")
32
[31332 refs]
py> sys.getsizeof(u"1"*100)
32
[31332 refs]
--
assignee: sch
New submission from Martin v. Löwis <[EMAIL PROTECTED]>:
When merging the sizeof changes to 3k, I had to disable a few tests,
marked with XXX. Can you please take a look at why precisely they broke,
and change them appropriately?
--
assignee: schuppenies
messages: 67752
nosy:
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> fixed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3049>
___
__
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Can you please provide the documentation change as a patch relative to
the 2.6 Doc/lib/turtle.rst (or as a complete file based on turtle.rst)?
In the current form, I find it hard to accept, since I would have to
redo all the changes
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for the patch. Committed as r64061.
Notice that the turtle module was meanwhile moved into the tkinter
package. If you think it should stay as a toplevel module, you should
discuss that on stdl
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> accepted
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This is not a bug. Please read about references in Python, and what this
means:
py> b=[0]
py> a=[b,b]
py> a[0] is a[1]
True
py> c=[[0],[0]]
py> c[0] is c[1]
False
py> c[0] == c[1]
True
In short, there is only a s
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Alternatively, I think the _multiprocessing module should be rewritten
to use a single C file only, and make all symbols except its init
function static.
I agree with Adam that the current code needs to be fixed, one way or
the
New submission from Martin v. Löwis <[EMAIL PROTECTED]>:
abstract.c defines two functions _add_one_to_C and _add_one_to_F. These
apparently must be global, as memoryobject.c references them. Therefore,
they should get a Py or _Py prefix.
A short comment for what these functions actua
New submission from Martin v. Löwis <[EMAIL PROTECTED]>:
ctypes defines a number of global symbols which aren't
namespace-prefixed, such as AllocFunctionCallback, FreeClosure, GetType,
IsSimpleSubType, MallocClosure, _AddTraceback, _CallProc,
alloc_format_string, conversion_mo
New submission from Martin v. Löwis <[EMAIL PROTECTED]>:
While most global symbols in the _sqlite3 module use a sqlite_ or
_sqlite_ prefix, some don't:
_enable_callback_tracebacks, converters, microprotocols_adapt,
microprotocols_add, psyco_adapters, psyco_microprotocols_adapt.
It wo
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
How do you know that there is a memory leak?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Are you by any chance using gcc 4.3? That compiler is known to
miscompile Python, see issue3019 or issue2626.
Also, I'm puzzled that your prompt says Python-2.5.1 when configuring
with a prefix sugge
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Are you willing to debug this? Otherwise, I'll have to close this as
"works-for-me" (which it does, as it did for many other people).
___
Python tracker <[EMAIL PROTECTED]&
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Run "python Lib/test/test_lists.py" separately, and find out which
specific test fails (to complete). Report that, and also try to separate
that test's code into its own file, and see whether you can reproduce it
there.
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The patch looks fine to me.
Notice that the code you are patching was never released, instead, it's
the result of r63059, which was the resolution of issue1792. So please
leave a message there also that you changed it again (and
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> out of date
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
After reviewing this again, I'm skeptical that this is a good idea. It
doesn't achieve its original purpose (anymore), as it only changes
tp_str for range objects (although it does change tp_repr for dict views
- why th
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I do not understand why you think that having the interpreter display
>
> when x.keys() is called is not an improvement over
>
I didn't say that the change in dict_keys is not an improvement,
but that the pa
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Unfortunately, these changes missed the beta for 2.6, so it must be
delayed until 2.7.
--
versions: +Python 2.7 -Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I agree with Georg and Raymond, closing this as "won't fix".
--
nosy: +loewis
resolution: -> wont fix
status: open -> closed
___
Python tracker <[EMAIL PROTE
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Ok, so it's fixed for the trunk, but not Py3k. The trunk fix doesn't
port to 3k, since the functions are called inside memoryobject.c (so
making them static would break that module).
--
versio
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2683>
___
___
Python-bugs-list mailing list
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Now that Python 2.6 is in beta, new features should be deferred to 2.7.
--
nosy: +loewis
versions: +Python 2.7 -Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> wont fix
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
So how does it work for non-English locales?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I cannot see the difference. The docstring doesn't say "current local
time", it says "current time". What do you mean by "current local unix
seconds" - that phrase makes no sense.
time.time() retu
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I think you are misinterpreting what you are seeing. time.mktime returns
seconds since the Epoch, in UTC, when passed broken-down local time. So
that the result is the same as time.time() doesn't mean that time.time()
returns
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Formally, the beta deadline has passed, so no new features can be
admitted. If pje is now happy with the code as it stands (not clear from
the last message), I can ask for permission to commit it,
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I can't quite follow your layout of a longint; in debug mode, I think it is
- 2P (next/prev)
- ssize_t (refcnt)
- P (type)
- ssize_t (size)
- digits
Notice that a ssize_t is 64 bits on Win64, so there shouldn't be any
longs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
That will break on systems where AF_INET6 doesn't default to
dual-stacked sockets and mapped v4 addresses (e.g. Windows); to make it
work correctly, you'll also have to disable the IPV6_V6ONLY option,
which then breaks on sys
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
priority: -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3215>
___
_
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Sorry, but adding new feature into the 2.5.3 release (or any later 2.5
release) is unacceptable; the feature list of 2.5 was frozen in 2006
(when the first beta release of 2.5 was made). Thus, I'm rejecting the
patch.
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
That's a limitation of the zip file format. It uses DOS time stamps,
which only support 5 bits for representing seconds. As a consequence,
within a minute, ZIP can only store even seconds.
If the number of seconds in the minut
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
1. The documentation never gives a rationale for deprecating things. To
find out why they are deprecated, you'll typically have to research what
checkins to a code base have been made that added the deprecation, and
perhaps
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
For the old int type, implementing this was trivial, as the conversion
converted into a C long, then called PyInt_FromLong.
For long, it's much more tricky, as no C type can be used to store the
intermediate result.
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The first beta release for 2.6 has been made, so no new features can be
accepted here. Deferring this to 2.7.
--
nosy: +loewis
versions: +Python 2.7 -Python 2.6
___
Python tracker &
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> The bug entry is just for pointing out a missed optimization
> opportunity. The first mentioned solution would already be an
> improvement, although of course it would even be better to skip the
> intermediary allocatio
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Why do you think string.letters gets corrupted? AFAICT, it's still correct.
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This is now fixed in r64596.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
priority: normal -> high
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1622>
___
__
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This is now fixed in r64597. I had indeed edited the project file before
the release, but couldn't commit, as that would have modified the tag. I
had rebuilt sqlite3.dll, but probably forgotten to rebuild _sqlite3.pyd.
There are
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
As Georg says: you shouldn't be mixing Unicode objects and string
objects. It's perfectly valid for string.letters to contain non-ASCII
bytes, and it's no surprise that this fails for you. string.letters
indeed *does*
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Why didn't it link with /usr/lib/libcrypt.so? That has always worked on
Solaris, including Solaris 2.6.
In addition, even if it did decide to use libcrypt.a for some strange
reason, it should still link successfully, since libcry
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Can you please report from the mmap man page how anonymous mappings can
be achieved on Solaris 2.6?
--
assignee: -> theller
nosy: +loewis, theller
___
Python tracker <[EMAIL PROTE
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Why do you think there is a typo? O_RDWR is a valid constant that should
be provided on all Unix-like systems.
Can you please find out from the open(2) man page: a) whether Solaris
2.6 supports the O_RDWR constant, b) what header fi
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Something must be broken with your system installation. des_crypt.o
should define the function _des_crypt (ar x /usr/lib/libcrypt.a;nm -g
des_crypt.o). What linker are you using?
It seems that the shared version of libcrypt was only
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I will stop posting URLs. ;-)
Thanks. None of the URLs seem to be helpful, anyway.
Please avoid posting URLs without any indication as to what
specific conclusion you like to see drawn from the page.
It seems that Solaris
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Ok. I have no further ideas on what the problem might be, but I'm
confident that linking with a different library is not the right thing
to do. Linking with -lcrypt did always work on Solaris 2.6, so I'm not
goin
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
No. We are not linking with libcrypto at all, so there can't be clashes.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Ah, ok. I completely missed the point of the error message (i.e.
"relocations remain"), and misinterpreted it as missing symbols.
So I still recommend doing what I recommended back then: Uncomment the
line in Modules/Se
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for the patch. This is now committed as r64688
--
resolution: -> accepted
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The patch for issue1622 was committed as r64688; closing this patch as
outdated.
--
nosy: +loewis
resolution: -> out of date
status: open -> closed
___
Python tracker <[EMAIL PR
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The patch in #1622 was committed as r64688.
--
nosy: +loewis
resolution: duplicate -> fixed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Why do you think this is a bug in Python, and not in FreeBSD?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Georg, what do you think?
--
assignee: -> georg.brandl
nosy: +georg.brandl, loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I believe the 2.6 s# processing works correctly; the error is in the
bytearray object. This either shouldn't support the buffer interface, or
it shouldn't reallocate the buffer after having returned a pointer to it.
For 3
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Fixing this in the methods themselves has the disadvantage that the
error reporting is not that good anymore.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Some flags for the compiler are really needed to compile the Python
headers correctly, e.g. -fno-strict-aliasing in 2.6.
So I think an explicit list of options reported would have to be
maintained, either as a blacklist (e.g. -O, -Wal
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> RFC 3986 states that the percent-encoded byte
> values should be decoded as UTF-8.
Where precisely do you read such a SHOULD requirement?
Section 2.5 elaborates that the local encoding (of the
resource) is typically used, ig
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
priority: -> high
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3302>
___
___
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
priority: -> high
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3303>
___
___
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
priority: -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3139>
___
_
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Can you please check the event log at the point of failure, and report
any events it may have recorded?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Do you have a copy of depends.exe? If so, how does it resolve the DLLs
referenced in apsw.pyd?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> BTW
> did you notice msg69367 and the attached file that shows the problem in
> a trivial test case?
I didn't understand it, so I ignored it. What use of localtime, by whom,
what tools? The mentioning of localtime
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Alan, what do you think?
--
nosy: +alanmcintyre
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> wont fix
status: open -> closed
versions: +3rd party
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
versions: +Python 3.1 -Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Assuming the patch is acceptable in the first place (which I personally
have not made my mind up), then it lacks documentation and test suite
changes.
___
Python tracker <[EMAIL PROTECTE
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Setting Version back to Python 3.0. Is there a reason it was set to
> Python 3.1?
3.0b1 has been released, so no new features can be added to 3.0.
___
Python tracker <[EMAIL PR
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Can you try this for a newer version? For 2.4, such problems will not be
fixed anymore.
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Amaury, as Alan is fine with these changes, feel free to apply them.
--
assignee: loewis -> amaury.forgeotdarc
resolution: -> accepted
___
Python tracker <[EMAIL PR
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Can you please re-report this at the tracker linked in the lower-right
corner of this page, i.e.
http://psf.upfronthosting.co.za/roundup/meta
Closing it here.
--
nosy: +loewis
resolution: -> invalid
status: open
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
lower-right -> lower-left (i.e. labelled "Report Tracker Problem")
___
Python tracker <[EMAIL PROTECTED]>
<http
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> don't u think that possibly merits its mention in the 2to3 category?
Please trust our judgment on how to use the bug tracker. This isn't a
competition for publicity; it's a tool to help organizing work am
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This is a Linux kernel crash, and has nothing to do with Python. No
matter what errors Python or your script may have - the operating system
kernel should not crash.
Please report this in a Linux forum, or try to upgrade to a newer
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
So would anybody like to contribute a patch?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The link on PyPI is correct. It doesn't point to the Python bug tracker,
but the PyPI bug tracker, which is on SF.
I have checked, and did not find any further links to the SF Python bug
tracker.
--
nosy: +loewis
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
It would be good to find out what the code inside
PyLocale_getdefaultlocale precisely is doing. I.e. what is the value of
name at that point, and is that perhaps an illegal parameter for
CFStringGetCStringPtr somehow? If the debugger
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I'd be happy to provide any more information that can help get this
> resolved.
Contribution of a patch would be the best way to resolve this quickly.
___
Python tracker <[EMA
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Reverting r64742 would have had the same effect (IMO, it shouldn't have
been checked in in the first place, as it causes the test suite to fail).
--
nosy: +loewis
___
Python trac
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The Python debugger (pdb) won't help here; you'ld have to use the system
debugger (gdb).
Please add the line
printf("The value of name is %p\n", name);
printf("It points to '%s&#
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> That revision caused the test suite to fail because it caused to be
> actually run. :)
Right - but now you've disabled the test again, when the original
introduction of the resource lib2to3 already had the (desirable)
ef
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I have fixed this in r65017 and am currently merging it into the trunk
> and py3k. Martin, do you still want to keep the lib2to3 resource around?
Last I tried, running test_import still took a very long time
(issue2968). If th
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Terry, would you like to contribute a patch (even if only for the one
you understand)?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I don't understand the second loop (where n is given). If n is given,
there should be only a single read operation, using
max(buffer_size, n-avail)
(i.e. the way it is in patch 2). In particular, if the stream is
unbuffered, i
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
As for the possibility of rejecting the request: Python should
absolutely not do so. If the user/applications wants to compute the
result, and the system has enough virtual memory, then Python should
provide the result.
If you want to
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
As for "how to use the module": what do you want to use the module for,
and what kind of information would you need for that?
___
Python tracker <[EMAIL PROTECTED]>
<http://
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>> max(buffer_size, n-avail)
>
> I mimicked the original logic rather than rethink the algorithm. I'm not
> totally
> sure what motivates the original logic but the purpose seems to be that
> non-blocki
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
We would need the copyright holder of the patch to submit a contributor
form. Would that be possible?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Here is a patch adding the s* format, and changing files, sockets, and
fileio to use it. For bz2, the immediate effect is that you get a type
error (as an object providing bf_releasebuffer cannot be converted
through s#/w# anymore); it
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Would you like to work on a patch?
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
If this is under the Google agreement, then it's fine (I think). It's
just that we can't accept anonymous contributions (even if made through
a known middleman).
___
Python trac
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The usual reasons, probably: nobody had time to work on it, as there are
so many other things to do.
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> (1) are you sure it is safe not to INCREF the obj pointer in the
> Py_buffer?
Yes, that's the semantics of the current buffer interface, and I cannot
see a flaw in it. When you call getbuffer, you certainly hold a
ref
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
A new message for spambayes
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1064>
___
_
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Testing authorage
--
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
1201 - 1300 of 4778 matches
Mail list logo
