[ python-Bugs-1262856 ] fcntl.ioctl have a bit problem.
Bugs item #1262856, was opened at 2005-08-18 09:53 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262856&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raise L. Sail (fullsail) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl.ioctl have a bit problem. Initial Comment: First, I write python program on Linux. The function ioctl of fcntl module, take a integer parameter as ioctl command. in python 2.3.x, if this command value is more than 0x8000, interpreter will popup some warnning message. but in python 2.4.x, it raise a exception directly. My solution is writing one cutoms module in C. but this is so ugly. There are some ioctl command value are more than 0x8000, I think we should not reject "negative" ioctl command. enjoy. -- >Comment By: Michael Hudson (mwh) Date: 2005-08-23 13:10 Message: Logged In: YES user_id=6656 I think this is fixed in CVS HEAD. Can you try that? As a workaround, you can probably pass ~int(~v&0x) to ioctl instead of v (which is very ugly, yes, but probably not as ugly as a C extension). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262856&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1263656 ] IDLE on Mac
Bugs item #1263656, was opened at 2005-08-18 22:35 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263656&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE on Mac Initial Comment: Copying code from some browsers into IDLE on the Mac can leave the file with only \r (13) at the ends of lines (Safari doesn't seem to have this problem). Then checksyntax() in ScriptBinding.py fails to convert these into \n (10), and compile() fails. The effect is that a program which Python is willing to run gets a syntax error in IDLE. I think the fix is in checksyntax() to add after source = re.sub(r"\r\n", "\n", source) the following statement, which converts unaccompanied \r's into \n's:: source = re.sub(r"\r", "\n", source) I've tried this and it works, but someone with a better overview of end-of-line issues in Python should think through whether this is the appropriate fix. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-08-23 13:41 Message: Logged In: YES user_id=149084 Backported, ScriptBinding.py 1.28.4.1 -- Comment By: Kurt B. Kaiser (kbk) Date: 2005-08-22 22:48 Message: Logged In: YES user_id=149084 ScriptBinding 1.62. Backport to 2.4.2 Seems harmless. Please check. IDLE retains line endings when loading code from a file. In this case OS X uses \r in the GUI and \r\n in the OS. Heaven knows what happens with fink/X11. IDLE expects \n internally, line endings are converted on I/O. What is your os.linesep under the conditions you mentioned? Regular expression pattern elements like r'\n' match the corresponding special characters; both bytes have to be in the pattern. You can do it by escaping the backslash in a regular string, '\n', which is also two bytes. But it's easier to use raw strings with regular expressions. -- Comment By: Bruce Sherwood (bsherwood) Date: 2005-08-19 12:16 Message: Logged In: YES user_id=34881 I should have said that this is in the environment of running IDLE on Mac OSX 10.4 under X11, using the fink distribution. I should also say that there seem to be issues not only of compiling but also of editing/display. In a browser, click on a .py file, select all the text, copy, paste into IDLE. With Safari, it looks right and it runs. With NetScape, it displays all on one line, and it doesn't run (syntax error). I haven't studied the actual code to see what if anything IDLE does to attempt to detect the nature of text pasted into an edit window, but clearly it's different coming from two popular browsers. -- Comment By: Bruce Sherwood (bsherwood) Date: 2005-08-19 00:23 Message: Logged In: YES user_id=34881 A footnote: Now I don't understand why the substitution searches for r"\r\n", since this would seem to be the raw string which represents slash, r, slash, n, not the two-character string "\r\n"?? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1263656&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1108992 ] IDLE Freezes on Ubuntu Warty
Bugs item #1108992, was opened at 2005-01-25 05:44 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) >Assigned to: Kurt B. Kaiser (kbk) >Summary: IDLE Freezes on Ubuntu Warty Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark -- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-08-23 14:02 Message: Logged In: YES user_id=149084 Closing as unreproducible. Exhibits only on Ubuntu Warty on a specific machine. -- Comment By: Mark Poolman (mgpoolman) Date: 2005-04-19 07:05 Message: Logged In: YES user_id=993923 Haven't been using the machine in question for a while. I can't reproduce the problem on an opteron with equivalent set up. (The machine I reported this on is a celeron). I've atatched a stack trace from gdb, having interrupted with ctrl-C at the gdb prompt when idle froze. -- Comment By: Kurt B. Kaiser (kbk) Date: 2005-04-14 17:01 Message: Logged In: YES user_id=149084 Any update on this? -- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2005-03-18 20:46 Message: Logged In: YES user_id=495142 If 1) your IDLE freezes when you close an editor window 2) which has been editing a file whose path contains a non-ASCII character, and 3) you do not call sys.setdefaultencoding() in your sitecustomize.py (so letting the default encoding to be 'ascii'), then my patch 'idlelib.diff' in Python Patch ID 1162825 "EditorWindow's title with non-ASCII chars." may help you. More precisely, IDLE freezes when updating the "Recent Files" menu if an implicit conversion of unicode to ASCII string occurs. The patch fixes it. Sorry if it is irrelevant. -- Comment By: Kurt B. Kaiser (kbk) Date: 2005-03-03 19:28 Message: Logged In: YES user_id=149084 There have been recent reports on idle-dev regarding IDLE freezing on Debian Sid. Since ubuntu is Debian derived, I assume there may be a relationship. -- Comment By: Mark Poolman (mgpoolman) Date: 2005-02-02 13:50 Message: Logged In: YES user_id=993923 >0.8 doesn't have the problem. Are you sure? Can't be certain as haven't used it for extended periods on that box, but I'll look into it. I've used IDLE daily for about 4 years on various RH and Suse, and never seen a problem until now. > What else is the ubuntu box doing? Is the load heavy? Almost nothing, it's there to evaluate ubuntu as a desktop w/s, and my main activity is getting some in-house python s/w ported to it. gdb results to follow. -- Comment By: Kurt B. Kaiser (kbk) Date: 2005-02-02 12:21 Message: Logged In: YES user_id=149084 To keep things simple, please start IDLE with the -n switch directly on your ubuntu box for the purposes of future investigations on this issue. Can you attach to the frozen IDLE with gdb and then use 'bt' to get a backtrace and find out what was going at at the time of the freeze? If so, is it repeatable? It's occasionally reported that IDLE freezes. I've never seen it myself, running IDLE for many days on OpenBSD, Debian, RH, and Arch Linux, WindowsXP, W2K, and W98, over a period of many years, so it's hard for me to figure out what's going on. But it's peculiar that 0.8 doesn't have the problem. Are you sure? What else is the ubuntu box doing? Is the load heavy? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-02-01 08:35 Message: Logged In: YES user_id=993923 > So if I foll
[ python-Bugs-1168135 ] Python 2.5a0 Tutorial errors and observations
Bugs item #1168135, was opened at 2005-03-22 01:58 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael R Bax (mrbax) Assigned to: Raymond Hettinger (rhettinger) Summary: Python 2.5a0 Tutorial errors and observations Initial Comment: Please find attached my updated list of errors and observations in response to Python 2.5a0. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-23 13:08 Message: Logged In: YES user_id=80475 Applied many of the suggestions. -- Comment By: Michael R Bax (mrbax) Date: 2005-04-06 07:39 Message: Logged In: YES user_id=1055057 Thanks for your comments. A handful of meta-observations: Front Matter > Your first correction is wrong. -ly adverbs are never hyphenated > (Chicago Manual of Style, Table 6.1, for instance). "Wrong" is wrong. In fact, the CMS Q&A explicitly states that "it has long been the practice elsewhere -- among British writers, for example -- to hyphenate ly + participle/adjective compounds. ... So it is a matter not of who is right or wrong but of whose rule you are going to follow." But I'm happy to leave it as is, given that it is a regional preference. 3.1.2 > > >>> word[:1] = 'Splat' > > -- This is trying to assign 5 letters to one? > > Slice assignment is replacement, not overwriting. This is > replacing 1 byte with 5, which *is* valid, and perhaps the point > being made. Perhaps you would recommend another change to > be clearer? I'm not recommending a change per se; I'm showing what a newbie reader thinks! :-) 5.2 > > There is a way to remove an item from a list given its index > > instead of its value: the del statement. > > -- How is this different to pop? > > pop, builtin on top of del, also saves and returns the deleted value > so it can be bound to something, which takes longer. ie > def pop(self, i): > ret = self[i] > del self[i] > return ret Again, this is a question that the newbie reader will pose. I may know the answer, but I am not asking the question for myself. I think the question should be answered pre- emptively in the tutorial! 9.2 > > Otherwise, all variables found outside of the innermost scope > > are read-only. > > -- Explain what happens when you try to assign to a > > read-only variable? > > You create a new local of the same name and will not be able to > read the masked variable. Right -- again, this is for the benefit of the newbie. Let's put that in the tutorial! :-) -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-30 16:01 Message: Logged In: YES user_id=593130 Subject to reading that particular version (.5a0), I generally agree with your suggestions. Here are some specific comments on your comments. Feel free to incorporate them into a revised suggestion list if you wish. --- Your first correction is wrong. -ly adverbs are never hyphenated (Chicago Manual of Style, Table 6.1, for instance). --- 3.1.2 >>> word[:1] = 'Splat' -- This is trying to assign 5 letters to one? Slice assignment is replacement, not overwriting. This is replacing 1 byte with 5, which *is* valid, and perhaps the point being made. Perhaps you would recommend another change to be clearer? --- ##5.1.3 ##Combining these two special cases, we see that "map(None, list1, list2)" is a convenient way of turning a pair of lists into a list of pairs # -- Shouldn't one rather use zip()? I would agree that 'convenient' should be removed and a note added that this has been superceded by zip unless one wants the different behavior of extending shorter sequences. -- 5.1.3 filter(function, sequence)" returns a sequence (of the same type, if possible) -- How could this ever be impossible? I suppose a broken class, but then what would filter do? If filter 'works' for all builtins, I agree that we should just say so. Perhaps 'returns a sequence of the same type (for all builtins and sensible user classes)' -- if that is true 5.2 There is a way to remove an item from a list given its index instead of its value: the del statement. -- How is this different to pop? pop, builtin on top of del, also saves and returns the deleted value so it can be bound to something, which takes longer. ie def pop(self, i): ret = self[i] del self[i] return ret 5.3 Sequence
[ python-Bugs-1267540 ] _register is not safe
Bugs item #1267540, was opened at 2005-08-23 16:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267540&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. Löwis (loewis) Summary: _register is not safe Initial Comment: The _register function is not safe. It uses the following code to generate a unique string to identify a python callable entity: f = CallWrapper(func, subst, self).__call__ name = repr(id(f)) It then adds the function name if func has a __name__ attribute, but bound methods don't have that, and it is bound methods that cause the problem because they don't have a constant id number unless somebody bothers to keep an explicit reference to the bound reference around (keeping a reference to the object itself isn't enough). For example: class foo: def meth1(self): pass def meth2(self): pass f = foo() print id(f) print id(f.meth1) print id(f.meth2) Odds are good that the last two printed numbers will be the same even though they are for two different bound methods. The id of f will persist and remain unique as long as the object exists, but the id of its bound methods will not. Even though one can call the bound methods as long as the object persists. I don't know how to best handle this. Possibilities include: - Use hash(func) instead of id(func). I don't know enough about the built in hash to know if that is safe. Certainly it is the right idea. One wants a function that has the same value if the callable entity is the same and a different value otherwise. - Generate a new hash function that is sure to work. "paolino" suggested the following hash function for bound methods (when I first asked about this problem on comp.lang.python): id(boundMethod.im_self)^id(boundMethod.im_func) this is probably the simplest solution if hash itself isn't safe, but it requires a some fiddling to figure out what kind of callable entity one has, and thus what hash equation is suitable. - Keep a reference to the callable entity, so its id number cannot be reused. That sounds hard to do safely; it would be all too easy to introduce a memory leak. It can probably be done fairly easily for the case cleanup=1, but there is code that uses cleanup=0 (including bind_all and bind_class). -- Russell -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267540&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1267547 ] bdist_rpm hardcodes setup.py as the script name
Bugs item #1267547, was opened at 2005-08-23 23:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267547&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fernando Pérez (fer_perez)
Assigned to: Nobody/Anonymous (nobody)
Summary: bdist_rpm hardcodes setup.py as the script name
Initial Comment:
The bdist_rpm command hardcodes 'setup.py' as the name of the setup script in
the .spec file it generates. A grep of the bdist_rpm file shows this:
planck[command]> grep -n -C 3 setup.py bdist_rpm.py
454-
455-# rpm scripts
456-# figure out default build script
457:def_build = "%s setup.py build" % self.python
458-if self.use_rpm_opt_flags:
459-def_build = 'env CFLAGS="$RPM_OPT_FLAGS" ' + def_build
460-
--
468-('prep', 'prep_script', "%setup"),
469-('build', 'build_script', def_build),
470-('install', 'install_script',
471: ("%s setup.py install "
472- "--root=$RPM_BUILD_ROOT "
473- "--record=INSTALLED_FILES") % self.python),
474-('clean', 'clean_script', "rm -rf $RPM_BUILD_ROOT"),
But there are packages out there which ship with multiple setup files, named
setup-foo.py, setup-bar.py, etc. While distutils correctly copies over the
proper setup-X.py file to the build/ directory, the bdist_rpm command fails
because rpm then tries to issue a build command against 'setup.py', which
doesn't exist. An example can be seen by downloading the clnum library from
http://calcrpnpy.sourceforge.net/clnum.html, and trying:
lanck[rpncalc-2.0]> python clnum_setup.py bdist_rpm
running bdist_rpm
creating build
creating build/bdist.linux-i686
creating build/bdist.linux-i686/rpm
creating build/bdist.linux-i686/rpm/SOURCES
creating build/bdist.linux-i686/rpm/SPECS
creating build/bdist.linux-i686/rpm/BUILD
creating build/bdist.linux-i686/rpm/RPMS
creating build/bdist.linux-i686/rpm/SRPMS
writing 'build/bdist.linux-i686/rpm/SPECS/clnum.spec'
running sdist
warning: sdist: manifest template 'MANIFEST.in' does not exist (using default
file list)
warning: sdist: standard file not found: should have one of README, README.txt
writing manifest file 'MANIFEST'
creating clnum-1.0
creating clnum-1.0/clnum
creating clnum-1.0/clnum/src
creating clnum-1.0/test
making hard links in clnum-1.0...
hard linking clnum_setup.py -> clnum-1.0
hard linking clnum/__init__.py -> clnum-1.0/clnum
hard linking clnum/_clnum_str.py -> clnum-1.0/clnum
hard linking clnum/src/clnum.cpp -> clnum-1.0/clnum/src
hard linking test/test_clnum.py -> clnum-1.0/test
[... snip]
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.8191
+ umask 022
+ cd /usr/local/installers/src/rpncalc-2.0/build/bdist.linux-i686/rpm/BUILD
+ cd clnum-1.0
+ LANG=C
+ export LANG
+ unset DISPLAY
+ env 'CFLAGS=-O2 -g -pipe -m32 -march=i386 -mtune=pentium4' python setup.py
build
python: can't open file 'setup.py'
error: Bad exit status from /var/tmp/rpm-tmp.8191 (%build)
I think that the fix is as simple as replacing the hardcoded 'setup.py' name by
os.path.basename(sys.argv[0]), but I'm not 100% sure.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267547&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1248119 ] pdb 'next' does not skip list comprehension
Bugs item #1248119, was opened at 2005-07-30 14:12 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Joseph Heled (pepster) Assigned to: Nobody/Anonymous (nobody) Summary: pdb 'next' does not skip list comprehension Initial Comment: pdb next command forces you to step over each list element. This seem to be a reincarnation of this old bug. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=523995&group_id=5470 Version: Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 -- Comment By: Ilya Sandler (isandler) Date: 2005-08-23 20:42 Message: Logged In: YES user_id=971153 I raised this question on python-dev. There was only a couple of replies. To summarize: the original "next N" suggestion got -1 (b/c in gdb "next N" means repeat "next" N times and it is desirable to keep pdb's and gdb's command sets as close as possible), however the alternative suggestion to implement "until" (which is also supported by gdb) got +1. Python-dev reference: http://mail.python.org/pipermail/python-dev/2005-August/055298.html Patch #1267629 implements 'until' and should address the original problem. -- Comment By: Ilya Sandler (isandler) Date: 2005-08-07 13:36 Message: Logged In: YES user_id=971153 > The only viable workaround now is to wrap the code in a > temporary function (i.e. lambda : ...). ugly. Would setting a temporary breakpoint (tbreak) on the line after list comprehension be a much simpler workaround? -- Comment By: Joseph Heled (pepster) Date: 2005-07-31 19:25 Message: Logged In: YES user_id=86677 I think this will be wonderfull The only viable workaround now is to wrap the code in a temporary function (i.e. lambda : ...). ugly. -Thanks, JOseph -- Comment By: Ilya Sandler (isandler) Date: 2005-07-31 13:48 Message: Logged In: YES user_id=971153 > you would realize what a serious bummer this is. I agree: this is a definite inconvenience. But I don't see how it is different from having to step through any other loop. However, I think there is a way to solve both problems at once..See below > Giving a 'next N' is nice, but will not be a real solution. > Somethims it is not easy to know how many iterations there > are. And when they are nested etc. Actually, I did not mean "next N" to skip N iterations, what I meant to have 'next N' (or at least next 1) to skip next N lines of code. I.e stop only when line>=line_where_next_N_happened+N is reached... So it seems like we are talking about the same thing...Right? There are a couple of corner cases which would have to be handled, (e.g keeping track of the current frame, etc) Also "next N" would allow to easily skip over any loops (not just list comprehensions), which I think would be a useful feature... What do you think? -- Comment By: Joseph Heled (pepster) Date: 2005-07-30 23:02 Message: Logged In: YES user_id=86677 You probably never use pdb in a real program, otherwise you would realize what a serious bummer this is. Giving a 'next N' is nice, but will not be a real solution. Somethims it is not easy to know how many iterations there are. And when they are nested etc. If you are convinced this is the desired and reasonable behaviour for next (a point of view I don't share), at least have a different command to skip to the next line. I am sorry but I have no idea if this is easy or hard. Thanks, Joseph -- Comment By: Ilya Sandler (isandler) Date: 2005-07-30 20:20 Message: Logged In: YES user_id=971153 While this behaviour indeed feels like a bug I'm starting to think that it is not.. Observation1: 'step' should stop at every iteration of a list comprehension Observation2: the only difference between 'step' and 'next' is that 'step' steps into function calls (which is not the case here) So, it seems like 'next' should also stop at every iteration of a list comprehenstion. Ie current behaviour is not a bug... Would supporting a numeric argument for the 'next' command make sense? So that 'next 1' would mean "stop when actual line number increases by at least 1"... -- Comment By: Ilya Sandl
[ python-Bugs-1168983 ] ftplib.py string index out of range
Bugs item #1168983, was opened at 2005-03-23 05:05
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168983&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: David Carroll (vmlinuxz)
Assigned to: Raymond Hettinger (rhettinger)
Summary: ftplib.py string index out of range
Initial Comment:
The following code works great on all of the 2.3.x
releases I have used.
def
ftpFetch(localPath,remoteFileDate,ftpSite,ftpPass,ftpDir,ftpUser):
print "Fetching split_mgr report"
fileList=[]
processList=[]
ftp = FTP(ftpSite)
ftp.login(ftpUser,ftpPass)
ftp.dir('LIST '+ftpDir,fileList.append)
for x in range(len(fileList)):
if (string.find(fileList[x],remoteFileDate) != -1):
print fileList[x]
TMP=fileList[x]
output=localPath+str(TMP[45:])
print output
processList.append(output)
print processList
outfile = open(output,'w')
ftp.retrbinary('RETR '+ftpDir+TMP[45:],
open(output, 'wb').write)
ftp.quit()
print processList
return processList
However I get the following error under 2.4
Traceback (most recent call last):
File
"C:\Python24\lib\site-packages\PythonCard\widget.py",
line 417, in _dispatch
handler(background, aWxEvent)
File "C:\Documents and
Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\readwaitreport.py",
line 61, in on_btnRun_command
mainRwclassLoop(self, mm+dd+yy, yesterday)
File "C:\Documents and
Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\rwclass.py",
line 39, in mainRwclassLoop
processList =
ftpFetch(localPath,"split_mgr."+date[0:4],ftpSite,ftpPass,ftpDir,ftpUser)
File "C:\Documents and
Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\rwclass.py",
line 173, in ftpFetch
ftp.dir('LIST '+ftpDir,fileList.append)
File "C:\Python24\lib\ftplib.py", line 464, in dir
self.retrlines(cmd, func)
File "C:\Python24\lib\ftplib.py", line 396, in retrlines
conn = self.transfercmd(cmd)
File "C:\Python24\lib\ftplib.py", line 345, in
transfercmd
return self.ntransfercmd(cmd, rest)[0]
File "C:\Python24\lib\ftplib.py", line 328, in
ntransfercmd
if resp[0] != '1':
IndexError: string index out of range
https://lists.dulug.duke.edu/pipermail/yum/2004-August/005067.html
discusses a similar problem under Linux in the YUM
script, I have reproduced this error under 2000, and XP.
I'm a fairly new programmer, and thus very new to
python so I hope this is enough information. I will
try and keep track of this and help out with more
information in any capacity I can.
Thank you for all your hard work and dedication.
David Carroll
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-24 00:00
Message:
Logged In: YES
user_id=80475
If you're issue has been addressed, go ahead and close it.
--
Comment By: David Carroll (vmlinuxz)
Date: 2005-04-11 04:13
Message:
Logged In: YES
user_id=684143
I'm not sure if this needs any more clarification, but for
accuracy I'm attaching a file with the working and non
working code segments, and the level 2 debug. This code was
run on 2.3, using your new ftplib modifications, and the
distributed ftplib. The FTP server is wu-2.6.2(1) running
on a SCO system (bleh). The code was tested in PASV and
PORT mode. I'm new to this so I don't know if I should
close this or the patch submitter. If you need anything
else from me let me know.
David
--
Comment By: David Carroll (vmlinuxz)
Date: 2005-04-08 05:13
Message:
Logged In: YES
user_id=684143
I achieve the same results with the following code.
ftp = FTP('ftp.cdrom.com')
ftp.login('anonymous', 'anonymous@')
ftp.retrlines('LIST')
This code works just fine with your patched ftplib.py, or
the old ftplib.py against all public internet ftp servers I
have tried it on. It works on the server at work only
sporadically,, and raising the protocol exception the rest
of the time. I'm inclined to think that there may be a
problem with the protocol implementation on the server side.
The server software version is wu-2.6.2(1), and the only
oddity I see with it is a pretty sizeable delay before
giving the login. Up to 10 seconds.
I'd love to get a pointer of where to take this debugging
process next. Perhaps I need to use a sniffer on the
connection or something. I would love to see what ftplib.py
is getting back that is breaking it.
---
[ python-Bugs-1192315 ] 'clear -1' in pdb
Bugs item #1192315, was opened at 2005-04-29 05:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192315&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Pechkin (mpech) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: 'clear -1' in pdb Initial Comment: Delete breakpoints like in %subj% is great feature, but wrong. Add additional check like in do_enable() if not (0 <= i < len(bdb.Breakpoint.bpbynumber)): -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 00:04 Message: Logged In: YES user_id=80475 For the print statement, I would have used something simpler: print 'No breakpoint numbered', i -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 05:11 Message: Logged In: YES user_id=1188172 Attached patch which implements the check. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1192315&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1190204 ] 3.29 site is confusing re site-packages on Windows
Bugs item #1190204, was opened at 2005-04-26 07:26 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190204&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Kent Johnson (kjohnson) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: 3.29 site is confusing re site-packages on Windows Initial Comment: Library Reference 3.29 site seems to say that site-packages is only searched on Unix and Mac. The relevant sentence is in the third paragraph: "For the tail part, it uses the empty string (on Windows) or it uses first lib/python2.4/site-packages and then lib/site-python (on Unixand Macintosh)." A clearer and more accurate wording would be "For the tail part, it uses the empty string and lib/site-python (on Windows) or it uses first lib/python2.4/site-packages and then lib/site-python (on Unixand Macintosh)." The relevant code is line 187 in site.py. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 00:10 Message: Logged In: YES user_id=80475 Before you check in doc changes, be sure to spellcheck and use: python -m texcheck libsite.tex -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 13:24 Message: Logged In: YES user_id=1188172 Fix attached; okay to checkin? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1190204&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1168983 ] ftplib.py string index out of range
Bugs item #1168983, was opened at 2005-03-23 05:05
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168983&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: David Carroll (vmlinuxz)
>Assigned to: Nobody/Anonymous (nobody)
Summary: ftplib.py string index out of range
Initial Comment:
The following code works great on all of the 2.3.x
releases I have used.
def
ftpFetch(localPath,remoteFileDate,ftpSite,ftpPass,ftpDir,ftpUser):
print "Fetching split_mgr report"
fileList=[]
processList=[]
ftp = FTP(ftpSite)
ftp.login(ftpUser,ftpPass)
ftp.dir('LIST '+ftpDir,fileList.append)
for x in range(len(fileList)):
if (string.find(fileList[x],remoteFileDate) != -1):
print fileList[x]
TMP=fileList[x]
output=localPath+str(TMP[45:])
print output
processList.append(output)
print processList
outfile = open(output,'w')
ftp.retrbinary('RETR '+ftpDir+TMP[45:],
open(output, 'wb').write)
ftp.quit()
print processList
return processList
However I get the following error under 2.4
Traceback (most recent call last):
File
"C:\Python24\lib\site-packages\PythonCard\widget.py",
line 417, in _dispatch
handler(background, aWxEvent)
File "C:\Documents and
Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\readwaitreport.py",
line 61, in on_btnRun_command
mainRwclassLoop(self, mm+dd+yy, yesterday)
File "C:\Documents and
Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\rwclass.py",
line 39, in mainRwclassLoop
processList =
ftpFetch(localPath,"split_mgr."+date[0:4],ftpSite,ftpPass,ftpDir,ftpUser)
File "C:\Documents and
Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\rwclass.py",
line 173, in ftpFetch
ftp.dir('LIST '+ftpDir,fileList.append)
File "C:\Python24\lib\ftplib.py", line 464, in dir
self.retrlines(cmd, func)
File "C:\Python24\lib\ftplib.py", line 396, in retrlines
conn = self.transfercmd(cmd)
File "C:\Python24\lib\ftplib.py", line 345, in
transfercmd
return self.ntransfercmd(cmd, rest)[0]
File "C:\Python24\lib\ftplib.py", line 328, in
ntransfercmd
if resp[0] != '1':
IndexError: string index out of range
https://lists.dulug.duke.edu/pipermail/yum/2004-August/005067.html
discusses a similar problem under Linux in the YUM
script, I have reproduced this error under 2000, and XP.
I'm a fairly new programmer, and thus very new to
python so I hope this is enough information. I will
try and keep track of this and help out with more
information in any capacity I can.
Thank you for all your hard work and dedication.
David Carroll
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-24 00:00
Message:
Logged In: YES
user_id=80475
If you're issue has been addressed, go ahead and close it.
--
Comment By: David Carroll (vmlinuxz)
Date: 2005-04-11 04:13
Message:
Logged In: YES
user_id=684143
I'm not sure if this needs any more clarification, but for
accuracy I'm attaching a file with the working and non
working code segments, and the level 2 debug. This code was
run on 2.3, using your new ftplib modifications, and the
distributed ftplib. The FTP server is wu-2.6.2(1) running
on a SCO system (bleh). The code was tested in PASV and
PORT mode. I'm new to this so I don't know if I should
close this or the patch submitter. If you need anything
else from me let me know.
David
--
Comment By: David Carroll (vmlinuxz)
Date: 2005-04-08 05:13
Message:
Logged In: YES
user_id=684143
I achieve the same results with the following code.
ftp = FTP('ftp.cdrom.com')
ftp.login('anonymous', 'anonymous@')
ftp.retrlines('LIST')
This code works just fine with your patched ftplib.py, or
the old ftplib.py against all public internet ftp servers I
have tried it on. It works on the server at work only
sporadically,, and raising the protocol exception the rest
of the time. I'm inclined to think that there may be a
problem with the protocol implementation on the server side.
The server software version is wu-2.6.2(1), and the only
oddity I see with it is a pretty sizeable delay before
giving the login. Up to 10 seconds.
I'd love to get a pointer of where to take this debugging
process next. Perhaps I need to use a sniffer on the
connection or something. I would love to see what ftplib.py
is getting back that is breaking it.
-
[ python-Bugs-1082487 ] font lock keyword regular expressions
Bugs item #1082487, was opened at 2004-12-09 16:43 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Robert Brown (robert-brown) Assigned to: Raymond Hettinger (rhettinger) Summary: font lock keyword regular expressions Initial Comment: I've noticed that when I use Python mode (alpha 1) with font lock mode, "self" is highlighted in the following line: his_self() The problem appears to be a combination of using "\b" in the Python font lock regular expressions and my .emacs file, which does: (modify-syntax-entry ?\_ "_" py-mode-syntax-table) I do not experience similar problems with highlighting in C mode, but there "\<" and "\>" are used in the font lock regular expressions. Using these word delimiters instead of "\b" appears to fix the problem for me in Python mode. Please wrap keywords with "\<" and "\>" instead of with "\b" in the font lock regular expression. Thanks very much. Bob -- Comment By: Skip Montanaro (montanaro) Date: 2005-05-22 20:41 Message: Logged In: YES user_id=44345 Passing along to Raymond. If it works for you, please close. If not, pass it back to me. -- Comment By: Skip Montanaro (montanaro) Date: 2005-05-19 21:45 Message: Logged In: YES user_id=44345 python-mode.el 4.71. Raymond, sorry for taking so long with this. Please give it a try and let me know how it works. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 22:36 Message: Logged In: YES user_id=80475 Skip, can you field this one? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193849 ] os.path.expanduser documentation wrt. empty $HOME
Bugs item #1193849, was opened at 2005-05-02 10:02
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Wummel (calvin)
>Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: os.path.expanduser documentation wrt. empty $HOME
Initial Comment:
If $HOME is unset, an initial "~" should not be
expanded according to the documentation. But instead it
somehow is expanded, perhaps through the pwd module:
$ env -u HOME python -c "import os.path; print
os.path.expanduser('~/foo')"
/home/calvin/foo
The result should be "~/foo" instead of "/home/calvin/foo".
I suggest adjusting the documentation to state the also
a single "~" is looked up in the pwd module, not only
"~user".
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-24 00:16
Message:
Logged In: YES
user_id=80475
Strike the comma before the final "or".
After you post this, put a note on your todo list to check
its appearance in the HTML docs whenever Fred runs an update:
http://www.python.org/dev/doc/devel/
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 07:29
Message:
Logged In: YES
user_id=1188172
Attached a patch which fixes the docs. Okay to checkin?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193849&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1007046 ] os.startfile() doesn't accept Unicode filenames
Bugs item #1007046, was opened at 2004-08-11 01:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Huening (huening) >Assigned to: M.-A. Lemburg (lemburg) Summary: os.startfile() doesn't accept Unicode filenames Initial Comment: WinXP, Python 2.3.4 os.startfile() seems to have problems with Unicode filenames. Example: >>> import tkFileDialog >>> import os >>> f = tkFileDialog.askopenfilename() >>> type(f) >>> os.startfile(f) Traceback (most recent call last): File "", line 1, in -toplevel- os.startfile(f) UnicodeEncodeError: 'ascii' codec can't encode characters in position 14-16: ordinal not in range(128) >>> -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 00:18 Message: Logged In: YES user_id=80475 I'm unicode illiterate. Passing to MAL for review. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-26 16:24 Message: Logged In: YES user_id=1188172 Attaching a patch which should fix that. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007046&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-728515 ] mmap's resize method resizes the file in win32 but not unix
Bugs item #728515, was opened at 2003-04-27 12:44 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: mmap's resize method resizes the file in win32 but not unix Initial Comment: In the resize method under win32 you have something like this: /* Move to the desired EOF position */ SetFilePointer (self->file_handle, new_size, NULL, FILE_BEGIN); /* Change the size of the file */ SetEndOfFile (self->file_handle); Which resizes the file Under Unix you need to call ftruncate(self->fileno, new_size) before calling remap() to make it do the same thing. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 15:50 Message: Logged In: YES user_id=1188172 Attaching patch which duplicates the file handle under UNIX too (btw, the size() method was broken too), mimics Windows behaviour with resize(), adds a testcase for this and clarifies the docs. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-03 15:12 Message: Logged In: YES user_id=1188172 This is not trivial since the filehandle can be closed at the time the ftruncate() would be necessary. The Windows specific code duplicates the filehandle upon mmap creation, perhaps the UNIX code should do this too? Then, the ftruncate call can be inserted. -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 18:51 Message: Logged In: YES user_id=752496 Reopened as posted that still is a bug. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-30 18:32 Message: Logged In: YES user_id=341410 The problem still persists in Python 2.3 and 2.4. A quick read of mmapmodule.c shows that ftruncate() is not being called within the non-windows portion of mmap_resize_method(). -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 13:59 Message: Logged In: YES user_id=752496 Deprecated. Reopen only if still happens in 2.3 or newer. .Facundo -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 12:55 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 07:36 Message: Logged In: YES user_id=21627 Would you like to contribute a patch? Please make sure to include changes to the documentation and test suite. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728515&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-718532 ] inspect, class instances and __getattr__
Bugs item #718532, was opened at 2003-04-09 15:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Stefan Schwarzer (sschwarzer) >Assigned to: Ka-Ping Yee (ping) Summary: inspect, class instances and __getattr__ Initial Comment: inspect.isclass(class_instance) fails if the corresponding class uses a "wildcard" implementation of __getattr__. Example: Python 2.2.2 (#1, Nov 13 2002, 22:53:57) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import inspect >>> class X: ... def __getattr__(self, name): ... if name == 'foo': ... return 1 ... if name == 'bar': ... return 2 ... else: ... return "default" ... >>> x = X() >>> inspect.isclass(x) 1 The problematic expression in inspect.isclass is hasattr(object, '__bases__') which returns a true value. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-24 00:25 Message: Logged In: YES user_id=80475 Ping, do you have a few minutes to look at this one and make sure its the right thing to do. -- Comment By: Facundo Batista (facundobatista) Date: 2005-05-30 14:15 Message: Logged In: YES user_id=752496 Don't know yet if it's a bug or not, but in Py2.4.1 inspect.isclass() is still returning True in these cases... -- Comment By: Stefan Schwarzer (sschwarzer) Date: 2005-01-28 11:44 Message: Logged In: YES user_id=383516 Hi Facundo The problem still exists in both Python 2.3.4 and 2.4. A possible test case is: import inspect import unittest class TestIsclass(unittest.TestCase): def test_instance_with_getattr(self): class Cls: def __getattr__(self, name): return "not important" obj = Cls() # obj is not a class self.failIf(inspect.isclass(obj)) -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 12:50 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-15 05:40 Message: Logged In: YES user_id=80475 Ping, if this change is made, will isclass() still be able to find extension classes? The addition of the hasattr(object, '__bases__') was made by you in ver 1.11 about two years ago. -- Comment By: Walter Dörwald (doerwalter) Date: 2003-04-15 05:01 Message: Logged In: YES user_id=89016 type(object) in (types.TypeType, types.ClassType) won't work with custom metaclasses. isinstance(object, (type, types.ClassType)) would be better. -- Comment By: Stefan Schwarzer (sschwarzer) Date: 2003-04-15 03:01 Message: Logged In: YES user_id=383516 Hello Raymond, thanks for your reply. In fact, I'm also not sure if it counts as a bug. I also suggested a patch (handle __getattr__ requests for __bases__ with an AttributeError) for for the SF project which causes/d the problem. I think, if there's a better way to decide on "class-ness" than now, the code in inspect should be changed. Fortunately, it doesn't have to be backward-compatible, because the module is always distributed with a certain interpreter version. -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-14 19:36 Message: Logged In: YES user_id=80475 Hmm. I'm not sure that counts as a bug. In an OO language, it's a feature that objects can be made to look like and be substituable for other types. In this case, you've taught your object to be able to fake some classlike behavior (having a __bases__ attribute). OTOH, inspect could have a stronger test for classhood: type(object) in (types.TypeType, types.ClassType) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&ati
[ python-Bugs-1267540 ] _register is not safe
Bugs item #1267540, was opened at 2005-08-24 01:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267540&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. Löwis (loewis) Summary: _register is not safe Initial Comment: The _register function is not safe. It uses the following code to generate a unique string to identify a python callable entity: f = CallWrapper(func, subst, self).__call__ name = repr(id(f)) It then adds the function name if func has a __name__ attribute, but bound methods don't have that, and it is bound methods that cause the problem because they don't have a constant id number unless somebody bothers to keep an explicit reference to the bound reference around (keeping a reference to the object itself isn't enough). For example: class foo: def meth1(self): pass def meth2(self): pass f = foo() print id(f) print id(f.meth1) print id(f.meth2) Odds are good that the last two printed numbers will be the same even though they are for two different bound methods. The id of f will persist and remain unique as long as the object exists, but the id of its bound methods will not. Even though one can call the bound methods as long as the object persists. I don't know how to best handle this. Possibilities include: - Use hash(func) instead of id(func). I don't know enough about the built in hash to know if that is safe. Certainly it is the right idea. One wants a function that has the same value if the callable entity is the same and a different value otherwise. - Generate a new hash function that is sure to work. "paolino" suggested the following hash function for bound methods (when I first asked about this problem on comp.lang.python): id(boundMethod.im_self)^id(boundMethod.im_func) this is probably the simplest solution if hash itself isn't safe, but it requires a some fiddling to figure out what kind of callable entity one has, and thus what hash equation is suitable. - Keep a reference to the callable entity, so its id number cannot be reused. That sounds hard to do safely; it would be all too easy to introduce a memory leak. It can probably be done fairly easily for the case cleanup=1, but there is code that uses cleanup=0 (including bind_all and bind_class). -- Russell -- >Comment By: Martin v. Löwis (loewis) Date: 2005-08-24 07:34 Message: Logged In: YES user_id=21627 Can you provide a test case that demonstrates the problem? I don't think there is anything wrong with that code. We don't take the id of func, we take the id of f, where f is CallWrapper(...).__call__. f gets then passed to tk.createcommand, which in turn puts f into PythonCmd_ClientData. So as long as the Tcl command lives, f (which is indeed a method) is referenced, which in turn means that no other method can have the same id. You are also wrong that the name is not added for bound methods. It looks at im_func, and then takes the name of the function in the bound method. >>> f.meth1.im_func.__name__ 'meth1' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267540&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1267547 ] bdist_rpm hardcodes setup.py as the script name
Bugs item #1267547, was opened at 2005-08-24 01:59
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267547&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fernando Pérez (fer_perez)
Assigned to: Nobody/Anonymous (nobody)
Summary: bdist_rpm hardcodes setup.py as the script name
Initial Comment:
The bdist_rpm command hardcodes 'setup.py' as the name of the setup script in
the .spec file it generates. A grep of the bdist_rpm file shows this:
planck[command]> grep -n -C 3 setup.py bdist_rpm.py
454-
455-# rpm scripts
456-# figure out default build script
457:def_build = "%s setup.py build" % self.python
458-if self.use_rpm_opt_flags:
459-def_build = 'env CFLAGS="$RPM_OPT_FLAGS" ' + def_build
460-
--
468-('prep', 'prep_script', "%setup"),
469-('build', 'build_script', def_build),
470-('install', 'install_script',
471: ("%s setup.py install "
472- "--root=$RPM_BUILD_ROOT "
473- "--record=INSTALLED_FILES") % self.python),
474-('clean', 'clean_script', "rm -rf $RPM_BUILD_ROOT"),
But there are packages out there which ship with multiple setup files, named
setup-foo.py, setup-bar.py, etc. While distutils correctly copies over the
proper setup-X.py file to the build/ directory, the bdist_rpm command fails
because rpm then tries to issue a build command against 'setup.py', which
doesn't exist. An example can be seen by downloading the clnum library from
http://calcrpnpy.sourceforge.net/clnum.html, and trying:
lanck[rpncalc-2.0]> python clnum_setup.py bdist_rpm
running bdist_rpm
creating build
creating build/bdist.linux-i686
creating build/bdist.linux-i686/rpm
creating build/bdist.linux-i686/rpm/SOURCES
creating build/bdist.linux-i686/rpm/SPECS
creating build/bdist.linux-i686/rpm/BUILD
creating build/bdist.linux-i686/rpm/RPMS
creating build/bdist.linux-i686/rpm/SRPMS
writing 'build/bdist.linux-i686/rpm/SPECS/clnum.spec'
running sdist
warning: sdist: manifest template 'MANIFEST.in' does not exist (using default
file list)
warning: sdist: standard file not found: should have one of README, README.txt
writing manifest file 'MANIFEST'
creating clnum-1.0
creating clnum-1.0/clnum
creating clnum-1.0/clnum/src
creating clnum-1.0/test
making hard links in clnum-1.0...
hard linking clnum_setup.py -> clnum-1.0
hard linking clnum/__init__.py -> clnum-1.0/clnum
hard linking clnum/_clnum_str.py -> clnum-1.0/clnum
hard linking clnum/src/clnum.cpp -> clnum-1.0/clnum/src
hard linking test/test_clnum.py -> clnum-1.0/test
[... snip]
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.8191
+ umask 022
+ cd /usr/local/installers/src/rpncalc-2.0/build/bdist.linux-i686/rpm/BUILD
+ cd clnum-1.0
+ LANG=C
+ export LANG
+ unset DISPLAY
+ env 'CFLAGS=-O2 -g -pipe -m32 -march=i386 -mtune=pentium4' python setup.py
build
python: can't open file 'setup.py'
error: Bad exit status from /var/tmp/rpm-tmp.8191 (%build)
I think that the fix is as simple as replacing the hardcoded 'setup.py' name by
os.path.basename(sys.argv[0]), but I'm not 100% sure.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-08-24 07:41
Message:
Logged In: YES
user_id=21627
Would you like to try your proposed fix yourself, and
contribute a patch?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1267547&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257255 ] tarfile local name is local, should be abspath
Bugs item #1257255, was opened at 2005-08-12 04:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257255&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin Blais (blais) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile local name is local, should be abspath Initial Comment: I ran into a bug using the tarfile module with compression from a directory that did not exist anymore, and this exhibits a bug in the tarfile module. I'm not completely sure how to fix it with certainty, so instead of filing a quick patch, I submit a bug so people familiar with the module can have a look first. The problem is that when you open a tarfile with gz or bz2 compression, the TarFile object is opened with a filename that is not absolute, just local (basename is called) but the actual file is using a file-like object. Now, when you add a new entry, there is a check in the TarFile.add method that checks if we're not adding the archive itself into the tarfile, and this method calls abspath. Calling abspath on the name that has been basename'd is incorrect and a bug. It happens not to fail nor cause any problems when called from an existing directory (the test returns false), but it does not do the job it is supposed to. When the CWD has been deleted, calling abspath fails with an OSError, which brings out the problem. Some code to reproduce the bug is provided in an attachment. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-08-24 08:08 Message: Logged In: YES user_id=21627 This was fixed with said patch. -- Comment By: Lars Gustäbel (gustaebel) Date: 2005-08-17 14:34 Message: Logged In: YES user_id=642936 Thank you very much for your report. I added patch #1262036 that ought to fix the problem. -- Comment By: Martin Blais (blais) Date: 2005-08-15 19:34 Message: Logged In: YES user_id=10996 Oops, that was silly. My apologies. Here goes the file... -- Comment By: Lars Gustäbel (gustaebel) Date: 2005-08-15 13:39 Message: Logged In: YES user_id=642936 Could you please attach the test code you mentioned? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257255&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
