Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
"he's giving a string"... the user simply called os.walk, which accepts
strings AFAIK.
We should discover what produced this bytestring. Does listdir() returns
a mixed list of strings and bytes?
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
The original problem seems to come from some Unix platform, but this
patch only handles two cases:
- on win32, when the argument is a bytestring.
- on OS/2.
And in both cases, the default (utf-8) conversion seems wrong. Som
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
repr() is supposed to round-trip with eval() for common types.
str() is the function that round-trips with the original type:
>>> x = 5
>>> x == int(str(x))
True
>>> x = "Test Text"
>
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
This problem may be a duplicate of issue815646 and issue595601, and was
probably corrected with r62195.
Can you please check with the new python version 2.6b1 ?
--
nosy: +amaury.forgeotdarc
resolution: -> out
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Closing as "already resolved in the upcoming release"
--
status: pending -> closed
___
Python tracker <[EMAIL PROTECTED]>
<
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
It seems that each self->nesting++ should be balanced with
self->nesting--. Attached patch enables all tests and corrects the issue
--
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file10
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Another version of the patch, that removes the self->nesting member and
uses the Py_EnterRecursiveCall machinery.
I prefer it because it takes into account the depth of the current
python call stack.
Added file: http://b
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
> long's structure is 'lP PP l H'
No, it's a VAR-sized object, and ob_size is a Py_ssize_t, which is best
represented as a 'P' as you already did for other types. I suggest 'lP
PP P H
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I tried this on windows 2000:
>>> # create a file with some text
>>> open("delete.me","w").write("some text\n")
>>>
>>> fp = open("delete.me", &q
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Yes, the exact behaviour depends on multiple aspects.
You should follow the C library conventions:
http://www.cplusplus.com/reference/clibrary/cstdio/fopen.html
"""
For the modes where both read and writing
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
It seems that python3.0 behaves better in this area, specially on
Windows. See the examples given in issue3207.
And since the 'file' type does not use FILE* anymore, the given
workaround is not necess
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
The escaped regexp is not utf-8 (why should it be?), but it still
matches the same bytes in the searched text, which has to be utf-8
encoded anyway:
>>> text = u"été".encode('utf-8')
>>
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I wondered why getsizeof fails for _sre.SRE_Pattern objects when it
succeeds for _socket.socket or struct.Struct.
It turns out that _sre.SRE_Pattern defines the tp_getattr slot, and this
prevents attribute lookup from se
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Robert,
looking at your patch for the _sre module, I noticed that
MatchObject.__sizeof__ includes the sizeof of one of its member (regs: a
tuple of (begin, end) pairs).
Why this one and not the others? I thought the rule (if
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Jesse: ping?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3125>
___
___
P
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I don't understand the relation between "the member is cached" and "it
counts in the object's sizeof".
What does "cached" mean?
Does 'self.x = 3' create a cached member?
_
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
> Caching itself is no criteria, but allocating memory without giving
> the user a chance to find out should be (in this context).
> ... calling match.regs creates a
> tuple which is not there before, but cannot
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Confirmed here.
As a workaround, you may rename sqlite3.dll to SQLITE3.pyd, with some
uppercase letters: the dll loader won't care, but the python import does
check for case consistency.
There is a problem in PCBuil
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I think I narrowed the problem to a race condition in *subclasses* of
threading.local:
In threadmodule.c::local_getattro, there is a chance that self->dict is
changed before PyObject_GenericGetAttr is called.
-
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
After 4 hours spent with the debugger I think I have an explanation and
a correction of one of the problems.
Note that this only affects the "Manager" tests.
- The threading.local type overrides getattr and setat
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I think the best is to ignore __instancecheck__ when
"cls.__instancecheck__" is returned as an unbound method. In this case,
we try "type(cls).__instancecheck__" instead.
Here is a patch along this idea
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Committed my changes to threading.local as r64601.
I think we could enable the "Manager" tests again.
___
Python tracker <[EMAIL PROTECTED]>
<ht
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I reproduced the problem on windows, and it is indeed a problem with the
"print" statement, when the write() method reassigns sys.stdout: the
code calls PyFile_WriteString(), then PyFile_SoftSpace on the same
o
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
> encoding and decoding is generally accepted terminology
Yes, but I personally always pause a couple of seconds each time I have
to write "encode" or "decode".
Following Mark's idea, I think
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Corrected as r64633 (trunk) and r64639 (release25-maint). version 3.0 is
not affected, and there won't be any more 2.4 release.
Thanks for the report!
--
resolution: -> fixed
sta
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
This block is only to support the older VC6 compiler. Since your
installation was most certainly compiled with VS7, your change is correct.
(or better, something like:
#if !defined(_MSC_VER) || _MSC_VER + 0 >= 130
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I don't like the changes in listobject.c and dictobject.c: they seem to
imply that all unhashable types must be modified when upgrading to 2.6.
___
Python tracker <[EMAI
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Not sure that all problems reported here are resolved.
For example, "test_get (__main__.WithProcessesTestQueue)" does not seem
to use threading.local at all.
___
Python trac
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
The cause is that this object use a custom tp_getattr slot, and use
Py_FindMethod from there. and py3k removed the special "__methods__"
lookup that allowed to lists these items.
Of course, nowadays the way to add
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Isn't that a serious compatibility issue? 2.5 code should work on 2.6
with minimal effort.
For deque objects, I don't get your point:
Python 2.6b1+ (trunk, Jul 1 2008, 22:35:48) [MSC v.1500 32 bit Inte
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
And please add the "-v" option at the end, so we can see which function
fails
___
Python tracker <[EMAIL PROTECTED]>
<ht
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Done in several changes: r64672 r64674 r64681.
Now the dir() is even more complete than before. I get:
['__class__', '__copy__', '__deepcopy__', '__delattr__', '__doc__',
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
This is precisely under discussion in issue2235:
if a base class is hashable, a derived class may set __hash__ to None,
and disallow hashing.
--
nosy: +amaury.forgeotdarc
___
Pyt
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
It now works for SRE objects in the py3k branch since r64672, but my
patch is still needed for types that define tp_getattr.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
The two tracebacks provided by Mark seem to correspond to the following
python stack (innermost last):
Lib/test/test_multiprocessing.py, line 1005, in _test_map_unordered
self.assertEqual(sorted(it), map(sqr, range(
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
To be valid, your analogy between dates and numbers suggests that a date
should be convertible to the datetime with the same date, at midnight.
And both objects compare equal, just like 42==42.0
But today this is not the
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Probably, but this affects all PyArg_ParseTuple("s#") calls that release
the GIL afterwards. How many of them are there?
___
Python tracker <[EMAIL PROTECTED]>
<ht
New submission from Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
Since python3.0, chr(0x2f81a) works even on narrow Unicode builds, but
>>> "%c" % 0x2f81a
OverflowError: %c arg not in range(0x1) (narrow Python build)
Likewise, Py_BuildValue("C&qu
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
This happens if the site-packages directory contains a .pth file.
This was unnoticed because the usual message
'import site' failed; use -v for traceback
is never printed: sys.stderr is empty before
New submission from Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
str.isprintable() returns True for undefined unicode code points:
>>> c = "\ufffe"
>>> unicodedata.category(c)
'Cn' # (Other, Not Assigned)
>>> c.isprintable()
T
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Microsoft compilers implement %a since VS8.0.
VS7.1 does not have it.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Committed as r64717.
--
resolution: -> fixed
status: open -> closed
type: -> behavior
___
Python tracker <[EMAIL PROTECTED]>
<htt
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Committed as r64762.
Maybe a 2.5 backport candidate, but I fear that it may break existing code.
--
nosy: +amaury.forgeotdarc
resolution: -> fixed
status: open -> pending
_
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
It seems that mingw is unable to compile the simplest program containing
a call to localtime():
$ echo "#include
> int main() { localtime(NULL); }" > t.c
$ gcc -mno-cygwin t.c -lmsvcr90
Then starting "
New submission from Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
Since r64688, zipfile.py contains duplicated definitions. The attached
patch removes them.
Also, Twisted uses a zipfile item that have been renamed by this change:
zipfile.stringFileHeader (now magicFileHeader).
This makes
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Sorry, here is the patch
--
keywords: +patch
Added file: http://bugs.python.org/file10852/zipfile-removedups.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Since the use of "from X import *" is discouraged (and serious projects
try to avoid it), the __all__ list is less and less meaningful.
___
Python tracker <[EMAIL PROTECTED]&
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Attached patch releases the _active_limbo_lock after a fork(). It is not
a complete solution, since existing Thread objects don't correspond to
anything, but it corrects a problem in test_multiprocessing.
--
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I found that on my Debian64, running test_multiprocessing under gdb
hangs even before the first test is started - somewhere in the
installation of the Manager.
And it appears that the problem is described in issue874900:
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
A slightly better patch, with tests.
Added file: http://bugs.python.org/file10859/fork-and-thread2.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Here is a third patch with latest trunk.
Did you apply it to a clean checkout?
Added file: http://bugs.python.org/file10869/fork-and-thread3.patch
___
Python tracker <[EMAIL PRO
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
No, PyTuple_SET_ITEM() "steals" a reference to its argument, so that
ownership is transferred to the tuple.
The reference will be released when the tuple is disposed, with
Py_DECREF(arg).
What makes you think that
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Well I was a bit presumptuous that my thread+fork tests would pass on
all platforms out of the box.
We should disable the tests, or have someone with better Unix expertise
examine and correct them.
At least I feel that
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Thanks for the short case. It makes everything simpler.
First, note that you get the same behaviour with python-only code:
import re, sys
class Issue3328:
def f(self):
# unbalanced parenthesis
x = re.co
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
A new patch:
- I replaced "_active_limbo_lock.release()" by
"_active_limbo_lock=_allocate_lock()"
- I replaced the successive deletions in _active by a re-creation with
only the current thread. There is n
New submission from Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
r62555 has the unfortunate effect that source lines are no more indented
in tracebacks, as in:
Traceback (most recent call last):
File "", line 1, in
File "C:\python\trunk\lib\re.py", line 150, in
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I think there is a problem when the source file cannot be opened (a .pyc
without its .py): the four spaces are printed, but not the line, and the
following level is not properly indented.
See issue3342 for a competing
New submission from Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
This new function is not documented at all.
And I find the error handling not consistent: when filename is NULL, -1
is returned, but no exception is set.
IMO the return code should be as follow:
- return 1 if a line
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I agree. My attempt to describe the behaviour of fork+threads in a
platform-independent test is another issue.
Just one more thing: looking at Module/posixmodule.c, os.fork1() calls
PyOS_AfterFork() in both parent and chil
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Two things may prevent the exception from being seen:
- First, the async exception is not immediate; it is checked every 100
bytecodes (=sys.getcheckinterval()). When testing from the interactive
prompt, try something lik
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
This is why I added an explicit "indent" parameter to Py_DisplaySourceLine.
___
Python tracker <[EMAIL PROTECTED]>
<ht
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Committed as 64880.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
r64881: Py_DisplaySourceLine is renamed to _Py_DisplaySourceLine
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http:/
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Corrected as r64881.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http:/
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I committed r64881, which invalidates your patch a bit :-|
BTW, I don't like your comment "Can't be bothered to check all those
PyFile_WriteString() calls".
In general, it is not a good idea to execut
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I am leaving for the whole next week, so anyone, feel free to commit
(part of) my patch if it helps.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
nosy: +amaury.forgeotdarc
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3385>
___
___
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10953/localstofast.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10707/localstofast.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
assignee: -> amaury.forgeotdarc
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
This issue is a duplicate of issue2378; the patch attached there
corrects this problem. I will commit it tonight.
--
nosy: +amaury.forgeotdarc
resolution: -> duplicate
status: open -> closed
superseder: -&g
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
IMO the "struct tok_state" should not be part of the API, it contains
too many implementation details. Or maybe as an opaque structure.
--
nosy: +amaury.forgeotdarc
_
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
PyCFunctionObject has indeed no way to store annotations. This could be
useful for extension module writers.
The PyMethodDef structure could grow a "ml_annotations" member. A patch
is welcome!
--
nosy
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
assignee: -> amaury.forgeotdarc
nosy: +amaury.forgeotdarc
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
nosy: +amaury.forgeotdarc
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3373>
___
___
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
assignee: -> effbot
nosy: +effbot
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Committed as r65174 and r65175.
(for trunk, I had to change PyBytes_AS_STRING into PyString_AS_STRING)
Thanks!
--
resolution: -> fixed
status: open -> closed
___
Pytho
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Committed as r65177.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http:/
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
assignee: -> kbk
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3344>
___
_
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Did you look at the io.open() function?
It's a new module in python2.6, but also the builtin "open" in py3k!
"""
* On input, if newline is None, universal newlines mode is
enabled. Lin
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Well, os.path.supports_unicode_filenames is False on posix platforms.
So os.path.abspath is not supposed to work with unicode values.
I was about to close the issue, but python 3.0 also defines
supports_unicode_filenames t
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
A use case:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/572213
shows how code can use the Pickler.dispatch dict, but also some
Pickler.save_xxx function which should be expo
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
- A immmutable object may contain mutable members. Try with a tuple
containing a list.
Then, I don't think that something says that CFunctionObjects are
immutable. They don't have any modifiable attribute, until
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10963/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Shared libraries share code, not memory.
But were you talking about sub-interpreters?
http://docs.python.org/dev/c-api/init.html#Py_NewInterpreter
mod_python uses them, but see the "Caveats&quo
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
The "First" argument does not apply here, we could just say "annotations
are not a function invariant", but the "Second" argument is valid to me.
A solution would be a global (or interpret
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Your remark is certainly valid, but where does this occur? Some tool
that generate python code on the fly?
Do you have an example, a use case?
--
nosy: +amaury.forgeotdarc
___
Pyt
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
> does it mean that if newline='\r\n' is specified all single '\n'
> characters are returned inline?
Yes.
Let's take a file with mixed newlines:
>>> io.open("c:/temp/t", &quo
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Please read
http://docs.python.org/dev/library/io.html#io.TextIOBase.newlines
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
VS8 and VS9 are immune to the crash, even if the exception message
differ between release and debug builds.
VC6 crashes, and the proposed patch fixes the problem there as well.
--
nosy: +amaury.
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I reproduced the problem on Windows.
The exception shown is the AttributeError('next') raised and caught in
lxml._elementpath.find().
The "args" atribute is cleared in the BaseException_clear, during
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I confirm that r65234 for 2.5 corrects the crash.
(Windows XP, Visual Studio 6)
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10989/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3450>
___
___
Python-bugs-list m
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
resolution: -> invalid
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http:/
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
> So the exception state would only stay available
> within the function itself.
AFAIK That's what python does for caught exceptions.
--
resolution: -> inval
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
With the patch the following script crashes the 2.6 interpreter on Windows:
import sys, io, threading
stdout2 = io.open(sys.stdout.fileno(), mode="w")
def f(i):
for i in range(10):
stdout2.write(unicod
New submission from Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
When executing self[i:j], the __getslice__(self,i,j) method is called
first, if it exists. See
http://docs.python.org/ref/sequence-methods.html
Yes, the __(get|set|del)slice__ methods are deprecated since 2.0, but
for co
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
There seems to be some misunderstanding.
zkfarmer, you said: "it deletes my file that in use without any exception."
Can you explain this sentence? How is your file "in use"?
-
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Are all those re.ASCII flags mandatory, or are they here just for
theoretical correctness?
For example, the output of "gcc -dumpversion" is certainly plain ASCII.
I don't mind that \d also matches some ex
701 - 800 of 2691 matches
Mail list logo
