Mark Dickinson dicki...@gmail.com added the comment:
Committed to py3k in r74279, release31-maint in r74280. Leaving open for
backport to 2.x.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6595
Mark Dickinson dicki...@gmail.com added the comment:
Backported to trunk and release26-maint in r74281 and r74282.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6595
New submission from Christoph Burgmer cburg...@ira.uka.de:
pydoc fails with a UnicodeEncodeError for properly specified Unicode
docstrings (u...) on the command line interface.
See attached patch that encodes the output with the system's encoding.
--
components: Extension Modules
Guilherme Polo ggp...@gmail.com added the comment:
I have reviewed the latest patch now, it is nice in general but I
dislike the idea of increasing even more EditorWindow. I would really
prefer to put this somewhere else, like.. idlelib/dialogs.py. Also, I'm
inclined to remove this master/parent
Mark Dickinson dicki...@gmail.com added the comment:
Thanks for the report! Fixed in r74285 (trunk), r74286 (release26-maint),
r74287 (py3k) and r74288 (release31-maint).
--
nosy: +marketdickinson
resolution: - fixed
status: open - closed
___
Tarek Ziadé ziade.ta...@gmail.com added the comment:
This was fixed in r71759 and backported in the 2.6 branch in r71765,
thanks for the feedback!
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
Mark Dickinson dicki...@gmail.com added the comment:
So this can happen only if grouping is [0] (or an equivalent iterable).
Since this is an invalid grouping, I think the appropriate response would
be for _grouping_intervals([0]) to raise an exception (which is what it
currently does as
Tarek Ziadé ziade.ta...@gmail.com added the comment:
The vcvarsall.bat eror is unrelated to the error James and Eric are
mentioned, which is another error fixed in the revision Hagen points.
Lenard, could you re-run it under the latest 2.6 version with the global
option --verbose please ?
Tarek Ziadé ziade.ta...@gmail.com added the comment:
The mac/win difference is with the starting dot because it's impossible
under windows to name a file under the directory browser UI that starts
with a .. You have to be a power-user to do so. (pydistutils.cfg
versus .pydistutils.cfg)
Now for
Mark Dickinson dicki...@gmail.com added the comment:
Comparing with trunk, I agree that it seems very likely that 'password' is
intended here.
It's unfortunate that the test-suite doesn't expose this bug; it would be
good to come up with a test that covers this.
--
nosy:
Mark Dickinson dicki...@gmail.com added the comment:
As far as I can tell, it looks safe to just remove these two blocks.
There's a third block that should be removed as well (the second if
os.name == 'mac': ... in the hexbin function.
--
nosy: +marketdickinson
Mark Dickinson dicki...@gmail.com added the comment:
This should be fixed in the 3.1 maintenance branch as well.
--
versions: +Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6621
Mark Dickinson dicki...@gmail.com added the comment:
See also issue 2715.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6621
___
___
Mark Dickinson dicki...@gmail.com added the comment:
This came up again recently in issue 6621.
What's the current status of the binhex module in py3k? It looks as
though the Carbon-specific code has been *partially* but not completely
removed. In particular, there are references to FSSpec
Mark Dickinson dicki...@gmail.com added the comment:
Closing as a duplicate of issue 2715.
--
resolution: - duplicate
status: open - closed
superseder: - Remove carbon-specific code from binhex
___
Python tracker rep...@bugs.python.org
Brett Cannon br...@python.org added the comment:
From my understanding the mac platform is OS 9, so that code in those 'if'
blocks can go.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2715
New submission from Jacob Rus jacobo...@gmail.com:
See discussion started right at the end of the month at
http://mail.python.org/pipermail/python-dev/2009-July/090928.html
And continued at
http://mail.python.org/pipermail/python-dev/2009-August/thread.html
Basically, the mimetypes module is
Tal Einat talei...@users.sourceforge.net added the comment:
The whole point of this patch is to make the EditorWindow's Text widget
the default master/parent for its dialogs!
IMO this makes sense, since this is a reasonable and intuitive default
for such methods of the EditorWindow object. I
New submission from Nikolaus Rath nikol...@rath.org:
When threads are created by a C extension loaded with ctypes,
threading.local() objects are always empty. If one uses
_threading_local.local() instead of threading.local(), the problem does
not occur.
More information and example program
James Abbatiello abb...@gmail.com added the comment:
Further investigation shows that MS asctime() doesn't like leap seconds
and causes an assertion when passing (2008, 12, 31, 23, 59, 60, 2, 366,
-1) - 'Wed Dec 31 23:59:60 2008'.
Given that and since asctime() is such a simple function I think
Jacob Rus jacobo...@gmail.com added the comment:
This diff should leave the semantics of the module essentially unchanged
(including lazy-loading of default files), and also leave the particular
MIME types used unchanged, even though these are out of date and should be
updated; a subsequent
Mark Dickinson dicki...@gmail.com added the comment:
Thanks, Brett. I've removed those blocks in r74289 (py3k) and r74290
(release31-maint).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2715
Mark Dickinson dicki...@gmail.com added the comment:
It looks to me as though this issue can now be closed. Ronald, any
comments?
--
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2715
Jacob Rus jacobo...@gmail.com added the comment:
Here is a version of the patch which does away with the lazy loading:
these are a small handful of easy-to-parse ~40k files; if the import takes
an extra eye-blink, it shouldn't be too big a deal.
--
Added file:
Jacob Rus jacobo...@gmail.com added the comment:
A fixed version of the patch from msg91200, 2009-08-02 20:08
--
Added file: http://bugs.python.org/file14631/mimetypes2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6626
Jacob Rus jacobo...@gmail.com added the comment:
This version (#4) switches to expressing the default types as a list of
tuples instead of as a dict, so that we can include duplicate rows so that
reverse type - extension lookups will behave properly, once we start
changing the actual content
Guilherme Polo ggp...@gmail.com added the comment:
I thought the main point of this issue was to define standard functions,
methods, classes (or something in that sense), in order to make the
creation of tk dialogs uniform across IDLE.
Right now it seems reasonable to keep the parent hidden,
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I know the API well enough (with manipulating dicts/lists etc)
and I still want this function for the sake of convenience.
Given that your level of skill is higher than the average user,
I recommend adding this to your own
Jacob Rus jacobo...@gmail.com added the comment:
Here is a list I generated of all the current Apache mime.types:
I would just as soon include this in the python standard library, either
just the Apache file as is, or even these python object literals (maybe
in a file outside of
Rhett Garber rhe...@gmail.com added the comment:
I've hit this issue as well.
Attached is an updated patch to 2.6 branch and a test case.
I wrote up more details here:
http://nullhole.com/2009/08/02/anatomy-of-a-regression-test/
--
nosy: +rhettg
Added file:
New submission from brian omniscient.br...@gmail.com:
Running Python 3.1/ IDLE, which was installed on top of a Python 2.5.4
install, Mac OSX 10.4
This seems like such an obvious bug, but I can't find it in the current
list of issues - so I suspect that it may not be reproducible on other
31 matches
Mail list logo