Jiri Krivanek added the comment:
In the mena time, by intuition, I have resolved my troube exactly the
way you recommend.
Thanks to you, currently I also know what is he core of the problem.
So the issue can be closed...
__
Tracker [EMAIL PROTECTED]
Neal Norwitz added the comment:
Thanks for testing 3.0.
Do you have any idea why they are no longer called? I don't recall any
changes related to this area. Can you try to debug further?
--
nosy: +nnorwitz
__
Tracker [EMAIL PROTECTED]
James G. sack (jim) added the comment:
Feature Request REVISION
Upon reflection and more playing around with some test cases, I wish to
revise my feature request.
I think the utf8 codecs should accept input with or without the sig.
On output, only the utf_8_sig should
James G. sack (jim) added the comment:
Later note: kind of weird!
On my LE machine, utf16 reads my BE-formatted test data (no BOM)
apparently assumng some kind of surrogate format, until it finds
an illegal UTF-16 surrogate.
That I fail to understand, especially since it quits upon seeing
a
Ralf Schmitt added the comment:
PyOS_setsig in pythonrun.c now calls siginterrupt(sig, 1) (in Python
2.4.4/Python 2.5.1, but not in Python 2.3). So you should be able to
timeout the system calls with a signal.alarm call.
However, having siginterrupt available would still be useful.
I have some
Christian Heimes added the comment:
Can you also use a global variable instead of /etc? Something like
ETC_DIR = /etc for example. It would allow you to ship samples from
several distribution and run unit tests against each.
I've attached the two relevant files from Ubuntu 7.10 Gutsy.
Added
Yann Cointepas added the comment:
I am writing a patch but I have a few questions:
1) There are at most three places where the distribution name can be
found. What is the priority order to select only one name ?
The three places are:
a) Inside the /etc/lsb-release file
b) In the name of the
New submission from Christian Heimes:
Here is the long promised bytes iterator view. It was much, *much*
easier to write it than I have thought. In fact I spent more time fixing
the indention than to modify the code from striterator.
I haven't written an unit test for it. The other iterators
New submission from Tal Einat:
This patch fixes the following bugs:
* Configured selection highlighting colors were ignored
* Updating highlighting in the config dialog would cause
non-Python files to be colored as if they were Python source
Additionally, adding and removing of
New submission from Jonathan Amsterdam:
This is under Linux (2.6).
I occasionally see subprocess.Popen() fail to return, and I have
finally figured out roughly what's going on. It involves the GC and
stderr.
1. os.fork()
2. Parent blocks reading from errpipe_read (subprocess.py:982)
3. In
New submission from Kevin Watters:
The msi.py script for creating an Windows MSI installer from a Python
source tree has hardcoded values for PCBuild. The newer MSVC 2005
build directory is PCBuild8 and has a slightly different structure.
msi.py needs to be changed to be able to work with a
Jean Brouwers added the comment:
Here is one thought, maybe 3.0a calls _exit() while 2.x uses exit() to
terminate. With _exit() any functions installed with atexit() or
on_exit() are *not* called.
That would explain the difference but only if destructor functions are
installed with atexit()
Jean Brouwers added the comment:
Sorry, premature submit. I will try using atexit() and report what
happens there.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1329
__
___
Eric Sammons added the comment:
I have tested 2.4.4 and 2.5.1 from python.org and both suffer from the
exact same issue. I have also compared ceval.c from 2.3, the last known
working copy and ceval.c from 2.4+ and found that ceval.c has undergone
some pretty significant changes.
Jean Brouwers added the comment:
Using atexit() to install the destructor function does not help. The
function in not called when 3.0a1 exits, but with 2.5.1 it is. Same
behavior on Linux and MacOS X.
Btw, that would mean that any C extension which uses atexit() directly
may be affected by
Guido van Rossum added the comment:
Committed revision 58673.
I made one change, hopefully I didn't screw it up: skip the positional
restore if the truncation itself failed. Otherwise the positional
restore might overwrite the error from the truncation. After an error
from this function they
Facundo Batista added the comment:
import os.path
os.path.exists(con)
False
os.path.exists(nul)
False
os.path.exists(prn)
False
This is in Windows 2000 (5.00.2195) sp4, using *both* Python 2.3.5 and
2.5.1, no cygwin.
Personally, I'm +1 with Mark Hammond about this:
I agree it is
Guido van Rossum added the comment:
Committed revision 58674.
I added a change to _abcoll.py to remove the registration of bytes as a
subclass of Iterable.
--
resolution: - accepted
status: open - closed
__
Tracker [EMAIL PROTECTED]
Guido van Rossum added the comment:
If you submit a patch that adds docs and a unit test, your wish will be
fulfilled.
--
nosy: +gvanrossum
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1325
__
Guido van Rossum added the comment:
Please submit a patch for docs and a unittest...
--
nosy: +gvanrossum
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1326
__
___
Guido van Rossum added the comment:
Can you provide a very small shared library that demonstrates this
problem? (E.g. you could start by modifying Modules/xxmodule.c, adding a
'destructor' function.)
--
nosy: +gvanrossum
__
Tracker [EMAIL PROTECTED]
Guido van Rossum added the comment:
Can't you force a BOM by simply writing \ufffe at the start of the file?
--
nosy: +gvanrossum
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1328
__
Guido van Rossum added the comment:
Can you step through it with a C/C++ debugger to see where it goes wrong?
--
nosy: +gvanrossum
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1332
__
Guido van Rossum added the comment:
You missed urllib2 I think. :-)
I agree it's a mess. I'm sure it all started out with backwards
compatibility in mind. I find myself often importing cgi only to use
the tiny function escape() that is defined there...
I wonder if web-sig wouldn't be a good
Guido van Rossum added the comment:
I don't think we can prevent GC from occurring between fork and exec --
it's legal to just call os.fork() and execute Python code in the
subprocess forever. I think the right solution might be to ignore
errors in file_close(). Can you try to whip up a patch
New submission from Guido van Rossum:
Alexandre Vassalotti suggested the following:
A simple way to add specific pickling support for bytes/buffer objects
would be to define two new constants:
BYTES = b'\x8c' # push a bytes object
BUFFER = b'\x8d' # push a buffer object
Warren DeLano added the comment:
Hmm. Well, for one thing, we're falling back on Python's
interlocked_cmp_xchg instead of using Windows'
InterlockedCompareExchange (or should it InterlockCompareExchange64?).
Python's implementation is clearly assuming 64 bit counters, but the
other native
Jean Brouwers added the comment:
Yes, I will make a small library. But first, here is another piece of
evidence.
As I mentioned, using std atexit does not work on 3.0a1. But
surprisingly, the destructor function is not called either when
installed with Py_AtExit on 3.0a1. On 2.5.1 it is.
Georg Brandl added the comment:
Having explicit support for sets at least would be consistent with all
other types for which there is a display form.
(Or else, {1,2,3} could be a different thing after unpickling if the set
builtin is overwritten.)
--
nosy: +georg.brandl
Warren DeLano added the comment:
Disabling Python's emulated InterlockedCompareExchange (for Win95
compatibility) cures the problem, so the underlying question is why the
existence of InterlockedCompareExchange is not being autodetected on 64
bit systems -- and that is apparently because
Guido van Rossum added the comment:
Disabling Python's emulated InterlockedCompareExchange (for Win95
compatibility) cures the problem, so the underlying question is why the
existence of InterlockedCompareExchange is not being autodetected on 64
bit systems -- and that is apparently because
Guido van Rossum added the comment:
If you can, please submit a patch that fixes all those issues, with
unit tests and doc changes if at all possible. That will make it much
easier to evaluate the ramifications of your proposal(s).
__
Tracker [EMAIL PROTECTED]
James G. sack (jim) added the comment:
re: msg56782
Yes, of course I can explicitly write the BOM. I did realize that after
my first post ( my-'duh' :-[ ).
But after playing some more, I do think this issue has become a
worthwhile one. My second post msg56780 asks that utf_8 be tolerant
of
James G. sack (jim) added the comment:
OK, I will work on it. I have just downloaded trunk and will see what
I can do. Might be a week or two.
..jim
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1328
__
Warren DeLano added the comment:
Patch attached. Do note that this patch will break threading on Win95
in order to achieve 64-bit compatibility. Win98 and up should be
fine -- however, that assertion has not yet been confirmed.
Added file: http://bugs.python.org/file8621/thread_nt_fix.patch
Jean Brouwers added the comment:
Here is the same file with an #if to use to Py_AtExit or destructor case.
Please us this one instead of the earlier one.
Added file: http://bugs.python.org/file8622/dlibtest.c
__
Tracker [EMAIL PROTECTED]
Jean Brouwers added the comment:
Attached is a simple test case which demonstrates the problem on Linux
and MacOS X. It is not an xxmodule example, though and hope this is OK.
See the comments for build steps and example output with 3 different
Python builds on both platforms.
If you need
Guido van Rossum added the comment:
OK, confirmed. But no insignt in what happened yet... Do you know where
the atexit stuff happens in 2.5?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1329
__
Changes by Guido van Rossum:
Removed file: http://bugs.python.org/file8620/dlibtest.c
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1329
__
___
Python-bugs-list mailing list
Jean Brouwers added the comment:
One more thing. Stepping with the debugger thru Py_Finalize looks exactly
the same for 2.5.1 and 3.0a1 in the last part of that function.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1329
Jean Brouwers added the comment:
The Py_AtExit function is in Python/pythonrun.c. The calls to all
installed C functions are made in call_ll_exitfuncs, also in
pythonrun.c. The call to call_ll_exitfuncs is at the very end of
Py_Finalize also in pythonrun.c.
I am just getting down there
Jean Brouwers added the comment:
I put a bunch of printf's in the Py_Finalize function of 2.5.1 and
3.0a1.
All those show up when 2.5.1 exists including the call to
call_ll_exitfuncs.
But in 3.0a1 only a few show up and the last one is just before the call
to PyImport_Cleanup near line 393.
New submission from Bill Fenner:
smtplib's complex methods, login and sendmail, try to EHLO or HELO if
it hasn't been done yet. login also checks to see if the EHLO response
included the ability to do authorization.
starttls seems to me to be similar in nature: why should it not try to
EHLO
New submission from Amaury Forgeot d'Arc:
This tiny patch correct a failure in test_tempfile on Windows: in
SpooledTemporaryFile, avoid translating the newlines twice.
Otherwise, in universal text mode, \n gets transformed to \r\n, then
to \r\r\n, which is read as \n\n.
Passing the encoding is
Neal Norwitz added the comment:
Maybe that's because site and io get cleaned up and then there is some
fatal error that can't be printed?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1329
__
Bill Fenner added the comment:
Yes, the state that should be reset includes helo_resp, ehlo_resp,
esmtp_features, and does_esmtp.
The workaround commonly proposed is to always call ehlo() after starttls()
. While this works (most of the time?), it seems arbitrary to require an
explicit
Jean Brouwers added the comment:
This is quite bizarre and difficult to reproduce. With gdb, 3.0a1 does
get to the very end of Py_Finalize, but without gdb it doesn't.
Also, the call to static function call_all_exitfuncs is inlined, its
while loop is shown inside Py_Finalize on MacOS X. On
New submission from Amaury Forgeot d'Arc:
This patch corrects test_fileinput on Windows: when redirecting stdout,
os.open should be given O_BINARY, because the file descriptor is then
wrapped in a text-mode file; os.fdopen(fd, w).
--
files: fileinput.diff
messages: 56833
nosy:
Changes by Amaury Forgeot d'Arc:
--
components: +Windows
versions: +Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1341
__
___
Python-bugs-list mailing list
Neal Norwitz added the comment:
I suggest you configure --with-pydebug. That will disable
optimization, enable debugging symbols and will make it easier to
develop. Note that a debug version runs much slower due to asserts()
and other internal changes. Otherwise, it should work the same.
On
Jean Brouwers added the comment:
OK, I try that.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1329
__
___
Python-bugs-list mailing list
Unsubscribe:
Warren DeLano added the comment:
No need -- turns out the problem was fixed on April 21st a mere three
days after Python 2.5.1 was released. Please close this issue -- my
rookie mistake not working with SVN source from the start! (gee, I
should have known better...) Sorry for wasting your
Guido van Rossum added the comment:
However, considering the severity of this problem
(threading.Lock.acquire(0) broken on 64-bit Windows), what do you think
about issuing a 2.5.2 maintenance release?
Neal Norwitz and Anthony Baxter have been planning to release 2.5.2
for a while now;
Jean Brouwers added the comment:
The 3.0a1 build --with-pydebug behaves the same as before (on Linux). The
problem does occur without gdb but not with gdb.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1329
__
Warren DeLano added the comment:
I wouldn't know how take the lead, but with customers breathing down
my neck for x64 support, my own threading.Rlock-dependent software
product cannot support x64 until an official Python release supports
it.
So I guess that automatically puts me in the
Jean Brouwers added the comment:
It looks like the problem may indeed just be that I/O is being shut down
somewhere inside PyImport_Cleanup. I am modifying the test case to
demonstrate that and will submit that version as soon as it runs.
__
Tracker [EMAIL
New submission from Christian Heimes:
Python 3.0 doesn't run from a directory with umlauts and possible other
non ASCII chars.
I renamed my development folder from C:\dev\ to c:\test äöüß name\.
Python crashes after a few moments before it can reach its shell.
Christian Heimes added the comment:
I think the problem is solved now. I haven't seen glob crashing for a while.
--
nosy: +tiran
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1042
__
Christian Heimes added the comment:
Here is the patch that contains only the harmless parts of the previous
patches. It changes a bunch of doc strings, changes the name of the
types and their repr() and str(). It also adds __builtin__.buffer but it
leaves __builtin__.bytes, __builtin__.str8 and
59 matches
Mail list logo
