[ python-Bugs-1481650 ] Docs on import of email.MIMExxx classes wrong
Bugs item #1481650, was opened at 2006-05-04 07:24 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=1481650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hugh Gibson (hgibson50) Assigned to: Nobody/Anonymous (nobody) Summary: Docs on import of email.MIMExxx classes wrong Initial Comment: http://docs.python.org/lib/node588.html says: -- Each of these classes should be imported from a module with the same name as the class, from within the email package. E.g.: import email.MIMEImage.MIMEImage or from email.MIMEText import MIMEText -- However, here is a Python IDLE session showing that the first import format doesn't work: -- Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.1.3 >>> import email.MIMEImage.MIMEImage Traceback (most recent call last): File "", line 1, in -toplevel- import email.MIMEImage.MIMEImage ImportError: No module named MIMEImage >>> -- This method *does* work: -- >>> import email.MIMEImage >>> -- This got one of my inexperienced programmers tied up in knots! Hugh -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481650&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1417699 ] float/atof have become locale aware
Bugs item #1417699, was opened at 2006-01-29 01:04
Message generated for change (Comment added) made by gustavo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Martin v. Löwis (loewis)
Summary: float/atof have become locale aware
Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:
Python 2.4.2 (#1, Nov 29 2005, 16:07:55)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5
This doesn't match what's specified in pep 331:
- float() and str() stay locale-unaware.
It also doesn't match the documentation for atof:
Convert a string to a floating point number.
The string must have the standard syntax for a
floating point literal in Python, optionally
preceded by a sign ("+" or "-"). Note that this
behaves identical to the built-in function float()
when passed a string.
The documentation for float() doesn't state which
format is accepted by float(), though.
The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:
This function behaves like the standard strtod()
function does in the C locale.
--
Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-04 10:47
Message:
Logged In: YES
user_id=908
My comment is, is "PyOS_ascii_strtod accepting both forms"
something that is harmful and should be fixed?
I didn't exactly write the PyOS_ascii_strtod code; I only
integrated it with Python. But if we really need to fix
this, I'll try to figure out how to make it not accept
floating points in locale aware format; if necessary I'll
ask help from the original author of the code, Alexander
Larsson.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-05-04 05:42
Message:
Logged In: YES
user_id=21627
It's a bug. As bernhard says, it originates from
PyOS_ascii_strtod accepting both forms, which in turn
happens because it just leaves the locale-specific decimal
point in the string, only replacing the . with the
locale-specific point. Then, the platform's strtod will
happily accept the locale-specific version.
I'd like Gustavo Carneiro to comment.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 12:19
Message:
Logged In: YES
user_id=1188172
Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1481650 ] Docs on import of email.MIMExxx classes wrong
Bugs item #1481650, was opened at 2006-05-04 03:24 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hugh Gibson (hgibson50) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Docs on import of email.MIMExxx classes wrong Initial Comment: http://docs.python.org/lib/node588.html says: -- Each of these classes should be imported from a module with the same name as the class, from within the email package. E.g.: import email.MIMEImage.MIMEImage or from email.MIMEText import MIMEText -- However, here is a Python IDLE session showing that the first import format doesn't work: -- Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.1.3 >>> import email.MIMEImage.MIMEImage Traceback (most recent call last): File "", line 1, in -toplevel- import email.MIMEImage.MIMEImage ImportError: No module named MIMEImage >>> -- This method *does* work: -- >>> import email.MIMEImage >>> -- This got one of my inexperienced programmers tied up in knots! Hugh -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481650&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1481770 ] hpux ia64 shared lib ext should be ".so"
Bugs item #1481770, was opened at 2006-05-04 05:43 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=1481770&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: Open Resolution: None Priority: 5 Submitted By: David Everly (deckrider) Assigned to: Nobody/Anonymous (nobody) Summary: hpux ia64 shared lib ext should be ".so" Initial Comment: On hpux ia64, the shared library extension should be ".so". This is currently problematic in that other add-on python modules (such as those for subversion) correctly detect the host_os/host_cpu and build _module.so, which is not seen by python built using ".sl". According to http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac "Shared library names Since dynamic linking APIs operate on shared libraries, it is also important to note that the shared library naming scheme on Linux is lib*.so; whereas, on HP-UX 11i Version 1.5 the naming scheme is lib*.sl for PA and lib*.so on IPF. Also APIs may reside in different libraries files on Linux and HP-UX, so you may need to dynamically load a different shared library name on HP-UX and Linux." To translate this quote, PA=hppa and IPF=ia64. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&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-1110010 ] 'attrmap' function, attrmap(x)['attname'] == x.attname
Feature Requests item #1110010, was opened at 2005-01-26 11:28
Message generated for change (Comment added) made by gregsmith
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&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 Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname
Initial Comment:
One of the side effects of the new-style classes is that
objects don't necessarily have __dict__ attached to them.
It used to be possible to write things like
def __str__(self):
return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % self.__dict__
... but this doesn't work if the class doesn't have a
__dict__. Even if does, I'm not sure it will always get
members from base classes.
There is a 'vars' function; you could put 'vars(self)'
in the above instead of self.__dict__, but it still
doesn't work if
the class doesn't have a __dict__.
I can see different solutions for this:
(1) change the 'string %' operator so that it allows
%(.name)s, leading to a getattr() on the right-side
argument
rather than a getitem.
return "Node %(.name)s, %(.nlinks)d links,
active: %(.active)s" % self
(2) Make a builtin like vars, but which works when the
object doesn't have a __dict__ I.e. attrmap(x) would
return a mapping which is bound to x, and reading
attrmap(x)['attname'] is the same as
getattr(x,'attname'). Thus
return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % attrmap(self)
This attrmap() function can be implemented in pure
python, of course.
I originally thought (1) made a lot of sense, but (2) seems
to work just as well and doesn't require changing much.
Also, (1) allows cases like "%(name)s %(.name2)s",
which are not very useful, but are very likely to be
created by
accident; whereas in (2) you are deciding on the right
of the '%' whether you are naming attributes or
providing mapping keys.
I'm not sure it's a good idea change 'vars' to have
this behaviour, since vars(x).keys() currently works in
a predictable way when vars(x) works; whereas
attrmap(x).keys() may not be complete, or possible,
even when attrmap(x) is useful. I.e. when x has a
__getattr__ defined.
On the other hand, vars(x) doesn't currently do much at
all, so maybe it's possible to enhance it like this
without breaking anything.
The motivation for this came from the "%(name)s" issue,
but the attrmap() function would be useful in other
places e.g.
processdata( infile, outfile, **attrmap(options))
... where options might be obtained from optparse, e.g.
Or, an attrmap can be used with the new Templates:
string.Template('Node $name').substitute( attrmap(node))
Both of these examples will work with vars(), but only
when the object actually has __dict__. This is why
I'm thinking it may make sense to enhance vars: some
code may be broken by the change; but other code,
broken by new-style classes, may be unbroken by this
change.
The proxy could be writable, so that
attrmap(x)['a'] = y
is the same as
x.a = y
.. which could have more uses.
A possible useful (possibly weird) variation: attrmap
accepts 1 or more parameters, and the resulting
proxy is bound to all of them. when attrmap(x,y,z)['a']
is done, the proxy will try x.a, y.a, z.a until one of
them doesn't raise AttributeError. So it's equivalent
to merging dictionaries. This would be useful
in the %(name)s or Template cases, where you want
information from several objects.
--
>Comment By: Gregory Smith (gregsmith)
Date: 2006-05-04 11:19
Message:
Logged In: YES
user_id=292741
Josiah, I'm well aware of that, but as I said 10/26 I don't
want to add attribute mapping to a whole set of classes just
so they will all work a certain way in one specific
situation; I want a separate adapter so I can have attribute
mapping for ANY object in that specific situation. I can't
mixin a new base class into every class I might encounter,
since most of them are not under my control; but all of them
have an attribute interface and will all work with attrmap.
There's no reason to mess things up like that when
I can implement attrmap already (and have done) -- and you
have shown how short the code is on your 6/26/'05 post --
I'm just suggesting this is simple, elegant, and generally
useful enough to be included as a standard python gizmo.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-10-27 02:16
Message:
Logged In: YES
user_id=341410
gregsmith:
class attrmap:
def __getitem__(self, key):
return getattr(self, key)
Use that as a mixin
[ python-Bugs-1482122 ] Shift+Backspace exhibits odd behavior
Bugs item #1482122, was opened at 2006-05-04 13:48 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=1482122&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: None Status: Open Resolution: None Priority: 5 Submitted By: NothingCanFulfill (ncf) Assigned to: Nobody/Anonymous (nobody) Summary: Shift+Backspace exhibits odd behavior Initial Comment: On Windows, pressing Shift+Backspace while in an editor window will act just like a regular Backspace will, however under Linux (Gentoo 2006.0 and Slackware-current), instead of deleting the caracter before the cursor, it inserts "^B". Correct me if I'm wrong, but I don't think it'd be too hard to fix this little annoyance. (I would do it myself, but I'm not at all familiar with IDLE's source layout) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482122&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-1110010 ] 'attrmap' function, attrmap(x)['attname'] == x.attname
Feature Requests item #1110010, was opened at 2005-01-26 08:28
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&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 Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname
Initial Comment:
One of the side effects of the new-style classes is that
objects don't necessarily have __dict__ attached to them.
It used to be possible to write things like
def __str__(self):
return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % self.__dict__
... but this doesn't work if the class doesn't have a
__dict__. Even if does, I'm not sure it will always get
members from base classes.
There is a 'vars' function; you could put 'vars(self)'
in the above instead of self.__dict__, but it still
doesn't work if
the class doesn't have a __dict__.
I can see different solutions for this:
(1) change the 'string %' operator so that it allows
%(.name)s, leading to a getattr() on the right-side
argument
rather than a getitem.
return "Node %(.name)s, %(.nlinks)d links,
active: %(.active)s" % self
(2) Make a builtin like vars, but which works when the
object doesn't have a __dict__ I.e. attrmap(x) would
return a mapping which is bound to x, and reading
attrmap(x)['attname'] is the same as
getattr(x,'attname'). Thus
return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % attrmap(self)
This attrmap() function can be implemented in pure
python, of course.
I originally thought (1) made a lot of sense, but (2) seems
to work just as well and doesn't require changing much.
Also, (1) allows cases like "%(name)s %(.name2)s",
which are not very useful, but are very likely to be
created by
accident; whereas in (2) you are deciding on the right
of the '%' whether you are naming attributes or
providing mapping keys.
I'm not sure it's a good idea change 'vars' to have
this behaviour, since vars(x).keys() currently works in
a predictable way when vars(x) works; whereas
attrmap(x).keys() may not be complete, or possible,
even when attrmap(x) is useful. I.e. when x has a
__getattr__ defined.
On the other hand, vars(x) doesn't currently do much at
all, so maybe it's possible to enhance it like this
without breaking anything.
The motivation for this came from the "%(name)s" issue,
but the attrmap() function would be useful in other
places e.g.
processdata( infile, outfile, **attrmap(options))
... where options might be obtained from optparse, e.g.
Or, an attrmap can be used with the new Templates:
string.Template('Node $name').substitute( attrmap(node))
Both of these examples will work with vars(), but only
when the object actually has __dict__. This is why
I'm thinking it may make sense to enhance vars: some
code may be broken by the change; but other code,
broken by new-style classes, may be unbroken by this
change.
The proxy could be writable, so that
attrmap(x)['a'] = y
is the same as
x.a = y
.. which could have more uses.
A possible useful (possibly weird) variation: attrmap
accepts 1 or more parameters, and the resulting
proxy is bound to all of them. when attrmap(x,y,z)['a']
is done, the proxy will try x.a, y.a, z.a until one of
them doesn't raise AttributeError. So it's equivalent
to merging dictionaries. This would be useful
in the %(name)s or Template cases, where you want
information from several objects.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-04 23:28
Message:
Logged In: YES
user_id=341410
As I and others have expressed perhaps hundreds of times
over the last few years; not all X line functions/classes
should be built into Python. This particular object doesn't
have enough general usefulness to make it into Python as a
builtin, so you would need to import something anyways.
If you are going to need to import to get at it, you may as
well put this somewhere, and perhaps monkey-patch
__builtins__ yourself so that you can get at it everywhere
without importing it. Heck, you could even put it into
site.py .
If this were going to make it into Python, I would suggest
it go into the operator module, where a similar feature
already exists in the operator.attrgetter. If there is also
desire, one may want to offer mapattr class which does
x.attr -> x['attr'] .
All in all, I'm -0; it would be useful, but I believe most
people would just write the 5-liner and call it good.
--
Comment By: Gregory Smith (gregsmith)
Date: 2006-05-04 08:19
Message:
Logged
