[ python-Bugs-1713252 ] character set in Japanese on Ubuntu distribution
Bugs item #1713252, was opened at 2007-05-05 05:16 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713252&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: Pending Resolution: None Priority: 5 Private: No Submitted By: Christopher Grell (cgrell) Assigned to: Nobody/Anonymous (nobody) Summary: character set in Japanese on Ubuntu distribution Initial Comment: I tried to use IDLE on new Ubuntu 7.04 and the window opens with Japanese character set -- >Comment By: Georg Brandl (gbrandl) Date: 2007-05-05 07:08 Message: Logged In: YES user_id=849994 Originator: NO As this is certainly not the case in other distributions, this is something you should file with the Ubuntu bug tracker. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713252&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1713535 ] Error inside logging module's documentation
Bugs item #1713535, was opened at 2007-05-05 20:01
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=1713535&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: billiejoex (billiejoex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error inside logging module's documentation
Initial Comment:
http://docs.python.org/lib/module-logging.html
Inside the explanation of logging.debug an example code is showed:
FORMAT = "%(asctime)-15s %(clientip)s %(user)-8s %(message)s"
logging.basicConfig(format=FORMAT)
dict = { 'clientip' : '192.168.0.1', 'user' : 'fbloggs' }
logging.warning("Protocol problem: %s", "connection reset", extra=d)
In the code "dict" is created but never used.
When logging.warning is called the author use the argument 'd' instead of
'dict' and no reference to 'd' exists:
logging.warning("Protocol problem: %s", "connection reset", extra=d)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713535&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1713535 ] Error inside logging module documentation
Bugs item #1713535, was opened at 2007-05-05 20:01
Message generated for change (Settings changed) made by billiejoex
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713535&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: 1
Private: No
Submitted By: billiejoex (billiejoex)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Error inside logging module documentation
Initial Comment:
http://docs.python.org/lib/module-logging.html
Inside the explanation of logging.debug an example code is showed:
FORMAT = "%(asctime)-15s %(clientip)s %(user)-8s %(message)s"
logging.basicConfig(format=FORMAT)
dict = { 'clientip' : '192.168.0.1', 'user' : 'fbloggs' }
logging.warning("Protocol problem: %s", "connection reset", extra=d)
In the code "dict" is created but never used.
When logging.warning is called the author use the argument 'd' instead of
'dict' and no reference to 'd' exists:
logging.warning("Protocol problem: %s", "connection reset", extra=d)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713535&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1713535 ] Error inside logging module documentation
Bugs item #1713535, was opened at 2007-05-05 20:01
Message generated for change (Settings changed) made by billiejoex
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713535&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: billiejoex (billiejoex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error inside logging module documentation
Initial Comment:
http://docs.python.org/lib/module-logging.html
Inside the explanation of logging.debug an example code is showed:
FORMAT = "%(asctime)-15s %(clientip)s %(user)-8s %(message)s"
logging.basicConfig(format=FORMAT)
dict = { 'clientip' : '192.168.0.1', 'user' : 'fbloggs' }
logging.warning("Protocol problem: %s", "connection reset", extra=d)
In the code "dict" is created but never used.
When logging.warning is called the author use the argument 'd' instead of
'dict' and no reference to 'd' exists:
logging.warning("Protocol problem: %s", "connection reset", extra=d)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713535&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1713535 ] Error inside logging module documentation
Bugs item #1713535, was opened at 2007-05-05 18:01
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713535&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
Private: No
Submitted By: billiejoex (billiejoex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error inside logging module documentation
Initial Comment:
http://docs.python.org/lib/module-logging.html
Inside the explanation of logging.debug an example code is showed:
FORMAT = "%(asctime)-15s %(clientip)s %(user)-8s %(message)s"
logging.basicConfig(format=FORMAT)
dict = { 'clientip' : '192.168.0.1', 'user' : 'fbloggs' }
logging.warning("Protocol problem: %s", "connection reset", extra=d)
In the code "dict" is created but never used.
When logging.warning is called the author use the argument 'd' instead of
'dict' and no reference to 'd' exists:
logging.warning("Protocol problem: %s", "connection reset", extra=d)
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-05-05 18:57
Message:
Logged In: YES
user_id=849994
Originator: NO
Thanks for the report, fixed in rev. 55154, 55155.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1713535&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-1713624 ] commands module
Feature Requests item #1713624, was opened at 2007-05-05 22:11
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=1713624&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: Windows
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joseph Armbruster (joearmbruster)
Assigned to: Nobody/Anonymous (nobody)
Summary: commands module
Initial Comment:
In reference to the commands module, and it's simple self :-)
Current comments in the module state the following:
# Module 'commands'
#
# Various tools for executing commands and looking at their output and status.
#
# NB This only works (and is only relevant) for UNIX.
Ultimately, I would like to see the following:
1) This comment removed:
# NB This only works (and is only relevant) for UNIX.
1) A change to getstatusoutput along these lines:
if os.name == 'nt':
pipe = os.popen(cmd + ' 2>&1','r')
else:
pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
* I was going to suggest having a more pythonic getstatus method, that would
act reasonably similar across platforms (maybe using some combination of
os.listdir and os.stat or something), however, it is being deprecated, so
onward!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1713624&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566331 ] Bad behaviour in .obuf*
Bugs item #1566331, was opened at 2006-09-27 13:19 Message generated for change (Comment added) made by rluse You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566331&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: None Priority: 5 Private: No Submitted By: Sam Dennis (samdennis) Assigned to: Greg Ward (gward) Summary: Bad behaviour in .obuf* Initial Comment: The _ssize() function in ossaudiodev.c (2.4.3, but it's the same in svn) calls SNDCTL_SET_CHANNELS with channels=0 as part of an attempt to determine the total number of samples per second for the current configuration of the audio device, but as far as I can tell this is not guaranteed to act as a query and at least two implementations treat it as a request for a monaural format (the ALSA pcm-oss module and the alsa-oss library). What this can safely be replaced with I don't know; both Linux's OSS drivers and ALSA support SOUND_PCM_READ_CHANNELS but this is not standard to the best of my knowledge. Storing the value returned when the program calls .setfmt or .setparameters may be an option. -- Comment By: Bob Luse (rluse) Date: 2007-05-06 03:41 Message: Logged In: YES user_id=1688601 Originator: NO I just wanted to confirm that this is problem for me as well when I run this. I am writing an application where I need to get buffer information when I am running with 2 channels. This is a quite normal situation these days. I assume that the change is made to mono because in OSS mono is the default, so that it will work with what is now quite ancient hardware. But, requesting the buffer size should not cause such a dramatic error. I don't understand why this is such a problem. Could there be a parameter for number of channels since you cannot request the buffer size unless you have already setup the hardware giving the number of channels? So even if the System cannot figure out the number of channels, your application knows it and can tell it. Granted, it is a kluge, but it is a kluge that can work whereas currently whenever you request buffer information the speed of your sound is cut in half making the obuf commands unusable. Possibly another solution would be to remove these commands until they work. I did notice that the program does reference SOUND_PCM_WRITE_CHANNELS. Is SOUND_PCM_WRITE_CHANNELS standard and SOUND_PCM_READ_CHANNELS not standard? I don't know that that is not true, but it does seem strange. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566331&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1707768 ] os.path.normpath changes path (chops of trailing slash)
Bugs item #1707768, was opened at 2007-04-26 01:44
Message generated for change (Comment added) made by siemer
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707768&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.normpath changes path (chops of trailing slash)
Initial Comment:
Hello everybody!
>>> os.path.normpath('/etc/passwd')
'/etc/passwd'
I don't know any environment at all where
a) '/etc/passwd/'
b) '/etc/passwd'
are treated the same. It clearly does not apply for the path part of http urls
(this is left as an exercise for the reader).
But it also does not apply for (e.g.) Linux either:
an open() on path a) return ENOTDIR while it succeeds with b).
(assuming /etc/passwd is a file)
This is definitively not a documentation bug, as "normpath" should normalize a
path and not fuck it up.
Robert
--
>Comment By: Robert Siemer (siemer)
Date: 2007-05-06 06:15
Message:
Logged In: YES
user_id=150699
Originator: YES
1) I (submitter) didn't specify what I expected to see:
os.path.normpath('/etc/passwd/') --> '/etc/passwd/'
So, I agree with the latest consensus, but definitely not with the
"/etc/passwd/." version...
2) I can't draw any explicit normalization rules from the excerpts of the
POSIX standard posted by iszegedi. Saying that "dir/" should be treated as
"dir/." doesn't mean that it is the normalized version of the first one. -
I actually read implicitly that the first one is the habitual one that
needs interpretation.
And I think everybody agrees that - beeing the same or not - "dir/." is
unusual.
3) I don't know what this is good for in the proposal:
path = path.rstrip()
It removes significant whitespace from the path, what must be avoided.
--
Comment By: Istvan Szegedi (iszegedi)
Date: 2007-05-01 20:05
Message:
Logged In: YES
user_id=1772412
Originator: NO
I must admit that josm's comments make sense: in fact, I quickly tried out
how mkdir command from a bash shell would behave and it does the same:
# mkdir hello
# rmdir hello/.
Invalid argument
whereas
# rmdir hello/
works fine. I also wrote a small C program using mkdir() and rmdir()
functions and they behave exactly the same as mkdir/rmdir from bash (well,
no real suprise).
My suggestion to get the original issue fixed was based on POSIX standard
and apparently the Linux commands are not fully POSIX compliant, either...
Or do I misunderstand the quotes from the standard? Anyway, it is pretty
easy to modify my fix to be inline with Linux commands and C functions -
everything could be the same, apart from the last line where I added "/."
-- this should be only "/". So the entire function could look like this:
-- clip --
def normpath(path):
"""Normalize path, eliminating double slashes, etc."""
if path == '':
return '.'
initial_slashes = path.startswith('/')
# The next two lines were added by iszegedi
path = path.rstrip()
trailing_slash = path.endswith('/')
# POSIX allows one or two initial slashes, but treats three or more
# as single slash.
if (initial_slashes and
path.startswith('//') and not path.startswith('///')):
initial_slashes = 2
comps = path.split('/')
new_comps = []
for comp in comps:
if comp in ('', '.'):
continue
if (comp != '..' or (not initial_slashes and not new_comps) or
(new_comps and new_comps[-1] == '..')):
new_comps.append(comp)
elif new_comps:
new_comps.pop()
comps = new_comps
path = '/'.join(comps)
if initial_slashes:
path = '/'*initial_slashes + path
# The next two lines were added by iszegedi
if trailing_slash:
path = path + '/'
return path or '.'
-- clip --
Nevertheless, I would really appreciate to receive some comments from
POSIX gurus, how they see this problem.
--
Comment By: jos (josm)
Date: 2007-04-30 08:48
Message:
Logged In: YES
user_id=1776568
Originator: NO
I think we should be careful enough to tackle on this.
iszegedi's patch seems to work correctly,
but XBD's spec itself has some defect.
http://www.opengroup.org/austin/mailarchives/ag-review/msg01722.html
What do you think of the follow behavior?
>>> os.mkdir('dir/')
>>> os.mkdir('dir2/')
>>> os.rmdir(os.path.normpath('dir'))
>>> os.rmdir(os.path.normpath('dir2/'))
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 22] Invalid argument: 'dir2/.'
--
[ python-Feature Requests-1713624 ] commands module
Feature Requests item #1713624, was opened at 2007-05-05 19:11
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1713624&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: Windows
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joseph Armbruster (joearmbruster)
Assigned to: Nobody/Anonymous (nobody)
Summary: commands module
Initial Comment:
In reference to the commands module, and it's simple self :-)
Current comments in the module state the following:
# Module 'commands'
#
# Various tools for executing commands and looking at their output and status.
#
# NB This only works (and is only relevant) for UNIX.
Ultimately, I would like to see the following:
1) This comment removed:
# NB This only works (and is only relevant) for UNIX.
1) A change to getstatusoutput along these lines:
if os.name == 'nt':
pipe = os.popen(cmd + ' 2>&1','r')
else:
pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
* I was going to suggest having a more pythonic getstatus method, that would
act reasonably similar across platforms (maybe using some combination of
os.listdir and os.stat or something), however, it is being deprecated, so
onward!
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-05-05 23:46
Message:
Logged In: YES
user_id=341410
Originator: NO
Recent discussions in one of the python development lists has basically
stated that the commands module will be deprecated in favor of being
replaced by equivalent platform independent versions based on subprocess,
which will be placed in the subprocess module. As such, it is doubtful
that your request will be fulfilled. Suggested close as 'wont fix'.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1713624&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
