[ python-Feature Requests-1656675 ] Drop-Handler for Python files
Feature Requests item #1656675, was opened at 2007-02-10 12:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656675&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: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marek Kubica (leonidasxiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: Drop-Handler for Python files
Initial Comment:
Hi!
We had a dscussion about what happens when one drops a file on a python
sourcecode-file in the python-forum [1]. It turned out, that nothing happens at
all. So someone brought up a solution. It is not really a problem with Python
but it would be nice to add this to the Windows Installer.
The proposed solution was to add the following to the registry (this is the
format of the registry editor):
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Python.File\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"
[HKEY_CLASSES_ROOT\Python.NoConFile\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"
[HKEY_CLASSES_ROOT\Python.CompiledFile\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"
That should be simple thing to do using the MSI-Installer.
[1] only in german, sorry: http://www.python-forum.de/topic-7493.html
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656675&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1653416 ] print >> f, "Hello" produces no error: normal?
Bugs item #1653416, was opened at 2007-02-06 17:23
Message generated for change (Comment added) made by eolebigot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653416&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 Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: E.-O. Le Bigot (eolebigot)
Assigned to: Nobody/Anonymous (nobody)
Summary: print >> f, "Hello" produces no error: normal?
Initial Comment:
When using
print >> f, "Hello"
on a file f opened for reading, no exception is raised. Is this normal?
This situation has to be contrasted with
f.write("Hello")
which raises an exception.
Details with Python 2.5 (r25:51908, Sep 24 206) on OS X 10.4.8 / darwin 8.8.0:
In [1]: f=open("start.01")
In [2]: f.write("Hello")
: [Errno 9] Bad file descriptor
In [3]: print >> f, "Hello"
In [4]: f.close()
NB: file f is not modified, despite the "print" statement yielding no error,
above.
--
>Comment By: E.-O. Le Bigot (eolebigot)
Date: 2007-02-10 12:49
Message:
Logged In: YES
user_id=1440667
Originator: YES
Just for reference: with Fink Python 2.5 (r25:51908, Sep 24 2006) on OS X
10.4.8 / darwin 8.8.0 for Intel Macs, "print >>f, 3" is also silently (and
incorrectly) accepted when f is only opened for reading.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-02-10 00:14
Message:
Logged In: YES
user_id=21627
Originator: NO
There seem to be multiple problems here. AFAICT,
print >>f, 3
fails on both Linux and OSX. This is because this uses fprintf to put out
the number, which, in turn, returns -1. This result is ignored; instead
Python expects ferror() to be set. However, ferror doesn't get set.
For printing strings, fwrite is used. On both Linux and OSX, fwrite will
return 0. On Linux, in addition, ferror gets set; on OSX, it doesn't.
Reading C99, I can't figure out which of these systems is behaving
correctly in what cases. The definition of ferror is that it returns the
"error indicator" of the stream, and only fseek, fputc (+putc), and fflush
are explicitly documented to set the error indicator. However, the error
indicator is also documented to be set that it "records whether a
read/write error has occurred", and write is documented to return a
number smaller than the requested only if an error occurred. Likewise,
fprintf is document to return an negative value "if an output or
encoding error occurred."
Putting these all together, ISTM that both Linux and OSX implement fprintf
incorrectly. To work around, Python could check the result of fprintf and
fwrite in all places; this might become a large change.
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-02-06 19:49
Message:
Logged In: YES
user_id=44345
Originator: NO
I verified this behavior on my Mac with /usr/bin/python, Python 2.5 and
Python 2.6a0, both built from SVN.
Skip
--
Comment By: E.-O. Le Bigot (eolebigot)
Date: 2007-02-06 18:45
Message:
Logged In: YES
user_id=1440667
Originator: YES
Interesting point, about Linux. The incorrect behavior is even seen in
the default python 2.3 that ships with Mac OS X!
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-02-06 18:31
Message:
Logged In: YES
user_id=849994
Originator: NO
If this happens, it's a bug. Though it doesn't seem to occur under Linux
here.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653416&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1656675 ] Drop-Handler for Python files
Feature Requests item #1656675, was opened at 2007-02-10 11:36
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656675&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: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marek Kubica (leonidasxiv)
>Assigned to: Martin v. Löwis (loewis)
Summary: Drop-Handler for Python files
Initial Comment:
Hi!
We had a dscussion about what happens when one drops a file on a python
sourcecode-file in the python-forum [1]. It turned out, that nothing happens at
all. So someone brought up a solution. It is not really a problem with Python
but it would be nice to add this to the Windows Installer.
The proposed solution was to add the following to the registry (this is the
format of the registry editor):
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Python.File\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"
[HKEY_CLASSES_ROOT\Python.NoConFile\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"
[HKEY_CLASSES_ROOT\Python.CompiledFile\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"
That should be simple thing to do using the MSI-Installer.
[1] only in german, sorry: http://www.python-forum.de/topic-7493.html
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656675&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 03:41 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&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: Open Resolution: None Priority: 5 Private: No Submitted By: Sérgio Monteiro Basto (sergiomb) Assigned to: Nobody/Anonymous (nobody) Summary: I think, I have found this bug on time.mktime() Initial Comment: well, I think, I have found this bug on time.mktime() for dates less than 1976-09-26 when I do stringtotime of 1976-09-25 print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) extract date = 1976 9 25 extract time = 0 0 0 timeint 212454000 and timetostring(212454000) = 1976-09-24T23:00:00Z !? To be honest the date that kept me the action was the 1-1-1970 that appears 31-12-1969. After timetostring(stringtotime(date))) I made the test and time.mktime got a bug when date is less than 1976-09-26 see: for 1976-09-27T00:00:00Z time.mktime gives 212630400 for 1976-09-26T00:00:00Z time.mktime gives 212544000 for 1976-09-25T00:00:00Z time.mktime gives 212454000 212630400 - 212544000 = 86400 (seconds) , one day correct ! but 212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds), more one hour ?!? -- Sérgio M. B. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-02-10 15:06 Message: Logged In: YES user_id=849994 Originator: NO This appears to be a timezone/DST issue: on Sept. 26, 1976 Daylight Saving Time ended at least in the European Union. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1654367 ] [PATCH] Debuggers need a way to change the locals of a frame
Feature Requests item #1654367, was opened at 2007-02-07 17:12
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1654367&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 Interpreter Core
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabio Zadrozny (fabioz)
Assigned to: Nobody/Anonymous (nobody)
Summary: [PATCH] Debuggers need a way to change the locals of a frame
Initial Comment:
Debuggers need a way to change the local variables in a given frame...
currently, this works only if this change is done in the topmost frame (and
under certain circumstances), but it should work for any frame.
Initial discussion at:
http://mail.python.org/pipermail/python-dev/2007-February/070884.html
Apparently, the problem is the order in which PyFrame_LocalsToFast /
PyFrame_FastToLocals is called.
The proposed solution to this is having a savelocals() method in the frame
object and have it reflect the changes in its returned dict into its locals. It
will simply enable users to call PyFrame_LocalsToFast externally after a
change, to be sure that it will not be changed (and it must be done before
another call to PyFrame_LocalsToFast -- which I don't see as a large problem,
because it is of restrict use -- mainly for debuggers).
- frameobject.c Patch part 1: -
static PyObject *
PyFrame_SaveLocals(PyFrameObject *f)
{
PyFrame_LocalsToFast(f, 0);
Py_INCREF(Py_None);
return Py_None;
}
static PyMethodDef frame_methodlist[] = {
{"savelocals", (PyCFunction)PyFrame_SaveLocals, METH_NOARGS,
"After a change in f_locals, this method should be called to save the
changes internally."
},
{NULL} /* Sentinel */
};
-- frameobject.c Patch part 2: ---
Add to PyTypeObject PyFrame_Type:
frame_methodlist,/* tp_methods */
-- end patch -
I'm sorry that this is not in an actual patch format... but as I didn't get it
from the cvs, it is easier for me to explain it (as it is a rather small patch).
Attached is a test-case for this patch.
Thanks,
Fabio
--
>Comment By: Armin Rigo (arigo)
Date: 2007-02-10 20:16
Message:
Logged In: YES
user_id=4771
Originator: NO
A point of detail probably, but I suppose that instead of introducing a
new method on frame objects, we could allow f_locals to be a writeable
attribute. Setting it to a dictionary would update the value of the local
variables. It's a bit of a hack, but so is the need for an explicit
savelocals() method.
A cleaner solution is to have f_locals return a dict-like object instead
of a real dict when appropriate, but it takes more efforts to implement.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-02-08 08:38
Message:
Logged In: YES
user_id=21627
Originator: NO
Why don't you set the clear parameter to 1?
Please do submit a patch, you can use 'diff -ur' to create a recursive
unified diff between source trees. Please also try to come up with a patch
to the documentation.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1654367&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1657034 ] 'Ok' key in options dialog does nothing
Bugs item #1657034, was opened at 2007-02-11 01:35 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=1657034&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: torhu (torhu) Assigned to: Nobody/Anonymous (nobody) Summary: 'Ok' key in options dialog does nothing Initial Comment: IDLE 1.2, winxp sp2 US. I get the same results with idlelib from svn rev. 53721. Steps to reproduce: 1. Open Options -> Configure IDLE... 2. Click on the Ok button. 3. Nothing happens, you have to click Cancel to close the options window. Here's a way that crashes IDLE on my machine: 1. Open Options -> Configure IDLE... 2. Set Indentation width to 8 (was 4 by default). 3. Click on Apply. 4. Click on Ok (nothing happens). 5. Click on Cancel - IDLE exits. Workaround: Replace the Python25/Lib/idlelib directory with the one that comes with python 2.4.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1657034&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656581 ] tarfile.TarFile fileobject use needs clarification
Bugs item #1656581, was opened at 2007-02-10 00:45 Message generated for change (Comment added) made by herrwitten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656581&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: Open Resolution: None Priority: 5 Private: No Submitted By: Witten (herrwitten) Assigned to: Lars Gustäbel (gustaebel) Summary: tarfile.TarFile fileobject use needs clarification Initial Comment: The constructor of a TarFile object expects an existing file object to have its file position at 0. This is not documented. -- >Comment By: Witten (herrwitten) Date: 2007-02-11 00:35 Message: Logged In: YES user_id=1595909 Originator: YES I suppose I could make this clearer: The user needs to know that the file object will be used from the current file position. -- Comment By: Witten (herrwitten) Date: 2007-02-10 00:47 Message: Logged In: YES user_id=1595909 Originator: YES A clarification: When an existing file object is used to create a TarFile object, the TarFile object expects the existing file object to have its file position at 0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656581&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
