[ python-Bugs-1453145 ] Unexpected module reloading
Bugs item #1453145, was opened at 2006-03-18 14:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453145&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: Invalid Priority: 5 Submitted By: Ali Gholami Rudi (aligrudi) Assigned to: Nobody/Anonymous (nobody) Summary: Unexpected module reloading Initial Comment: I'll demonstrate the problem: Consider the following package hierarchy: p/ __all__.py m1.py m2.py The contents of m1 and m2 modules are: -m1.py import m2 import p.m2 -- -m2.py print 'Loading m2 module' -- Running the m1 module would yield the output Loading m2 module Loading m2 module . As it is obvious from the output the module m2 is loaded twice. The problem arrises when you want to do things such as implementing a singleton class: -Alternate m2.py- class Singleton(object): _instance = None @staticmethod def getInstance(): if Singleton._instance is None: Singleton._instance = Singleton() return _instace - -Alternate m1.py- import m2 import p.m2 print m2.Singleton.getInstance() print p.m2.Singleton.getInstance() - If you run m1 module, the output shows that the two instaces are not the same objects. That is m2.Singleton and p.m2.Singleton are not the same classes. I think this is a bug. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-03-19 11:44 Message: Logged In: YES user_id=21627 At first, I could reproduce the problem; look at this transcript to see what I did. [EMAIL PROTECTED]:~/tmp$ mkdir p [EMAIL PROTECTED]:~/tmp$ echo >p/__init__.py [EMAIL PROTECTED]:~/tmp$ cat >p/m1.py import m2 import p.m2 [EMAIL PROTECTED]:~/tmp$ cat >p/m2.py print 'Loading m2 module' [EMAIL PROTECTED]:~/tmp$ python Python 2.3.5 (#2, Mar 6 2006, 10:12:24) [GCC 4.0.3 20060304 (prerelease) (Debian 4.0.2-10)] on linux2 Type "help", "copyright", "credits" or "license" for more information. py> import p.m1 Loading m2 module py> As you can see, the "Loading" output is printed only once. This might happen if you run p/m1.py as the main program, but I cannot reproduce it: [EMAIL PROTECTED]:~/tmp$ python p/m1.py Loading m2 module Traceback (most recent call last): File "p/m1.py", line 2, in ? import p.m2 ImportError: No module named p.m2 As the current directory is not on sys.path, it won't find the package p. Now, if you also change that (e.g. by setting PYTHONPATH), I get [EMAIL PROTECTED]:~/tmp$ export PYTHONPATH=`pwd` [EMAIL PROTECTED]:~/tmp$ python p/m1.py Loading m2 module Loading m2 module This is not a bug: Now *both* the current directory, and the directory ~/tmp/p are on sys.path (print sys.path inside m1 to see what I mean). When you do "import m2", it searches for a module named m2 on sys.path, and it finds p/m2.py. When you then import p.m2, it searches for a package p on sys.path, finds the package, and then imports the module m2. It happens that both modules have the same source file - yet they are different modules. If you change the print statement to print 'Loading', __name__, 'module' you get Loading m2 module Loading p.m2 module So in short: this is not a bug. Don't try running a module in a package as the main program. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453145&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451503 ] os.startfile() still doesn't work with Unicode filenames
Bugs item #1451503, was opened at 2006-03-16 19:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&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 Submitted By: roee88 (roee88) Assigned to: Nobody/Anonymous (nobody) Summary: os.startfile() still doesn't work with Unicode filenames Initial Comment: >From 2.4.2 changelog: >>>Bug #1007046: os.startfile() did not accept unicode strings encoded in the file system encoding. If the filename is unicode type and the encoding isn't the default system encoding, all "unknown" (to system encoding) characters are replaced by "?". This is causing the os.startfile() to fail with WindowsError: [Errno2] Because the filename doesn't really have the "?". -- >Comment By: Martin v. Löwis (loewis) Date: 2006-03-19 11:49 Message: Logged In: YES user_id=21627 Well, it does work on Unicode strings when all characters from the string come from the system code page; this got implemented in response to bug #1007046. To fix this, the implementation should use ShellExecuteW (except on Win9x). Would you like to work on a patch? As a work-around, change your system code page so your file names are supported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1453570 ] try-except-finally in the tutorial
Bugs item #1453570, was opened at 2006-03-19 04:36 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453570&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: try-except-finally in the tutorial Initial Comment: Doc/tut/tut.tex describes "finally" statement as :: A try statement must either have one or more except clauses or one finally clause, but not both ... But now that PEP 341[*] has been accepted and merged, this part needs a rewrite. Adding a new section or an example using try-except- (else-)finally will be required. * http://www.python.org/peps/pep-0341.html -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-19 11:21 Message: Logged In: YES user_id=849994 I updated that section. try-except-finally should be made clear now. [rev. 43142] Thanks for spotting! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453570&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1453579 ] conditional expression documentation missing/incorrect
Bugs item #1453579, was opened at 2006-03-19 05:06 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453579&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: conditional expression documentation missing/incorrect Initial Comment: PEP 308 http://www.python.org/doc/peps/pep-0308/ says Python 2.5 will add a conditional expression. The Programming FAQ is as a result now wrong: http://www.python.org/doc/faq/programming/#is-there-an-equivalent-of-c-s-ternary-operator Also I do not see mention of this on the What's New page, especially http://www.python.org/dev/doc/devel/whatsnew/node5.html where it seems naturally to belong. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-19 11:24 Message: Logged In: YES user_id=849994 The new up-to-date devel docs are at http://docs.python.org/dev/. In the whatsnew there, PEP308 is included. I've sent a mail to [EMAIL PROTECTED] about the programming FAQ. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1453579&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448060 ] gettext.py breaks on plural-forms header (PATCH)
Bugs item #1448060, was opened at 2006-03-12 00:20
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&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: 5
Submitted By: Danilo Segan (dsegan)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py breaks on plural-forms header (PATCH)
Initial Comment:
See http://bugzilla.gnome.org/show_bug.cgi?id=334256
The problem is a PO file like the following:
test.po:
msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"#-#-#-#-# plo.po (PACKAGE VERSION) #-#-#-#-#\n"
(these kinds of entries are sometimes inserted by
msgmerge, so they're somewhat common)
Any Python program trying to access this breaks:
$ python test.py
Traceback (most recent call last):
File "test.py", line 7, in ?
gt = gettext.GNUTranslations(file)
File "/usr/lib/python2.4/gettext.py", line 177, in
__init__
self._parse(fp)
File "/usr/lib/python2.4/gettext.py", line 300, in _parse
v = v.split(';')
AttributeError: 'list' object has no attribute 'split'
test.py is simple:
#!/usr/bin/env python
import gettext
file = open("test.mo", "rb")
if file:
gt = gettext.GNUTranslations(file)
The problem is the corner-case: plural-forms precedes
this kind of comment, so "v" is split (v=v.split(";")).
In the next instance, lastk is "plural-forms", yet the
entry doesn't contain ":", so it tries to set plural
forms to v.split(";") again, which fails since v is
already a list.
The attached simple patch fixes this.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-03-19 12:51
Message:
Logged In: YES
user_id=21627
Several things seem to be going on here:
1. gettext.py is clearly wrong; it shouldn't break on that file.
2. it is trying to process multi-line fields here. So the
patch is also wrong, as it just sets k and v to None.
3. I believe that the PO file presented is also wrong. I
believe the intention of the header is that it should have
the RFC822 style syntax, which doesn't allow for # comment
lines. The tool should use a syntax like
X-Filename: plo.po; package=PACKAGE; version=VERSION;
To summarize, I think the attempt to process multi-line
fields in the header is misguided, and gettext.py should
just fetch the first line of content-type and plural-forms.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448640 ] datetime.__init__ cannot be overridden
Bugs item #1448640, was opened at 2006-03-13 04:54 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448640&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: Invalid Priority: 5 Submitted By: Martin Blais (blais) Assigned to: Michael Hudson (mwh) Summary: datetime.__init__ cannot be overridden Initial Comment: Hi The following code does not work properly: #!/usr/bin/env python """ Test overriding constructor of datetime classes. """ import sys, datetime class MyDate(datetime.date): def __init__( self, year, month, day ): print >> sys.stderr, 'lose data' d = MyDate(2006, 11, 29) print d class MyDate(datetime.date): def __new__( self, year, month, day ): print 'lose data' def __init__( self, year, month, day ): print 'lose data again' d = MyDate(2006, 11, 29) print d The output is: lose data 2006-11-29 lose data None The problem is that the initialization of the object is done in its time_new() method which is registered for __new__ rather than using an __init__ method. This prevent one from overriding the date/datetime/time constructors. cheers, -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-19 12:25 Message: Logged In: YES user_id=849994 blais: your mistake was that you didn't call datetime.date.__new__() in your overridden __new__() and did return None from __new__ whereas __new__ must return a new object of type MyDate. -- Comment By: Martin Blais (blais) Date: 2006-03-13 21:45 Message: Logged In: YES user_id=10996 H... that's not quite true. If I derive from datetime in order to add new data members (e.g. in my case I add "seq" which is used as a sequence number on top of datetime for storing the names of photographs, the sequence number is in case I have a panorama or multiple photographs in burst mode--all within one second), I might want a different constructor. I tried overriding __new__ and had some troubles, cannot remember what exactly, will reproduce and send code soon. -- Comment By: Michael Hudson (mwh) Date: 2006-03-13 16:42 Message: Logged In: YES user_id=6656 datetime.date objects are immutable, so this is the same as not being able to override __init__ in a subclass of int. Override __new__ instead. -- Comment By: splitscreen (splitscreen) Date: 2006-03-13 15:40 Message: Logged In: YES user_id=1126061 Isn't this an abuse of __new__ ? Taken from the documentation: "__new__ must return an object. There's nothing that requires that it return a new object that is an instance of its class argument, although that is the convention. If you return an existing object, the constructor call will still call its __init__ method. If you return an object of a different class, its __init__ method will be called. If you forget to return something, Python will unhelpfully return None, and your caller will probably be very confused." So, you're actually calling __init__ with None? Or have i misunderstood? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448640&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448042 ] Defining a class with __dict__ brakes attributes assignment
Bugs item #1448042, was opened at 2006-03-11 23:49
Message generated for change (Comment added) made by zseil
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&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: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defining a class with __dict__ brakes attributes assignment
Initial Comment:
When defining a class with __dict__ attribute, its
instances can't rebind their __dict__ attributes.
--
class C(object): __dict__ = {}
obj = C()
obj.a = object()
import gc
gc.get_referrers(obj.a) # => [{'a': }]
obj.__dict__ = {} # doesn't really bind new __dict__
vars(obj) # => {}
object.__getattribute__(obj, '__dict__') # => {}
object.__getattribute__(C, '__dict__') # => {..., but
without "a"}
obj.a # => (no exception
!)
gc.get_referrers(obj.a) # => [{'a': , '__dict__': {}}]
--
Although neither class nor object has an attribute "a",
it's still accessible. It's also not possible to rebind
__dict__ in that object, as it gets inside real object
attributes dictionary.
This behaviour has been tested on Python 2.2, 2.3 and
2.4, but may as well affect earlier versions.
--
Comment By: iga Seilnacht (zseil)
Date: 2006-03-19 14:50
Message:
Logged In: YES
user_id=1326842
Maybe this shows that it is actually a feature?
>>> class C(object):
... pass
...
'__dict__' is not a normal attribute, it's a descriptor
(a "getset_descriptor") generated by object's type.
You can get to this object if you try hard enough:
>>> C_dict_descriptor = C.__dict__['__dict__']
>>> type(C_dict_descriptor).__name__
'getset_descriptor'
This descriptor is automatically created for most of the
python classes (except for those, that have __slots__
without __dict__) by 'type' object.
Since 'type' is an instance of itself, it also has it:
>>> type_dict_descriptor = type.__dict__['__dict__']
And we can see, that it is responsible for creating
the C's __dict__ attribute:
>>> C.__dict__ == type_dict_descriptor.__get__(C, type)
True
As is normal for most of the special named attributes,
this one is looked up in object's type, not in its dict,
and it isn't a normal dict, but a dictproxy:
>>> type(C.__dict__).__name__
'dictproxy'
Now in your case, you create a class attribute '__dict__':
>>> class D(C):
... __dict__ = {'a': 1}
...
Which basically does something like:
>>> name = 'E'
>>> bases = (C,)
>>> E_namespace = {
... '__dict__': {'a': 1},
... '__doc__': "set to None by type if not provided",
... '__module__': "globals()['__name__'] if missing",
... '__weakref__': "another descriptor",
... }
>>> E = type(name, bases, E_namespace)
The '__dict__' attribute of this class is still provided by
its type (type 'type'), and is basicaly just a dictproxy of
the E_namespace:
>>> type(E.__dict__).__name__
'dictproxy'
>>> E.__dict__ == E_namespace
True
What your class definition actually did, is it has
overwritten the __dict__ descriptor that would be
normaly created by type; compare:
>>> C.__dict__['__dict__']
>>> E.__dict__['__dict__']
{'a': 1}
Now watch what happens if you create an instance of E class:
>>> e = E()
>>> e.__dict__
{'a': 1}
>>> e.a = 2
>>> e.__dict__
{'a': 1}
Basically, now the '__dict__' attribute is a normal
attribute, that behaves just as any other attribute,
while you have lost acces to the instance's inner dict:
>>> e.__dict__ = {}
>>> e.__dict__
{}
>>> e.a
2
If you inherit directly from object, which doesn't have
this descriptor:
>>> object.__dict__['__dict__']
Traceback (most recent call last):
File "", line 1, in ?
KeyError: '__dict__'
there would be no way of accesing instance's dictinary.
But since we inherited from class C, we can stil acces it:
>>> C_dict_descriptor.__get__(e)
{'a': 2, '__dict__': {}}
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 18:57
Message:
Logged In: YES
user_id=849994
Reopening. This is a bug, confirmed by Alex Martelli.
--
Comment By: Michal Kwiatkowski (rubyjoker)
Date: 2006-03-18 14:01
Message:
Logged In: YES
user_id=1310227
To see an example of rebinding __dict__ usage, go to:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/
66531
It's Alex Martelli implementation of Borg design pattern.
If rebinding __dict__ is forbidden, it should be clearly
noted in the documetation. Either way, it's a bug.
--
Comment
[ python-Feature Requests-1453973 ] addheaders for urlopen / open / xxxx_open
Feature Requests item #1453973, was opened at 2006-03-19 19:55
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=1453973&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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: addheaders for urlopen / open / _open
Initial Comment:
Adding a header also for each open call is a frequent
need for me (much more than e.g. proxies per call in
urllib1/urlopen).
For example:
urlopen(url,data,addheaders=[('Referer':lasturl)])
So far one is forced to set the _complete_ re-rendered
bunch of opener.addheaders each time (and to maintain a
separate opener for each thread )
open/OpenerDirector.open maybe should distribute
*args,**kwargs
---
Note on disciplined use of protocol modules in urllib2
( see also #1046077 ):
urllib2 still draws in all kind of (future?) protocol
modules all in advance => slows down app startup / cgi
script's ...; ugly non-pythonic/non-modular; unused
prots cannot be excluded for cx_Freeze,setup ...
Now the fat cookielib was also added in that manner.
Thus, when you use urllib2 for "ftp://xy";, you load
also all kind of fun (down to things like
_MozillaCookieJar) into Python.
The need for those imports is very local (search e.g.
"ftplib."). ==> local import in those few places.
I saw, this jam style already encouraged more
undisciplined dependencies like :
"origin_req_host = cookielib.request_host(self)"
(~urllib2-py2.4/line 191) in the general Request.__init__
Robert
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453973&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448060 ] gettext.py breaks on plural-forms header (PATCH)
Bugs item #1448060, was opened at 2006-03-12 00:20
Message generated for change (Comment added) made by dsegan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&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: 5
Submitted By: Danilo Segan (dsegan)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py breaks on plural-forms header (PATCH)
Initial Comment:
See http://bugzilla.gnome.org/show_bug.cgi?id=334256
The problem is a PO file like the following:
test.po:
msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"#-#-#-#-# plo.po (PACKAGE VERSION) #-#-#-#-#\n"
(these kinds of entries are sometimes inserted by
msgmerge, so they're somewhat common)
Any Python program trying to access this breaks:
$ python test.py
Traceback (most recent call last):
File "test.py", line 7, in ?
gt = gettext.GNUTranslations(file)
File "/usr/lib/python2.4/gettext.py", line 177, in
__init__
self._parse(fp)
File "/usr/lib/python2.4/gettext.py", line 300, in _parse
v = v.split(';')
AttributeError: 'list' object has no attribute 'split'
test.py is simple:
#!/usr/bin/env python
import gettext
file = open("test.mo", "rb")
if file:
gt = gettext.GNUTranslations(file)
The problem is the corner-case: plural-forms precedes
this kind of comment, so "v" is split (v=v.split(";")).
In the next instance, lastk is "plural-forms", yet the
entry doesn't contain ":", so it tries to set plural
forms to v.split(";") again, which fails since v is
already a list.
The attached simple patch fixes this.
--
>Comment By: Danilo Segan (dsegan)
Date: 2006-03-20 05:07
Message:
Logged In: YES
user_id=219596
Agreed on all points, except the "summary": multi-line
plural forms are actually supported and widely used.
Anyway, gettext.py should fail gracefully in case of any
problem in the header, instead of running into exception.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-03-19 12:51
Message:
Logged In: YES
user_id=21627
Several things seem to be going on here:
1. gettext.py is clearly wrong; it shouldn't break on that file.
2. it is trying to process multi-line fields here. So the
patch is also wrong, as it just sets k and v to None.
3. I believe that the PO file presented is also wrong. I
believe the intention of the header is that it should have
the RFC822 style syntax, which doesn't allow for # comment
lines. The tool should use a syntax like
X-Filename: plo.po; package=PACKAGE; version=VERSION;
To summarize, I think the attempt to process multi-line
fields in the header is misguided, and gettext.py should
just fetch the first line of content-type and plural-forms.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1454227 ] makesetup fails to tolerate valid linker options
Bugs item #1454227, was opened at 2006-03-20 00:11 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=1454227&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: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Blaine (jblaine) Assigned to: Nobody/Anonymous (nobody) Summary: makesetup fails to tolerate valid linker options Initial Comment: Using something like the following (in Setup.local) will generate 'bad word' when makesetup runs: -L/whatever -Xlinker -rpath /whatever The '/whatever' after -rpath is the bad word, yet it is completely valid syntax. I have to edit makesetup to get it to tolerate library directories and add them to $libs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454227&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1454285 ] test_parsedate_acceptable_to_time_functions+DST == :-(
Bugs item #1454285, was opened at 2006-03-20 18:47 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=1454285&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 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Barry A. Warsaw (bwarsaw) Summary: test_parsedate_acceptable_to_time_functions+DST == :-( Initial Comment: TZ=UTC ./python ./Lib/test/test_email.py works fine. But "TZ=Australia/Melbourne ./python ./Lib/test/test_email.py" breaks - the date used in this test (5 Feb 2003) is during daylight savings time here. It's unclear to me what the test is trying to do, so assigning to Barry to look at. FAILED (failures=1) Traceback (most recent call last): File "./Lib/test/test_email.py", line 13, in test_main() File "./Lib/test/test_email.py", line 10, in test_main run_suite(suite()) File "/home/anthony/src/py/pytrunk/python/Lib/test/test_support.py", line 285, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/home/anthony/src/py/pytrunk/python/Lib/email/test/test_email.py", line 2127, in test_parsedate_acceptable_to_time_functions eq(time.localtime(t)[:6], timetup[:6]) AssertionError: (2003, 2, 5, 14, 47, 26) != (2003, 2, 5, 13, 47, 26) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454285&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448060 ] gettext.py breaks on plural-forms header (PATCH)
Bugs item #1448060, was opened at 2006-03-12 00:20
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&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: 5
Submitted By: Danilo Segan (dsegan)
Assigned to: Nobody/Anonymous (nobody)
Summary: gettext.py breaks on plural-forms header (PATCH)
Initial Comment:
See http://bugzilla.gnome.org/show_bug.cgi?id=334256
The problem is a PO file like the following:
test.po:
msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"#-#-#-#-# plo.po (PACKAGE VERSION) #-#-#-#-#\n"
(these kinds of entries are sometimes inserted by
msgmerge, so they're somewhat common)
Any Python program trying to access this breaks:
$ python test.py
Traceback (most recent call last):
File "test.py", line 7, in ?
gt = gettext.GNUTranslations(file)
File "/usr/lib/python2.4/gettext.py", line 177, in
__init__
self._parse(fp)
File "/usr/lib/python2.4/gettext.py", line 300, in _parse
v = v.split(';')
AttributeError: 'list' object has no attribute 'split'
test.py is simple:
#!/usr/bin/env python
import gettext
file = open("test.mo", "rb")
if file:
gt = gettext.GNUTranslations(file)
The problem is the corner-case: plural-forms precedes
this kind of comment, so "v" is split (v=v.split(";")).
In the next instance, lastk is "plural-forms", yet the
entry doesn't contain ":", so it tries to set plural
forms to v.split(";") again, which fails since v is
already a list.
The attached simple patch fixes this.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-03-20 08:50
Message:
Logged In: YES
user_id=21627
dsegan: Can you give a real-world (i.e. non-documentation)
example of a PO file with a multi-line plural formula?
--
Comment By: Danilo Segan (dsegan)
Date: 2006-03-20 05:07
Message:
Logged In: YES
user_id=219596
Agreed on all points, except the "summary": multi-line
plural forms are actually supported and widely used.
Anyway, gettext.py should fail gracefully in case of any
problem in the header, instead of running into exception.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-03-19 12:51
Message:
Logged In: YES
user_id=21627
Several things seem to be going on here:
1. gettext.py is clearly wrong; it shouldn't break on that file.
2. it is trying to process multi-line fields here. So the
patch is also wrong, as it just sets k and v to None.
3. I believe that the PO file presented is also wrong. I
believe the intention of the header is that it should have
the RFC822 style syntax, which doesn't allow for # comment
lines. The tool should use a syntax like
X-Filename: plo.po; package=PACKAGE; version=VERSION;
To summarize, I think the attempt to process multi-line
fields in the header is misguided, and gettext.py should
just fetch the first line of content-type and plural-forms.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
