[ python-Bugs-905389 ] str.join() intercepts TypeError raised by iterator

[SourceForge.net]

Bugs item #905389, was opened at 2004-02-26 21:19
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905389&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.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Lenard Lindstrom (kermode)
Assigned to: Nobody/Anonymous (nobody)
Summary: str.join() intercepts TypeError raised by iterator

Initial Comment:
For str.join(), if it is passed an iterator and that 
iterator raises a TypeError, that exception is caught 
by the join method and replaced by its own 
TypeError exception. SyntaxError and IndexError 
exceptions are uneffected.

Example:

Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC 
v.1200 32 bit (Intel)] on win32
...
IDLE 1.0.2  
>>> def gen(n):
if not isinstance(n, int):
raise TypeError, "gen() TypeError"
if n<0:
raise IndexError,  "gen() 
IndexError"
for i in range(n):
yield str(i)


>>> ''.join(gen(5))
'01234'
>>> ''.join(gen(-1))

Traceback (most recent call last):
  File "", line 1, in -toplevel-
''.join(gen(-1))
  File "", line 5, in gen
raise IndexError, "gen() IndexError"
IndexError: gen() IndexError
>>> ''.join(gen(None))

Traceback (most recent call last):
  File "", line 1, in -toplevel-
''.join(gen(None))
TypeError: sequence expected, generator found
>>> 


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-14 08:10

Message:
Logged In: YES 
user_id=849994

This is fixed on the trunk.

--

Comment By: Paul Moore (pmoore)
Date: 2004-06-05 19:13

Message:
Logged In: YES 
user_id=113328

Unicode objects do not have this behaviour. For example:

>>> u''.join(gen(None))
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 3, in gen
TypeError: gen() TypeError

The offending code is at line 1610 or so of stringobject.c.
The equivalent Unicode code starts at line 3955 of
unicodeobject.c.

The string code does a 2-pass approach to calculate the size
of the result, allocate space, and then build the value. The
Unicode version resizes as it goes along. This *may* be a
significant speed optimisation (on the assumption that
strings are more commonly used than Unicode objects), but I
can't test (no MSVC7 to build with).

If the speed issue is not significant, I'd recommend
rewriting the string code to use the same approach the
Unicode code uses. Otherwise, the documentation for str.join
should clarify these points:

1. The sequence being joined is materialised as a tuple
(PySequence_Fast) - this may have an impact on generators
which use a lot of memory.
2. TypeErrors produced by materialising the sequence being
joined will be caught and re-raised with a different message.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905389&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1505841 ] Add support for GNU --long options (interpreter)

[SourceForge.net]

Bugs item #1505841, was opened at 2006-06-14 11:15
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=1505841&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: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Jari Aalto (jaalto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for GNU --long options (interpreter)

Initial Comment:
This is forwarded wishlist from Debian bug tracking 
system.
http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?
bug=289007

It would be good if Python supported standard GNU long 
options. Please support both short and long forms for 
all options. Like

python --help
python --version
...


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505841&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1153163 ] reflected operator not used when operands have the same type

[SourceForge.net]

Bugs item #1153163, was opened at 2005-02-28 01:09
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153163&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.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Hugh Secker-Walker (hughsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: reflected operator not used when operands have the same type

Initial Comment:

The reflected operators, e.g. __radd__, are used when
the left operand does not have the non-reflected
operator, *unless* the right operand is of the same type.

The documentation on the "Emulating numeric types" page
doesn't mention this peculiar exclusion.  Of the
reflected operators it says:
"These methods are called to implement the binary
arithmetic operations (+, -, *, /, %, divmod(), pow(),
**, <<, >>, &, ^, |) with reflected (swapped) operands.
These functions are only called if the left operand
does not support the corresponding operation. For
instance, to evaluate the expression x-y, where y is an
instance of a class that has an __rsub__() method,
y.__rsub__(x) is called."

This code demonstrates the correct behavior and then
the problem:

class A(object):
def __radd__(self, other):
return '__radd__', other

print None + A()
print A() + A()

giving

('__radd__', None)

Traceback (most recent call last):
  File "C:/Temp/reflectedbug.py", line 6, in -toplevel-
print A() + A()
TypeError: unsupported operand type(s) for +: 'A' and 'A'

I've replaced None in the first print statement with
many kinds of builtin objects, instances of other
classes, and with instances of subclasses of A.  In all
these cases the __radd__ operator is used as
documented.  I've only seen the problem when the two
operands are of the same type.

This problem also occurs during the backing-off to
plain operators that occurs when augmented operators,
e.g. __iadd__, aren't implemented by the type and the
operands are of the same type.

This problem is present in 2.4 on Linux and Windows,
and in the current CVS version (2.5a0, 27-Feb-05) on Linux.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-14 08:32

Message:
Logged In: YES 
user_id=849994

I added some wording to the docs along your suggestions.
Fixed in rev. 46952, 46953.

--

Comment By: Hugh Secker-Walker (hughsw)
Date: 2005-03-02 03:25

Message:
Logged In: YES 
user_id=1146279

Upon reflection and offline discussion it appears to me that
Python is behaving as designed and that the documentation is
buggy in that it fails to mention the special cases
demonstrated in this bug report.

The two special cases that the documentation should mention are:

1) The reflected operator is never used if the two operands
are of the same type, regardless of whether the
non-reflected operator exists.  

The necessity of this isn't clear to me.

2) If the type of the right-hand operand is a subclass of
the type of the left-hand operand, and if the right-hand
operand overloads the reflected operator from whatever is
(or isn't) implemented by the left-hand operand, then the
reflected operator of the right-hand operand will be used,
regardless of the presence of the non-reflected operator for
either type.  This behavior is necessary for subclasses to
overload parent class operators. 

-Hugh



--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 05:08

Message:
Logged In: YES 
user_id=593130

I believe Python's designer(s) intend that if A()+A() is valid, then 
A will have an __add__ method.  __rxxx__ is only intended for 
backup use with mixed types.  So your example sends a mixed 
message to the interpreter.

If the current behavior is both intended and still necessary, the 
manual sentence
"These functions are only called if the left operand
does not support the corresponding operation"
could be augmented with 
"and has a different type than the right operand"


--

Comment By: Hugh Secker-Walker (hughsw)
Date: 2005-03-01 04:36

Message:
Logged In: YES 
user_id=1146279

The problem is in the SLOT1BINFULL() macro near line 4020 in
typeobject.c.  In two places it ensures that the reflected
(reversed, swapped, rop, you name it) operator won't
be called if the two operands are of the same type. 
Removing these two exclusions fixes the problem.  

However, this being my third day ever modifying Python
source code, for all intents and purposes, I have no idea
why the exclusions were there (efficiency?).  And,
elsewhere, I saw high-level code that h

[ python-Bugs-1505841 ] Add support for GNU --long options (interpreter)

[SourceForge.net]

Bugs item #1505841, was opened at 2006-06-14 08:15
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505841&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: Feature Request
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Jari Aalto (jaalto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for GNU --long options (interpreter)

Initial Comment:
This is forwarded wishlist from Debian bug tracking 
system.
http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?
bug=289007

It would be good if Python supported standard GNU long 
options. Please support both short and long forms for 
all options. Like

python --help
python --version
...


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-14 08:33

Message:
Logged In: YES 
user_id=849994

This is already tracked in #1481112.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505841&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1202018 ] mimetypes.py does not find mime.types on Mac OS X

[SourceForge.net]

Bugs item #1202018, was opened at 2005-05-14 16:57
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202018&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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Stefan H. Holek (shh42)
Assigned to: Nobody/Anonymous (nobody)
Summary: mimetypes.py does not find mime.types on Mac OS X

Initial Comment:
Python 2.3 and 2.4 (dunno about 2.5)

The mimetypes.py library does not find the mime.types files on Mac 
OS X. They are in:

/etc/cups/mime.types and
/etc/httpd/mime.types respectively.

As a result not all mimetypes are recognized by Python. The one in /
etc/cups is fairly limited, so including the Apache one as well seems 
like a good idea.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-14 08:42

Message:
Logged In: YES 
user_id=849994

Added some mime.types locations in rev. 46954.

--

Comment By: Stefan H. Holek (shh42)
Date: 2005-05-14 16:59

Message:
Logged In: YES 
user_id=864871

This is a with a standalone build of Python, I am not talking about the 
Python shipping with the system.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202018&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1117556 ] SimpleHTTPServer and mimetypes: almost together

[SourceForge.net]

Bugs item #1117556, was opened at 2005-02-06 23:01
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117556&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: Matthew L Daniel (mdaniel)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleHTTPServer and mimetypes: almost together

Initial Comment:
SimpleHTTPServer.py from python2.4 (and python2.3, so
this is an old bug that hasn't bothered anyone before
now), uses mimetypes for mime-type detection.

The issue is that it only uses 50% of mimetypes, in two
different ways.

I argue that SimpleHTTPServer should not be copying
mimetypes type-map into its own variable instead of
leveraging  the functionality found in
mimetypes.guess_type (which guesses without regard to
case, btw).

If, however, you guys stick with your own
extension_map, this bug is really about calling ``if
not mimetypes.inited: mimetypes.init()'' before doing
any such copying.

This allows mimetypes to find mime.types on the local
host and populate the types_map with lots of meaningful
mime types. If it doesn't find any mime.types, no harm
done.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-14 08:50

Message:
Logged In: YES 
user_id=849994

Thanks, fixed in 46955, 46956 (2.4).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117556&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1229380 ] No struct.pack exception for some out of range integers

[SourceForge.net]

Bugs item #1229380, was opened at 2005-06-28 23:30
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&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: Adal Chiriliuc (adalx)
Assigned to: Bob Ippolito (etrepum)
Summary: No struct.pack exception for some out of range integers

Initial Comment:
struct.pack("B", -1) generates an OverflowError
exception since the B format corresponds to the
"unsigned char" type which can have values between 0
and 255.

But struct.pack("I", -1) and struct.pack("L", -1) do
not generate these errors, even if struct.pack("I",
-1L) and struct.pack("L", -1L) do (notice the final L).


--

Comment By: Bob Ippolito (etrepum)
Date: 2006-05-26 13:16

Message:
Logged In: YES 
user_id=139309

The test suite now covers this issue and it's fixed in revision 46320.

Note that this is definitely a backwards incompatible change and we might have 
to change it to a warning or something stupid like that.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-24 10:25

Message:
Logged In: YES 
user_id=849994

Assigning to Bob since he rewrote/extended the struct module
for 2.5.

--

Comment By: Ilya Sandler (isandler)
Date: 2006-04-27 14:46

Message:
Logged In: YES 
user_id=971153


Also it appears that there is some kind of interference
between range checking and byte-order chars:

  import struct; struct.pack("H", 7)  #Exception

  import struct; struct.pack(">H", 7) # no exception

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-02-20 20:52

Message:
Logged In: YES 
user_id=849994

Attaching patch, raises struct.error. Neal, please look over it.

Note that I find struct's error handling confusing: it's not
clear from the docs in which cases OverflowError is raised,
and in which struct.error.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229380&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-756924 ] SIGSEGV causes hung threads (Linux)

[SourceForge.net]

Bugs item #756924, was opened at 2003-06-18 23:28
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756924&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: Threads
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Greg Jones (morngnstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: SIGSEGV causes hung threads (Linux)

Initial Comment:
When a segmentation fault happens on Linux in any 
thread but the main thread, the program exits, but 
zombie threads remain behind.

Steps to reproduce:
1. Download attached tar and extract files zombie.py 
and zombieCmodule.c.
2. Compile and link zombieCmodule.c as a shared library 
(or whatever other method you prefer for making a 
Python extension module).
3. Put the output from step 2 (zombieC.so) in your 
lib/python directory.
4. Run python2.2 zombie.py.
5. After the program exits, run ps.

zombie.py launches several threads that just loop 
forever, and one that calls a C function in zombieC. The 
latter prints "NULL!" then segfaults intentionally, 
printing "Segmentation fault". Then the program exits, 
returning control back to the shell.

Expected, and Python 2.1 behavior:
No Python threads appear in the output of ps.

Actual Python 2.2 behavior:
5 Python threads appear in the output of ps. To kill 
them, you have to apply kill -9 to each one individually.

  Not only does this bug leave around messy zombie 
threads, but the threads left behind hold on to program 
resources. For example, if the program binds a socket, 
that port cannot be bound again until someone kills the 
threads. Of course programs should not generate 
segfaults, but if they do they should fail gracefully.

  I have identified the cause of this bug. The old Python 
2.1 behavior can be restored by removing these lines of 
Python/thread_pthread.h:

sigfillset(&newmask);
SET_THREAD_SIGMASK(SIG_BLOCK, &newmask, 
&oldmask);

... and ...

SET_THREAD_SIGMASK(SIG_SETMASK, &oldmask, NULL);

  I guess even SIGSEGV gets blocked by this code, and 
somehow that prevents the default behavior of segfaults 
from working correctly.

  I'm not suggesting that removing this code is a good 
way to fix this bug. This is just an example to show that 
it seems to be the blocking of signals that causes this 
bug.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-14 09:18

Message:
Logged In: YES 
user_id=849994

It seems that the patch at 960406 was applied and fixed this
problem.

--

Comment By: Andrew Langmead (langmead)
Date: 2004-05-26 17:19

Message:
Logged In: YES 
user_id=119306

The patch in  is 
probably a better change to consider rather than the LinuxThreads 
specific workarounds of 948614 or the false synchronous/
asynchronous dichotomy of 949332. (948614 was just looking at 
things in terms of LinuxThreads specific quirks, and when 
comments started popping up about similar problems in HP/UX 
and others it became apparent that a more general approach was 
needed. 949332 was a hope that a minimally intrusive variation 
might get be more palatable for 2.3.4, but I can perfectly 
understand your reluctance.)

The new patch, 960406, seems to solve the problems Jason Lowe 
reported in  
(at least with my testing under Linux, Solaris, Irix, HP/UX, and 
True64 Unix) but does not exhibit the problems described here.

--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-05-26 15:43

Message:
Logged In: YES 
user_id=29957

This will not be in 2.3.4, as I've already stated.

a) We've already cut the release candidate, and the final
release is less than 12 hours away
b) this is a high-risk patch -- anything in the area of
threads and signals is very risky.

Here's how it should go forward:

First, the trunk should be patched. This fix can then be in
2.4a1.
Once we're through to 2.4 final, we'll know whether the fix
is good enough for the 2.3 series.
Finally, after 2.4 final comes out, there will be a 2.3.5.
This fix can be in that, assuming it's fine in 2.4.



--

Comment By: Dieter Maurer (dmaurer)
Date: 2004-05-26 11:28

Message:
Logged In: YES 
user_id=265829

The Python documentation currently asserts that signals are
delivered only to the main thread.

I think we can deviate from this assertion for signals that
are not normally used by applications but are used by the OS
to indicate abnorma

[ python-Bugs-895567 ] os.listdir fails for pathprefix \\?\d:...

[SourceForge.net]

Bugs item #895567, was opened at 2004-02-12 09:15
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=895567&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: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Guenter Kruschina (kruschina)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.listdir fails for pathprefix \\?\d:...

Initial Comment:
The  function os.listdir() fails with arguments
beggining with \\?\... . This is necessary under
windows to switch off pathchecking  for all
Win32-Widecharacter functions. The problem is located
in the posixmodule.

A diff -u will show the solution for this problem:

--- posixmodule.c   2004-01-30 16:51:18.768574400 +0100
+++ posixmodule.c.org   2003-12-03 02:21:01.0 +0100
@@ -1386,7 +1386,7 @@
len = wcslen(wnamebuf);
wch = (len > 0) ?
wnamebuf[len-1] : L'\0';
if (wch != L'/' && wch != L'\\'
&& wch != L':')
-   wnamebuf[len++] = L'\\';
+   wnamebuf[len++] = L'/';
wcscpy(wnamebuf + len, L"*.*");
if ((d = PyList_New(0)) == NULL)
return NULL;


By the way: The functions isdir..isfile...etc also does
not work with the pathprefix \\?\

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-14 09:34

Message:
Logged In: YES 
user_id=849994

It seems that someone applied the patch. Closing this
accordingly.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=895567&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1504676 ] Make sgmllib char and entity references pluggable

[SourceForge.net]

Bugs item #1504676, was opened at 2006-06-12 06:41
Message generated for change (Comment added) made by rubys
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&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
Submitted By: Sam Ruby (rubys)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Make sgmllib char and entity references pluggable

Initial Comment:
The changes being made to sgmllib in Python 2.5 may
break existing applications.  This patch makes it easy
for subclasses to revert to the old behavior. 
Additionally, it makes it easier to provide new
behaviors, like supporting unicode, hexadecimal
character references, and additional entities.

--

>Comment By: Sam Ruby (rubys)
Date: 2006-06-14 08:59

Message:
Logged In: YES 
user_id=141556

updated patch with test case.

Note that in the pre-existing code tag data values are
transformed twice -- this should be corrected and ideally
the code for handing references should be unified. 

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-06-14 01:14

Message:
Logged In: YES 
user_id=3066

This patch certainly makes the subclass interface nicer; I
like that.  There is a case that it breaks (foolishly not
covered by the existing tests, but clear on reading the
patch that it broke).  I've added the relevant test in this
change:

http://mail.python.org/pipermail/python-checkins/2006-June/053975.html

The problem with the patch is that attribute values are
transformed twice (once for entity refs, once for character
refs), instead of just once, so entity ref expansions can
cause character refs to be located that aren't in the markup.

I'm out of time tonight, but should be able to make this
patch work with the additional tests tomorrow night if sruby
doesn't beat me to it.

Documentation and tests for the subclass interface changes
are still needed as well.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1504676 ] Make sgmllib char and entity references pluggable

[SourceForge.net]

Bugs item #1504676, was opened at 2006-06-12 06:41
Message generated for change (Comment added) made by rubys
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&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
Submitted By: Sam Ruby (rubys)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Make sgmllib char and entity references pluggable

Initial Comment:
The changes being made to sgmllib in Python 2.5 may
break existing applications.  This patch makes it easy
for subclasses to revert to the old behavior. 
Additionally, it makes it easier to provide new
behaviors, like supporting unicode, hexadecimal
character references, and additional entities.

--

>Comment By: Sam Ruby (rubys)
Date: 2006-06-14 09:02

Message:
Logged In: YES 
user_id=141556

Note that the pre-existing code transforms tag data twice.

Ideally, the handing for entities in attributes and data
would be unified.

--

Comment By: Sam Ruby (rubys)
Date: 2006-06-14 08:59

Message:
Logged In: YES 
user_id=141556

updated patch with test case.

Note that in the pre-existing code tag data values are
transformed twice -- this should be corrected and ideally
the code for handing references should be unified. 

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-06-14 01:14

Message:
Logged In: YES 
user_id=3066

This patch certainly makes the subclass interface nicer; I
like that.  There is a case that it breaks (foolishly not
covered by the existing tests, but clear on reading the
patch that it broke).  I've added the relevant test in this
change:

http://mail.python.org/pipermail/python-checkins/2006-June/053975.html

The problem with the patch is that attribute values are
transformed twice (once for entity refs, once for character
refs), instead of just once, so entity ref expansions can
cause character refs to be located that aren't in the markup.

I'm out of time tonight, but should be able to make this
patch work with the additional tests tomorrow night if sruby
doesn't beat me to it.

Documentation and tests for the subclass interface changes
are still needed as well.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1504676 ] Make sgmllib char and entity references pluggable

[SourceForge.net]

Bugs item #1504676, was opened at 2006-06-12 06:41
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&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
Submitted By: Sam Ruby (rubys)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Make sgmllib char and entity references pluggable

Initial Comment:
The changes being made to sgmllib in Python 2.5 may
break existing applications.  This patch makes it easy
for subclasses to revert to the old behavior. 
Additionally, it makes it easier to provide new
behaviors, like supporting unicode, hexadecimal
character references, and additional entities.

--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-06-14 09:06

Message:
Logged In: YES 
user_id=3066

Thanks.  I'll look into this again tonight.

--

Comment By: Sam Ruby (rubys)
Date: 2006-06-14 09:02

Message:
Logged In: YES 
user_id=141556

Note that the pre-existing code transforms tag data twice.

Ideally, the handing for entities in attributes and data
would be unified.

--

Comment By: Sam Ruby (rubys)
Date: 2006-06-14 08:59

Message:
Logged In: YES 
user_id=141556

updated patch with test case.

Note that in the pre-existing code tag data values are
transformed twice -- this should be corrected and ideally
the code for handing references should be unified. 

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-06-14 01:14

Message:
Logged In: YES 
user_id=3066

This patch certainly makes the subclass interface nicer; I
like that.  There is a case that it breaks (foolishly not
covered by the existing tests, but clear on reading the
patch that it broke).  I've added the relevant test in this
change:

http://mail.python.org/pipermail/python-checkins/2006-June/053975.html

The problem with the patch is that attribute values are
transformed twice (once for entity refs, once for character
refs), instead of just once, so entity ref expansions can
cause character refs to be located that aren't in the markup.

I'm out of time tonight, but should be able to make this
patch work with the additional tests tomorrow night if sruby
doesn't beat me to it.

Documentation and tests for the subclass interface changes
are still needed as well.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&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-1506122 ] Add "compose" function to the functools

[SourceForge.net]

Feature Requests item #1506122, was opened at 2006-06-14 19:12
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=1506122&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add "compose" function to the functools

Initial Comment:
I think it would be very usefull to have something 
similar to Haskell's "dot" operator in Python, IMO it 
should be something like this (untested):

def compose(f, g):
return lambda *args, **kws: f(g(*args, **kws))

but C-coded. So, _functools can be a good place for it.

--
Regards, Gregory.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506122&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-1506171 ] Add "methodcaller" to the operator module

[SourceForge.net]

Feature Requests item #1506171, was opened at 2006-06-14 20:02
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=1506171&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add "methodcaller" to the operator module

Initial Comment:
I found that I (like Alex Martelli, http://mail.python.
org/pipermail/python-dev/2006-February/060341.html :-) 
am writing lambdas like "lambda x: x.do_smth(a,b,c)" a 
lot (often for filter/map functions). So, I think it 
would be great to have such a function implemented in 
C and placed in the standart library. Operator module 
can be a good place for it.

--
Regards, Gregory.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506171&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-1506190 ] Add "methodcaller" to the operator module

[SourceForge.net]

Feature Requests item #1506190, was opened at 2006-06-14 20:33
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=1506190&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add "methodcaller" to the operator module

Initial Comment:
I found that I (like Alex Martelli, http://mail.python.
org/pipermail/python-dev/2006-February/060341.html :-) 
am writing lambdas like "lambda x: x.do_smth(a,b,c)" a 
lot (often for filter/map functions). So, I think it 
would be great to have such a function implemented in 
C and placed in the standart library. Operator module 
can be a good place for it.

--
Regards, Gregory.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506190&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-805015 ] PyUnicode_FromEncodedObject

[SourceForge.net]

Bugs item #805015, was opened at 2003-09-12 11:39
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805015&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: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyUnicode_FromEncodedObject

Initial Comment:
There's a bug, either in the code or docs for
PyUnicode_FromEncodedObject.  The docs read:

  "Unicode objects are passed back as-is with 
incremented
  refcount. Note: These cannot be decoded; passing a 
non-NULL value
  for encoding will result in a TypeError."


'tain't so; the following shows that the error is 
unconditional.



if (obj == NULL) {
PyErr_BadInternalCall();
return NULL;
}

#if 0
/* For b/w compatibility we also accept Unicode 
objects provided
   that no encodings is given and then redirect to
   PyObject_Unicode() which then applies the 
additional logic for
   Unicode subclasses.

   NOTE: This API should really only be used for 
object which
 represent *encoded* Unicode !

*/
if (PyUnicode_Check(obj)) {
if (encoding) {
PyErr_SetString(PyExc_TypeError,
"decoding Unicode 
is not supported");
return NULL;
}
return PyObject_Unicode(obj);
}
#else
if (PyUnicode_Check(obj)) {
PyErr_SetString(PyExc_TypeError,
"decoding Unicode is not 
supported");
return NULL;
}
#endif


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-14 16:46

Message:
Logged In: YES 
user_id=849994

Fixed in rev. 46961.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805015&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1099364 ] raw_input() displays wrong unicode prompt

[SourceForge.net]

Bugs item #1099364, was opened at 2005-01-10 10:33
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099364&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.4
>Status: Closed
>Resolution: Wont Fix
Priority: 7
Submitted By: Petr Prikryl (prikryl)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw_input() displays wrong unicode prompt

Initial Comment:
I have observed a problem when running 
Python 2.4, Windows version (python-2.4.msi)
and using raw_input() with unicode prompt
string in a console program (ran in the DOS window).

I do use the following sitecustomize.py file to set
the default encoding in the English Windows 2000 Server:

sitecustomize.py
=
import sys
sys.setdefaultencoding('cp1250')
=


test.py
=
# -*- coding: cp1250 -*-
s = u'string with accented letters (different than this)'
print s# OK
val = raw_input(s)# s displayed differently (wrong)
=

See the test.png
(captured from screen) and the test.py for the
used string -- inside the attached zip file. 

The "type test.py" (result visible on the captured
screen) displays the string
definition also wrongly, because the DOS window
uses different encoding than cp1250. The print
command prints the string correctly, converting
the internal unicode string to the encoding that
the is defined by the output environment. However,
the raw_input() probably does convert the unicode
string to the cp1250 and does not do the same
(more clever) thing that the print does.

I did not use the unicode in older Python (2.3.4),
so I do not know what was the behaviour earlier.

Could you confirm the bug? Sorry if the bug
is well known.

Petr


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-14 16:49

Message:
Logged In: YES 
user_id=849994

Per python-dev discussion, this is still expected behavior
(and a wart).

--

Comment By: Petr Prikryl (prikryl)
Date: 2005-08-08 08:37

Message:
Logged In: YES 
user_id=771873

As the patch #1214889 that would have solved the problem 
on lower levels was rejected, the problem should be reopened 
and the raw_input() internals should be implemented similarly 
to print. 

Thanks, 
  Petr


--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-28 06:40

Message:
Logged In: YES 
user_id=1188172

You'll have to explicitly encode the unicode string using
raw_input(s.encode(sys.stdout.encoding)).

As said, this behaviour will change if the patch mentioned
is accepted.

--

Comment By: Petr Prikryl (prikryl)
Date: 2005-06-28 05:56

Message:
Logged In: YES 
user_id=771873

Should I understand it that there is no bug, but I do use it 
incorrectly? I cannot agree that this is expected behaviour. (I 
am not the only one who found this strange.) 

Of course, the sys.stdout.encoding is different for a DOS 
window (cp852) than the default encoding (cp1250). Windows 
simply behaves this way when working with DOS window 
(because of legacy DOS applications).

I do not complain on behaviour of sys.stdout.write() but on 
behaviour of raw_input(). The output of raw_input() prompt 
should be displayed the same way as the print diplays the 
results to the user. The raw_input() is used for building user 
interface. Its prompt should not be displayed differently in 
windows that use different encoding (i.e. DOS console vs. 
say IDLE console).

In other words, how should I use raw_input() to make it 
working correctly?

--

Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-26 20:34

Message:
Logged In: YES 
user_id=1188172

Actually, your sys.stdout.encoding is set to something
different than cp1250, which is why the result of DOS type
looks the same as the one of print.

This is because print observes sys.stdout.encoding, while
sys.stdout.write uses the system default encoding, which is,
as you set it, cp1250 and is displayed wrong on the console.

Closing this bug, as it is currently expected behaviour (but
will perhaps change when patch #1214889 is accepted).

--

Comment By: Petr Prikryl (prikryl)
Date: 2005-04-14 14:34

Message:
Logged In: YES 
user_id=771873

Python 2.4.1 for Windows behaves the same way.

Petr

--

Comment By: Petr Prikryl (

[ python-Feature Requests-1506190 ] Add "methodcaller" to the operator module

[SourceForge.net]

Feature Requests item #1506190, was opened at 2006-06-14 16:33
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506190&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: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add "methodcaller" to the operator module

Initial Comment:
I found that I (like Alex Martelli, http://mail.python.
org/pipermail/python-dev/2006-February/060341.html :-) 
am writing lambdas like "lambda x: x.do_smth(a,b,c)" a 
lot (often for filter/map functions). So, I think it 
would be great to have such a function implemented in 
C and placed in the standart library. Operator module 
can be a good place for it.

--
Regards, Gregory.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-14 16:55

Message:
Logged In: YES 
user_id=849994

Duplicate of #1506171.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506190&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-1506211 ] Add "methodcaller" to the operator module

[SourceForge.net]

Feature Requests item #1506211, was opened at 2006-06-14 21:03
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=1506211&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add "methodcaller" to the operator module

Initial Comment:
I found that I (like Alex Martelli, http://mail.python.
org/pipermail/python-dev/2006-February/060341.html :-) 
am writing lambdas like "lambda x: x.do_smth(a,b,c)" a 
lot (often for filter/map functions). So, I think it 
would be great to have such a function implemented in 
C and placed in the standart library. Operator module 
can be a good place for it.

--
Regards, Gregory.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506211&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-1506216 ] Add "methodcaller" to the operator module

[SourceForge.net]

Feature Requests item #1506216, was opened at 2006-06-14 21:15
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=1506216&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add "methodcaller" to the operator module

Initial Comment:
I found that I (like Alex Martelli, http://mail.python.
org/pipermail/python-dev/2006-February/060341.html :-) 
am writing lambdas like "lambda x: x.do_smth(a,b,c)" a 
lot (often for filter/map functions). So, I think it 
would be great to have such a function implemented in 
C and placed in the standart library. Operator module 
can be a good place for it.

--
Regards, Gregory.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506216&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-1506211 ] Add "methodcaller" to the operator module

[SourceForge.net]

Feature Requests item #1506211, was opened at 2006-06-14 17:03
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506211&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: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add "methodcaller" to the operator module

Initial Comment:
I found that I (like Alex Martelli, http://mail.python.
org/pipermail/python-dev/2006-February/060341.html :-) 
am writing lambdas like "lambda x: x.do_smth(a,b,c)" a 
lot (often for filter/map functions). So, I think it 
would be great to have such a function implemented in 
C and placed in the standart library. Operator module 
can be a good place for it.

--
Regards, Gregory.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-14 17:25

Message:
Logged In: YES 
user_id=849994

Se #1506171.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506211&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-1506216 ] Add "methodcaller" to the operator module

[SourceForge.net]

Feature Requests item #1506216, was opened at 2006-06-14 17:15
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506216&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: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add "methodcaller" to the operator module

Initial Comment:
I found that I (like Alex Martelli, http://mail.python.
org/pipermail/python-dev/2006-February/060341.html :-) 
am writing lambdas like "lambda x: x.do_smth(a,b,c)" a 
lot (often for filter/map functions). So, I think it 
would be great to have such a function implemented in 
C and placed in the standart library. Operator module 
can be a good place for it.

--
Regards, Gregory.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-14 17:26

Message:
Logged In: YES 
user_id=849994

See #1506171.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506216&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-1506296 ] Add some dicts to datetime module

[SourceForge.net]

Feature Requests item #1506296, was opened at 2006-06-14 23:35
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=1506296&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add some dicts to datetime module

Initial Comment:
I think it would be nice to have dicts like

weekdays = {0:'Monday', ...}
isoweekdays = {1:'Monday', ...}
months = {1:'January', ...}

in the datetime module. IMO they are rather usefull.

--
Regards, Gregory.



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506296&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-1506313 ] Add some dicts to datetime module

[SourceForge.net]

Feature Requests item #1506313, was opened at 2006-06-15 00:15
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=1506313&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add some dicts to datetime module

Initial Comment:
I think it would be nice to have dicts like

weekdays = {0:'Monday', ...}
isoweekdays = {1:'Monday', ...}
months = {1:'January', ...}

in the datetime module. IMO they are rather usefull.

--
Regards, Gregory.



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506313&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-1506324 ] Add some dicts to datetime module

[SourceForge.net]

Feature Requests item #1506324, was opened at 2006-06-15 00:45
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=1506324&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add some dicts to datetime module

Initial Comment:
I think it would be nice to have dicts like

weekdays = {0:'Monday', ...}
isoweekdays = {1:'Monday', ...}
months = {1:'January', ...}

in the datetime module. IMO they are rather usefull.

--
Regards, Gregory.



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506324&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-1506313 ] Add some dicts to datetime module

[SourceForge.net]

Feature Requests item #1506313, was opened at 2006-06-14 20:15
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506313&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: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add some dicts to datetime module

Initial Comment:
I think it would be nice to have dicts like

weekdays = {0:'Monday', ...}
isoweekdays = {1:'Monday', ...}
months = {1:'January', ...}

in the datetime module. IMO they are rather usefull.

--
Regards, Gregory.



--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-14 20:57

Message:
Logged In: YES 
user_id=849994

See #1506296.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506313&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-1506324 ] Add some dicts to datetime module

[SourceForge.net]

Feature Requests item #1506324, was opened at 2006-06-14 20:45
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506324&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: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add some dicts to datetime module

Initial Comment:
I think it would be nice to have dicts like

weekdays = {0:'Monday', ...}
isoweekdays = {1:'Monday', ...}
months = {1:'January', ...}

in the datetime module. IMO they are rather usefull.

--
Regards, Gregory.



--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-14 20:58

Message:
Logged In: YES 
user_id=849994

See #1506296.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506324&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-1506340 ] Add some dicts to datetime module

[SourceForge.net]

Feature Requests item #1506340, was opened at 2006-06-15 01:14
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=1506340&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add some dicts to datetime module

Initial Comment:
I think it would be nice to have dicts like

weekdays = {0:'Monday', ...}
isoweekdays = {1:'Monday', ...}
months = {1:'January', ...}

in the datetime module. IMO they are rather usefull.

--
Regards, Gregory.



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506340&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-1506340 ] Add some dicts to datetime module

[SourceForge.net]

Feature Requests item #1506340, was opened at 2006-06-15 01:14
Message generated for change (Comment added) made by gregory_p
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506340&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Petrosyan (gregory_p)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add some dicts to datetime module

Initial Comment:
I think it would be nice to have dicts like

weekdays = {0:'Monday', ...}
isoweekdays = {1:'Monday', ...}
months = {1:'January', ...}

in the datetime module. IMO they are rather usefull.

--
Regards, Gregory.



--

>Comment By: Gregory Petrosyan (gregory_p)
Date: 2006-06-15 01:18

Message:
Logged In: YES 
user_id=1405187

I am terribly sorry for that many duplicates of this and 
other tickets. This is a strange bug, i don't know why this 
had happened.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506340&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-516412 ] Python gettext doesn't support libglade

[SourceForge.net]

Bugs item #516412, was opened at 2002-02-12 16:01
Message generated for change (Comment added) made by nshmyrev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Christian Reis (kiko_async)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python gettext doesn't support libglade

Initial Comment:
Libglade is a library that parses XML and generates
GTK-based UIs in runtime. It is written in C and
supports a number of languages through bindings.

James Henstridge has maintained a set of bindings for
Python for some time now. These bindings work very
well, _except for internationalization_.

The reason seems now straightforward to me. Python's
gettext.py is a pure python implementation, and because
of it, bindtextdomain/textdomain are never called. This
causes any C module that uses gettext to not activate
the support, and not use translation because of it.

Using Martin's intl.so module things work great, but it
is a problem for us having to redistribute it with our
application. Any other suggestions to fix?

--

Comment By: Shmyrev Nick (nshmyrev)
Date: 2006-06-15 02:26

Message:
Logged In: YES 
user_id=598622

I am still seeing this with meld application

meld.sourceforge.net

Python 2.4.2 (#1, Feb 12 2006, 03:59:46)
[GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2

pygtk2-devel-2.8.4-1.1

--

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 21:53

Message:
Logged In: YES 
user_id=21627

This is fixed with

configure 1.291
configure.in 1.301
pyconfig.h.in 1.25
liblocale.tex 1.28
NEWS 1.369
_localemodule.c 2.29

Notice that applications that want to change the C library's
domain bindings will have to invoke locale.bindtextdomain; I
decided not to provide automatic forwarding from
gettext.bindtextdomain to locale.bindtextdomain, since the C
library and Python may have different message catalog
formats (e.g. on Solaris); this might confuse the C library.


--

Comment By: James Henstridge (jhenstridge)
Date: 2002-02-13 05:15

Message:
Logged In: YES 
user_id=146903

Some libraries (libglade in this case) translate some
messages on behalf of the application (libglade translates
messages in the input file using the default translation
domain, or some other domain specified by the programmer).

This is a case of wanting python's gettext module to
cooperate with the C level gettext library.

For libglade, this could be achieved by making the
gettext.bindtextdomain() and gettext.textdomain() calls to
call the equivalent C function in addition to what they do now.

For most messages in gtk+ itself, it will use dgettext() for
most messages already, so isn't a problem.  The exception to
this is places where it allows other libraries (or the app)
to register new stock items, which get translated with a
programmer specified domain.

As of gettext 0.10.40, there should be no license problems,
as the license for the libintl library was changed from GPL
to LGPL.

It should be a fairly simple to implement this; just needs a
patch :)


--

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-13 04:17

Message:
Logged In: YES 
user_id=21627

How does gtk invoke gettext? It sounds buggy in the respect
that it expects the textdomain to be set globally; a library
should not do that. Instead, the right thing (IMO) would be
if   gtk called dgettext, using an application-supplied
domain name. It would be then the matter of the Python gtk
wrapper to expose the GTK APIs for setting the text domain.

--

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-12 16:52

Message:
Logged In: NO 

If what you want is a way to call bindtextdomain/textdomain
from Python, feel free to supply a patch or ask martin to
add intl.so to the distribution.

--Guido (@#$% SF always logs me out :-( )

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-516412 ] Python gettext doesn't support libglade

[SourceForge.net]

Bugs item #516412, was opened at 2002-02-12 14:01
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Christian Reis (kiko_async)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python gettext doesn't support libglade

Initial Comment:
Libglade is a library that parses XML and generates
GTK-based UIs in runtime. It is written in C and
supports a number of languages through bindings.

James Henstridge has maintained a set of bindings for
Python for some time now. These bindings work very
well, _except for internationalization_.

The reason seems now straightforward to me. Python's
gettext.py is a pure python implementation, and because
of it, bindtextdomain/textdomain are never called. This
causes any C module that uses gettext to not activate
the support, and not use translation because of it.

Using Martin's intl.so module things work great, but it
is a problem for us having to redistribute it with our
application. Any other suggestions to fix?

--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-06-15 08:03

Message:
Logged In: YES 
user_id=21627

Please don't add messages to a bug report that was closed
four years ago. Add a new bug report, explaining your
problem. Please be precise in stating what "this" is that
you are seeing.

--

Comment By: Shmyrev Nick (nshmyrev)
Date: 2006-06-15 00:26

Message:
Logged In: YES 
user_id=598622

I am still seeing this with meld application

meld.sourceforge.net

Python 2.4.2 (#1, Feb 12 2006, 03:59:46)
[GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2

pygtk2-devel-2.8.4-1.1

--

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:53

Message:
Logged In: YES 
user_id=21627

This is fixed with

configure 1.291
configure.in 1.301
pyconfig.h.in 1.25
liblocale.tex 1.28
NEWS 1.369
_localemodule.c 2.29

Notice that applications that want to change the C library's
domain bindings will have to invoke locale.bindtextdomain; I
decided not to provide automatic forwarding from
gettext.bindtextdomain to locale.bindtextdomain, since the C
library and Python may have different message catalog
formats (e.g. on Solaris); this might confuse the C library.


--

Comment By: James Henstridge (jhenstridge)
Date: 2002-02-13 03:15

Message:
Logged In: YES 
user_id=146903

Some libraries (libglade in this case) translate some
messages on behalf of the application (libglade translates
messages in the input file using the default translation
domain, or some other domain specified by the programmer).

This is a case of wanting python's gettext module to
cooperate with the C level gettext library.

For libglade, this could be achieved by making the
gettext.bindtextdomain() and gettext.textdomain() calls to
call the equivalent C function in addition to what they do now.

For most messages in gtk+ itself, it will use dgettext() for
most messages already, so isn't a problem.  The exception to
this is places where it allows other libraries (or the app)
to register new stock items, which get translated with a
programmer specified domain.

As of gettext 0.10.40, there should be no license problems,
as the license for the libintl library was changed from GPL
to LGPL.

It should be a fairly simple to implement this; just needs a
patch :)


--

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-13 02:17

Message:
Logged In: YES 
user_id=21627

How does gtk invoke gettext? It sounds buggy in the respect
that it expects the textdomain to be set globally; a library
should not do that. Instead, the right thing (IMO) would be
if   gtk called dgettext, using an application-supplied
domain name. It would be then the matter of the Python gtk
wrapper to expose the GTK APIs for setting the text domain.

--

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-12 14:52

Message:
Logged In: NO 

If what you want is a way to call bindtextdomain/textdomain
from Python, feel free to supply a patch or ask martin to
add intl.so to the distribution.

--Guido (@#$% SF always logs me out :-( )

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&group_id=5470
___
Python-bug