[ python-Bugs-1445781 ] install fails on hard link
Bugs item #1445781, was opened at 2006-03-08 17:06 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445781&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: None Status: Open Resolution: None Priority: 5 Submitted By: goldenautumnday (goldenautumnday) >Assigned to: Martin v. Löwis (loewis) Summary: install fails on hard link Initial Comment: Installing on an attached linux drive from a Mac OS X (Tiger) system fails because hard links are not supported. This is attempted when trying to link python2.4 to python (ln python2.4 python). If it fails, a copy should be performed instead. changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/idle to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/pydoc to 755 changing mode of /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/smtpd.py to 755 if test -f /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/ bin/python -o -h /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ then rm -f /Users/martinol/auto_v4.0/devel/powerpc-apple- darwin8.5.0/bin/python; \ else true; \ fi (cd /Users/martinol/auto_v4.0/devel/powerpc-apple-darwin8.5.0/bin; ln python2.4 python) ln: python: Operation not supported /Users/martinol/auto_v4.0 is symbolic link to /Volumes/thing/martinol which has been attached to using openapple-K (via SMB). -- Comment By: goldenautumnday (goldenautumnday) Date: 2006-03-08 20:22 Message: Logged In: YES user_id=1471082 Changing line 599 in Makefile.pre.in to: (cd $(DESTDIR)$(BINDIR); $(LN) python$(VERSION)$(EXE) $(PYTHON) || cp python $(VERSION)$(EXE) $(PYTHON)) allowed make to complete. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445781&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1447885 ] traceback.format_exception_only() and SyntaxError
Bugs item #1447885, was opened at 2006-03-11 14:46 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=1447885&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: Remy Blank (remyblank) Assigned to: Nobody/Anonymous (nobody) Summary: traceback.format_exception_only() and SyntaxError Initial Comment: There is a special case in traceback.format_exception_only() for SyntaxError so that the location of the syntax error is printed. Unfortunately, the test is written so that it only works with SyntaxError, but not for children of SyntaxError, e.g. IndentationError. OTOH, the interpreter prints the correct output if the exception is allowed to terminate the program. I have attached a test case that shows the difference in output. With the current traceback.py module, the output is different: [EMAIL PROTECTED] py $ ./testSyntaxError.py Traceback (most recent call last): File "./testSyntaxError.py", line 7, in ? import SyntaxErr IndentationError: expected an indented block (SyntaxErr.py, line 2) [EMAIL PROTECTED] py $ ./testSyntaxError.py raise Traceback (most recent call last): File "./testSyntaxError.py", line 7, in ? import SyntaxErr File "/home/joe/tmp/py/SyntaxErr.py", line 2 class OtherClass: ^ IndentationError: expected an indented block There's a second file that is needed for the test case, I'll attach it as well. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447885&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1447885 ] traceback.format_exception_only() and SyntaxError
Bugs item #1447885, was opened at 2006-03-11 14:46 Message generated for change (Comment added) made by remyblank You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447885&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: Remy Blank (remyblank) Assigned to: Nobody/Anonymous (nobody) Summary: traceback.format_exception_only() and SyntaxError Initial Comment: There is a special case in traceback.format_exception_only() for SyntaxError so that the location of the syntax error is printed. Unfortunately, the test is written so that it only works with SyntaxError, but not for children of SyntaxError, e.g. IndentationError. OTOH, the interpreter prints the correct output if the exception is allowed to terminate the program. I have attached a test case that shows the difference in output. With the current traceback.py module, the output is different: [EMAIL PROTECTED] py $ ./testSyntaxError.py Traceback (most recent call last): File "./testSyntaxError.py", line 7, in ? import SyntaxErr IndentationError: expected an indented block (SyntaxErr.py, line 2) [EMAIL PROTECTED] py $ ./testSyntaxError.py raise Traceback (most recent call last): File "./testSyntaxError.py", line 7, in ? import SyntaxErr File "/home/joe/tmp/py/SyntaxErr.py", line 2 class OtherClass: ^ IndentationError: expected an indented block There's a second file that is needed for the test case, I'll attach it as well. -- >Comment By: Remy Blank (remyblank) Date: 2006-03-11 14:47 Message: Logged In: YES user_id=568100 This file generates the IndentationError. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447885&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1447885 ] traceback.format_exception_only() and SyntaxError
Bugs item #1447885, was opened at 2006-03-11 14:46 Message generated for change (Comment added) made by remyblank You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447885&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: Remy Blank (remyblank) Assigned to: Nobody/Anonymous (nobody) Summary: traceback.format_exception_only() and SyntaxError Initial Comment: There is a special case in traceback.format_exception_only() for SyntaxError so that the location of the syntax error is printed. Unfortunately, the test is written so that it only works with SyntaxError, but not for children of SyntaxError, e.g. IndentationError. OTOH, the interpreter prints the correct output if the exception is allowed to terminate the program. I have attached a test case that shows the difference in output. With the current traceback.py module, the output is different: [EMAIL PROTECTED] py $ ./testSyntaxError.py Traceback (most recent call last): File "./testSyntaxError.py", line 7, in ? import SyntaxErr IndentationError: expected an indented block (SyntaxErr.py, line 2) [EMAIL PROTECTED] py $ ./testSyntaxError.py raise Traceback (most recent call last): File "./testSyntaxError.py", line 7, in ? import SyntaxErr File "/home/joe/tmp/py/SyntaxErr.py", line 2 class OtherClass: ^ IndentationError: expected an indented block There's a second file that is needed for the test case, I'll attach it as well. -- >Comment By: Remy Blank (remyblank) Date: 2006-03-11 14:51 Message: Logged In: YES user_id=568100 This patch makes both the output of the interpreter and the output generated by format_exception_only() identical. -- Comment By: Remy Blank (remyblank) Date: 2006-03-11 14:47 Message: Logged In: YES user_id=568100 This file generates the IndentationError. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447885&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1447945 ] Unable to stringify datetime with tzinfo
Bugs item #1447945, was opened at 2006-03-11 20:51
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=1447945&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: Ilpo Nyyssönen (biny)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to stringify datetime with tzinfo
Initial Comment:
zdump -v Europe/Helsinki | head -5 gives
Europe/Helsinki Fri Dec 13 20:45:52 1901 UTC = Fri Dec
13 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Dec 14 20:45:52 1901 UTC = Sat Dec
14 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Apr 30 22:20:07 1921 UTC = Sat Apr
30 23:59:59 1921 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Apr 30 22:20:08 1921 UTC = Sun May
1 00:20:08 1921 EET isdst=0 gmtoff=7200
Europe/Helsinki Thu Apr 2 21:59:59 1942 UTC = Thu Apr
2 23:59:59 1942 EET isdst=0 gmtoff=7200
Europe/Helsinki Thu Apr 2 22:00:00 1942 UTC = Fri Apr
3 01:00:00 1942 EEST isdst=1 gmtoff=10800
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
->> from datetime import datetime
->> from dateutil import tz
->> str(datetime(1920, 1, 1, 0, 0,
tzinfo=tz.gettz('Europe/Helsinki')))
Traceback (most recent call last):
File "", line 2, in ?
ValueError: tzinfo.utcoffset() must return a whole
number of minutes
->>
tz.gettz('Europe/Helsinki').utcoffset((datetime(1900,
1, 1, 0, 0)))
datetime.timedelta(0, 5992)
->>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447945&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1447945 ] Unable to stringify datetime with tzinfo
Bugs item #1447945, was opened at 2006-03-11 13:51
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447945&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: Ilpo Nyyssönen (biny)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to stringify datetime with tzinfo
Initial Comment:
zdump -v Europe/Helsinki | head -5 gives
Europe/Helsinki Fri Dec 13 20:45:52 1901 UTC = Fri Dec
13 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Dec 14 20:45:52 1901 UTC = Sat Dec
14 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Apr 30 22:20:07 1921 UTC = Sat Apr
30 23:59:59 1921 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Apr 30 22:20:08 1921 UTC = Sun May
1 00:20:08 1921 EET isdst=0 gmtoff=7200
Europe/Helsinki Thu Apr 2 21:59:59 1942 UTC = Thu Apr
2 23:59:59 1942 EET isdst=0 gmtoff=7200
Europe/Helsinki Thu Apr 2 22:00:00 1942 UTC = Fri Apr
3 01:00:00 1942 EEST isdst=1 gmtoff=10800
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
->> from datetime import datetime
->> from dateutil import tz
->> str(datetime(1920, 1, 1, 0, 0,
tzinfo=tz.gettz('Europe/Helsinki')))
Traceback (most recent call last):
File "", line 2, in ?
ValueError: tzinfo.utcoffset() must return a whole
number of minutes
->>
tz.gettz('Europe/Helsinki').utcoffset((datetime(1900,
1, 1, 0, 0)))
datetime.timedelta(0, 5992)
->>
--
>Comment By: Tim Peters (tim_one)
Date: 2006-03-11 13:58
Message:
Logged In: YES
user_id=31435
What's this?
>>> from dateutil import tz
There is no `dateutil` module in the Python distribution (in
which case problems with `dateutil` should be directed to
its developers, not to the Python tracker).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447945&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1447945 ] Unable to stringify datetime with tzinfo
Bugs item #1447945, was opened at 2006-03-11 20:51
Message generated for change (Comment added) made by biny
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447945&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: Ilpo Nyyssönen (biny)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to stringify datetime with tzinfo
Initial Comment:
zdump -v Europe/Helsinki | head -5 gives
Europe/Helsinki Fri Dec 13 20:45:52 1901 UTC = Fri Dec
13 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Dec 14 20:45:52 1901 UTC = Sat Dec
14 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Apr 30 22:20:07 1921 UTC = Sat Apr
30 23:59:59 1921 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Apr 30 22:20:08 1921 UTC = Sun May
1 00:20:08 1921 EET isdst=0 gmtoff=7200
Europe/Helsinki Thu Apr 2 21:59:59 1942 UTC = Thu Apr
2 23:59:59 1942 EET isdst=0 gmtoff=7200
Europe/Helsinki Thu Apr 2 22:00:00 1942 UTC = Fri Apr
3 01:00:00 1942 EEST isdst=1 gmtoff=10800
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
->> from datetime import datetime
->> from dateutil import tz
->> str(datetime(1920, 1, 1, 0, 0,
tzinfo=tz.gettz('Europe/Helsinki')))
Traceback (most recent call last):
File "", line 2, in ?
ValueError: tzinfo.utcoffset() must return a whole
number of minutes
->>
tz.gettz('Europe/Helsinki').utcoffset((datetime(1900,
1, 1, 0, 0)))
datetime.timedelta(0, 5992)
->>
--
>Comment By: Ilpo Nyyssönen (biny)
Date: 2006-03-11 21:06
Message:
Logged In: YES
user_id=861953
The error is from datetime and it is from python
distribution. The tz uses operating systems information
about the timezones and as the zdump shows, it gets there
utcoffset that is not full minute.
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-11 20:58
Message:
Logged In: YES
user_id=31435
What's this?
>>> from dateutil import tz
There is no `dateutil` module in the Python distribution (in
which case problems with `dateutil` should be directed to
its developers, not to the Python tracker).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447945&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1447945 ] Unable to stringify datetime with tzinfo
Bugs item #1447945, was opened at 2006-03-11 20:51
Message generated for change (Comment added) made by biny
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447945&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: Ilpo Nyyssönen (biny)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to stringify datetime with tzinfo
Initial Comment:
zdump -v Europe/Helsinki | head -5 gives
Europe/Helsinki Fri Dec 13 20:45:52 1901 UTC = Fri Dec
13 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Dec 14 20:45:52 1901 UTC = Sat Dec
14 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Apr 30 22:20:07 1921 UTC = Sat Apr
30 23:59:59 1921 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Apr 30 22:20:08 1921 UTC = Sun May
1 00:20:08 1921 EET isdst=0 gmtoff=7200
Europe/Helsinki Thu Apr 2 21:59:59 1942 UTC = Thu Apr
2 23:59:59 1942 EET isdst=0 gmtoff=7200
Europe/Helsinki Thu Apr 2 22:00:00 1942 UTC = Fri Apr
3 01:00:00 1942 EEST isdst=1 gmtoff=10800
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
->> from datetime import datetime
->> from dateutil import tz
->> str(datetime(1920, 1, 1, 0, 0,
tzinfo=tz.gettz('Europe/Helsinki')))
Traceback (most recent call last):
File "", line 2, in ?
ValueError: tzinfo.utcoffset() must return a whole
number of minutes
->>
tz.gettz('Europe/Helsinki').utcoffset((datetime(1900,
1, 1, 0, 0)))
datetime.timedelta(0, 5992)
->>
--
>Comment By: Ilpo Nyyssönen (biny)
Date: 2006-03-11 21:12
Message:
Logged In: YES
user_id=861953
What do you think is best solution?
1) Python datetime is changed to tolerate more.
2) Linux tzdata package is changed to contain only full
minute offsets. Who is going to convince them that this is
good idea?
3) The python-dateutil tz library is changed to touch the
information provided by the operating system.
--
Comment By: Ilpo Nyyssönen (biny)
Date: 2006-03-11 21:06
Message:
Logged In: YES
user_id=861953
The error is from datetime and it is from python
distribution. The tz uses operating systems information
about the timezones and as the zdump shows, it gets there
utcoffset that is not full minute.
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-11 20:58
Message:
Logged In: YES
user_id=31435
What's this?
>>> from dateutil import tz
There is no `dateutil` module in the Python distribution (in
which case problems with `dateutil` should be directed to
its developers, not to the Python tracker).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447945&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1447945 ] Unable to stringify datetime with tzinfo
Bugs item #1447945, was opened at 2006-03-11 13:51
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447945&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: Ilpo Nyyssönen (biny)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to stringify datetime with tzinfo
Initial Comment:
zdump -v Europe/Helsinki | head -5 gives
Europe/Helsinki Fri Dec 13 20:45:52 1901 UTC = Fri Dec
13 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Dec 14 20:45:52 1901 UTC = Sat Dec
14 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Apr 30 22:20:07 1921 UTC = Sat Apr
30 23:59:59 1921 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Apr 30 22:20:08 1921 UTC = Sun May
1 00:20:08 1921 EET isdst=0 gmtoff=7200
Europe/Helsinki Thu Apr 2 21:59:59 1942 UTC = Thu Apr
2 23:59:59 1942 EET isdst=0 gmtoff=7200
Europe/Helsinki Thu Apr 2 22:00:00 1942 UTC = Fri Apr
3 01:00:00 1942 EEST isdst=1 gmtoff=10800
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
->> from datetime import datetime
->> from dateutil import tz
->> str(datetime(1920, 1, 1, 0, 0,
tzinfo=tz.gettz('Europe/Helsinki')))
Traceback (most recent call last):
File "", line 2, in ?
ValueError: tzinfo.utcoffset() must return a whole
number of minutes
->>
tz.gettz('Europe/Helsinki').utcoffset((datetime(1900,
1, 1, 0, 0)))
datetime.timedelta(0, 5992)
->>
--
>Comment By: Tim Peters (tim_one)
Date: 2006-03-11 15:38
Message:
Logged In: YES
user_id=31435
I don't know that this needs "a solution", but doubt
anything relevant is going to change in Python regardless --
that utcoffset() must return a whole number of minutes has
been documented from the start, and in several years hasn't
caused anyone else a problem.
Do you really believe that Helsinki was once 99 minutes and
52 seconds off from UTC? I don't ;-) Seems more likely
that your installation's time zone info is corrupt; that
this specific piece of historical time zone info is wrong
but nobody noticed before ("historical" because it's
certainly not the case that Helsinki is ever 5992 seconds
off from UTC in current reality); or that `dateutil` has a
relevant error.
--
Comment By: Ilpo Nyyssönen (biny)
Date: 2006-03-11 14:12
Message:
Logged In: YES
user_id=861953
What do you think is best solution?
1) Python datetime is changed to tolerate more.
2) Linux tzdata package is changed to contain only full
minute offsets. Who is going to convince them that this is
good idea?
3) The python-dateutil tz library is changed to touch the
information provided by the operating system.
--
Comment By: Ilpo Nyyssönen (biny)
Date: 2006-03-11 14:06
Message:
Logged In: YES
user_id=861953
The error is from datetime and it is from python
distribution. The tz uses operating systems information
about the timezones and as the zdump shows, it gets there
utcoffset that is not full minute.
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-11 13:58
Message:
Logged In: YES
user_id=31435
What's this?
>>> from dateutil import tz
There is no `dateutil` module in the Python distribution (in
which case problems with `dateutil` should be directed to
its developers, not to the Python tracker).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447945&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 (Tracker Item Submitted) made by Item Submitter
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: 5
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.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448058 ] problems with too many sockets in FreeBSD
Bugs item #1448058, was opened at 2006-03-12 02:19 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=1448058&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.5 Status: Open Resolution: None Priority: 5 Submitted By: aix-d (aix-d) Assigned to: Nobody/Anonymous (nobody) Summary: problems with too many sockets in FreeBSD Initial Comment: When there are about 200 sockets, or so, i'm getting errors: "unable to select on socket" We are running multithread application, for each thread there is one socket. TRACEBACK contains: r = self.connection.recv(1024) error: unable to select on socket. This error appeared after fixing this problem: http://sourceforge.net/tracker/index.php?func=detail&aid=1429585&group_id=5470&atid=105470 Python version: 2.5a0 (trunk, Mar 8 2006, 18:28:30) OS version: FreeBSD 6.1-PRERELEASE Soon we will make program that will reproduce this error if needed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448058&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
Bugs item #1448060, was opened at 2006-03-12 00:20
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=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
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.
--
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-1448060 ] gettext.py breaks on plural-forms header (PATCH)
Bugs item #1448060, was opened at 2006-03-12 00:20
Message generated for change (Settings changed) 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.
--
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-1447945 ] Unable to stringify datetime with tzinfo
Bugs item #1447945, was opened at 2006-03-11 20:51
Message generated for change (Comment added) made by biny
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447945&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: Ilpo Nyyssönen (biny)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to stringify datetime with tzinfo
Initial Comment:
zdump -v Europe/Helsinki | head -5 gives
Europe/Helsinki Fri Dec 13 20:45:52 1901 UTC = Fri Dec
13 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Dec 14 20:45:52 1901 UTC = Sat Dec
14 22:25:44 1901 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Apr 30 22:20:07 1921 UTC = Sat Apr
30 23:59:59 1921 EET isdst=0 gmtoff=5992
Europe/Helsinki Sat Apr 30 22:20:08 1921 UTC = Sun May
1 00:20:08 1921 EET isdst=0 gmtoff=7200
Europe/Helsinki Thu Apr 2 21:59:59 1942 UTC = Thu Apr
2 23:59:59 1942 EET isdst=0 gmtoff=7200
Europe/Helsinki Thu Apr 2 22:00:00 1942 UTC = Fri Apr
3 01:00:00 1942 EEST isdst=1 gmtoff=10800
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
->> from datetime import datetime
->> from dateutil import tz
->> str(datetime(1920, 1, 1, 0, 0,
tzinfo=tz.gettz('Europe/Helsinki')))
Traceback (most recent call last):
File "", line 2, in ?
ValueError: tzinfo.utcoffset() must return a whole
number of minutes
->>
tz.gettz('Europe/Helsinki').utcoffset((datetime(1900,
1, 1, 0, 0)))
datetime.timedelta(0, 5992)
->>
--
>Comment By: Ilpo Nyyssönen (biny)
Date: 2006-03-12 07:49
Message:
Logged In: YES
user_id=861953
I need a solution for this. Either I need to work around it
myself or I need to create a patched version of python or
dateutil.
We can't compare datetimes with tzinfos with datetimes
without tzinfos. This means that I either have tzinfo for
every datetime or for none. I prefer having them. Mostly I
am handling recent or future times, but I do want to have
some a bit older times too. It is not a problem if those
older times are not that exact, but I really don't want
those to cause errors. I ran into this while trying to
import data to my software and the whole import failed
because of this.
I really don't know what the offset was. Maybe the tzdata
people have some reason for it, maybe it is a bug with them.
But I don't see myself going to tell them that they need to
change the data because python does not work with it. How
could I be sure that they would change all such occurrences
and wouldn't do it again?
My preferred solution would be that python datetime would
somehow tolerate it and not cause errors. It could even
round it to make it full minute. As these errors clearly
happen only with old times people rarely use, I don't see it
as a problem to make it a bit inaccurate.
If python won't change, then maybe I need to go and try to
say to dateutil people that they need to round the offsets
to avoid errors.
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-11 22:38
Message:
Logged In: YES
user_id=31435
I don't know that this needs "a solution", but doubt
anything relevant is going to change in Python regardless --
that utcoffset() must return a whole number of minutes has
been documented from the start, and in several years hasn't
caused anyone else a problem.
Do you really believe that Helsinki was once 99 minutes and
52 seconds off from UTC? I don't ;-) Seems more likely
that your installation's time zone info is corrupt; that
this specific piece of historical time zone info is wrong
but nobody noticed before ("historical" because it's
certainly not the case that Helsinki is ever 5992 seconds
off from UTC in current reality); or that `dateutil` has a
relevant error.
--
Comment By: Ilpo Nyyssönen (biny)
Date: 2006-03-11 21:12
Message:
Logged In: YES
user_id=861953
What do you think is best solution?
1) Python datetime is changed to tolerate more.
2) Linux tzdata package is changed to contain only full
minute offsets. Who is going to convince them that this is
good idea?
3) The python-dateutil tz library is changed to touch the
information provided by the operating system.
--
Comment By: Ilpo Nyyssönen (biny)
Date: 2006-03-11 21:06
Message:
Logged In: YES
user_id=861953
The error is from datetime and it is from python
distribution. The tz uses operating systems information
about the timezones and as the zdump shows, it gets there
utcoffset that is not full minute.
-
[ python-Bugs-1183896 ] PCbuild/readme.txt description not quite right
Bugs item #1183896, was opened at 2005-04-15 17:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183896&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: Closed >Resolution: Invalid Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: PCbuild/readme.txt description not quite right Initial Comment: PCbuild/readme.txt contains some very useful instructions on obtaining external packages needed to build extensions (zlib, tk, etc), but there is a small error in the instruction as to where these distributions should be placed. "... download the base packages first and unpack them into siblings of PCbuilds's parent directory; for example, if your PCbuild is ...\dist\src\PCbuild\, unpack into new subdirectories of dist\." This should say "if your PCbuild is ...\dist\Python-2.4.1\src\PCbuild\" ... because that's what works. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-12 07:56 Message: Logged In: YES user_id=849994 Actually, it currently seems to be correct. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183896&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
