[ python-Bugs-1545658 ] distutils home scheme lacks python versioning
Bugs item #1545658, was opened at 2006-08-24 02:27
Message generated for change (Comment added) made by movement
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: Distutils
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: John Levon (movement)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils home scheme lacks python versioning
Initial Comment:
The "home scheme", as described here:
http://docs.python.org/inst/alt-install-windows.html
seems to be broken: no version suffix is appended,
yet .pyc files are not guaranteed across Python
revisions. Thus, breakage can occur.
This is quite annoying, as an OS vendor often would like
to install stuff into /usr/lib/python2.x/ (not using
vendor-packages).
--
>Comment By: John Levon (movement)
Date: 2006-09-11 10:17
Message:
Logged In: YES
user_id=53034
You still haven't given an explanation for why it's OK for
it to be different just because it's in somebody's $HOME.
> you have to live with the consequences
Huh? This makes no sense. I'm filing a bug saying the home
behaviour has problems and your answer is "it's not a bug,
because if you use this option, then you must live with this
bug". I can see an argument for this being an RFE, I
suppose, but I've really lost interest now.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 21:08
Message:
Logged In: YES
user_id=21627
I read the example you gave. In case of a shared directory,
you shouldn't use the "home" scheme. If you do anyway, you
have to live with the consequences. The home scheme is
called "home scheme" for a reason: the target directory is
expected to be inside the user's home directory.
--
Comment By: John Levon (movement)
Date: 2006-09-10 20:12
Message:
Logged In: YES
user_id=53034
> not have the right to install
Did you actually read the example I gave?
Just because it's a "possible slowdown" doesn't mean
that this behaviour is both inconsistent and potentially
troublesome. But I suppose you don't care.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 19:00
Message:
Logged In: YES
user_id=21627
Why would a user not have the right to install to its own
home directory? That's what the home scheme is there for.
In any case, it seems that there won't be actual breakage,
only a possible slowdown. I very much doubt that the
slowdown would ever be significant, though.
It seems you want to use the home scheme for something that
it was not designed for. Notice that it is merely an
abbreviation - you can specify the directories directly if
you want to.
I'm closing this as invalid: the original report ("Thus,
breakage can occur.") is apparently wrong.
--
Comment By: John Levon (movement)
Date: 2006-09-10 18:51
Message:
Logged In: YES
user_id=53034
Consider a shared tree where users do not have access to
write new .pyc's. Just like the standard python libraries,
there could be a significant speed slowdown due to not being
able to use the old .pyc's.
It's the exact same case that prompts distro's to install
into /usr/lib/pythonX.X/
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 15:26
Message:
Logged In: YES
user_id=21627
It's true that the format of marshal may change. More
regularly, the format of .pyc files may change due to
changes in the byte codes. Yet, I fail to see why this can
cause breakage. The pyc format is deliberately so designed
that nothing will break even if the format changes.
I'm still waiting for a demonstrable problem.
--
Comment By: John Levon (movement)
Date: 2006-09-10 14:55
Message:
Logged In: YES
user_id=53034
http://www.python.org/doc/1.5.2p2/lib/module-marshal.html
specifically:
"Details of the format are undocumented on purpose; it may
change between Python versions (although it rarely does)."
Thus, anyone using the home scheme can hit these changes as
the format is not architecturally guaranteed.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 00:13
Message:
Logged In: YES
user_id=21627
I fail to see the problem. Can you please provide a scenario
where breakage does occur (instead of merely suggesting that
it "can occur")? What is the specific error message that you
get?
Also, what does that have to do w
[ python-Bugs-1556261 ] Move fpectl elsewhere in library reference
Bugs item #1556261, was opened at 2006-09-11 10: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=1556261&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: Open Resolution: None Priority: 5 Submitted By: Michael Hoffman (hoffmanm) Assigned to: Nobody/Anonymous (nobody) Summary: Move fpectl elsewhere in library reference Initial Comment: The fpectl module is not installed by default, but it still has a prominent place in the library reference. I think it should be moved to Optional Operating System Services and a note added at the top that it is not installed by default. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556261&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512604 ] Install on Windows Vista locks up
Bugs item #1512604, was opened at 2006-06-26 13:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&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: Installation >Group: 3rd Party >Status: Closed Resolution: None Priority: 5 Submitted By: Michael Lucas (michael_lucas) Assigned to: Nobody/Anonymous (nobody) Summary: Install on Windows Vista locks up Initial Comment: I have had problems trying to install this version on Vista. When the install gets to the verifying disk space requirements the system locks up. It does not go any further. I have to cancel the instalation of python. The only way I have got around this is to install an older version of python (version 2.3.5) this version does work, but there are newer versions that I want to work with on my system. If anyone has a work around for this please contact me at [EMAIL PROTECTED] -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-11 14:03 Message: Logged In: YES user_id=21627 It appears that this problem has been fixed in Vista RC1. Closing this report as third-party bug. -- Comment By: Martin v. Löwis (loewis) Date: 2006-07-07 07:08 Message: Logged In: YES user_id=21627 That's actually no surprise: /qb disables the user interface, so that the problematic interaction is skipped entirely. -- Comment By: Pat Lathem (plathem) Date: 2006-07-07 03:51 Message: Logged In: YES user_id=661716 FWIW, this can be worked around by using the command-line MSI installer: msiexec /i python-2.4.3.msi TARGETDIR="C:\Program Files\Python24" ALLUSERS=1 /qb Found that here: http://mail.python.org/pipermail/python-list/2006-June/347402.html -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-29 20:48 Message: Logged In: YES user_id=21627 I can confirm the problem, but I doubt I can do much about it. In fact, I believe this is a bug in Vista/Windows Installer 4.0. The installer GUI waits for the CostingComplete property to be set, but this never happens. If you are a beta tester, please make a bug report to Microsoft. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512604&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1510984 ] 2.5b1 windows won't install or admit failure
Bugs item #1510984, was opened at 2006-06-23 00:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&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: Installation Group: Python 2.5 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5b1 windows won't install or admit failure Initial Comment: I downloaded the Windows 2.5b1, and then tried to install following all defaults. I had previously installed 2.5a2, and it is possible that I switched between "install for all users" and "install just for me". The install offered me a finish button, and no protest when I clicked it -- but after that, the shortcuts did not start python (nor did they protest; they just went into never neverland). Starting python at the command line did work. Reinstall with a repair did not fix anything. Uninstall, then uninstall 2.5a, then install on a "clean" system did work. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-11 14:04 Message: Logged In: YES user_id=21627 Closing this as "works for me". If it happens again, please create a new report with the exact steps needed to reproduce. -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-30 06:40 Message: Logged In: YES user_id=21627 The alpha installers are at http://www.python.org/ftp/python/2.5/prev/ -- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-29 22:21 Message: Logged In: YES user_id=764593 I can no longer locate the alpha installers, but I'll see if I can reproduce it with the beta installer plus a 2.4 version. -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-29 20:59 Message: Logged In: YES user_id=21627 I could not reproduce the problem. Can you please try to reproduce it, installing things in the order you did? Please provide all details, such as sequence of MSI invocations, options selected, reboots/logouts performed, etc. -- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 17:39 Message: Logged In: YES user_id=764593 All versions are binary downloads for windows, from python.org I have a 2.4, which seems not to be relevant. I don't remember whether I had installed 2.5a1, though I think so. If I had, it was successfully overwritten by 2.5a2. I had definately installed 2.5a2. The problem came when I attempted to install 2.5b1 on top of 2.5a2. -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-24 12:28 Message: Logged In: YES user_id=21627 Can you please give a precise reference to what you've downloaded? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545658 ] distutils home scheme lacks python versioning
Bugs item #1545658, was opened at 2006-08-24 04:27
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: Distutils
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: John Levon (movement)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils home scheme lacks python versioning
Initial Comment:
The "home scheme", as described here:
http://docs.python.org/inst/alt-install-windows.html
seems to be broken: no version suffix is appended,
yet .pyc files are not guaranteed across Python
revisions. Thus, breakage can occur.
This is quite annoying, as an OS vendor often would like
to install stuff into /usr/lib/python2.x/ (not using
vendor-packages).
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-09-11 21:48
Message:
Logged In: YES
user_id=21627
It's ok for the Lib directory to be the same across Python
versions because it means that the user doesn't have to
reinstall the packages (atleast not the pure-python ones,
and, conditionally, perhaps not even the binary ones) when
the Python version changes. Python will automatically,
transparently replace the byte code files when the system
Python is updated, and the user only has to add a single
directory to the PYTHONPATH. If the user has the convention
to include ~/bin in his path, he doesn't need any additional
setup for scripts that get installed.
So, adding a version number into the directories would add
additional inconvenience, since the user would have to
install the same package multiple times, and because she
would have to set PYTHONPATH differently depending on what
Python version she wants to use. It is the way it is to
please the user; changing it the way you propose would make
it more inconvenient.
Now, you suggest that the home scheme would be used by an OS
vendor who likes to install into /usr/lib/python2.x. This is
an abuse of the home scheme, and what works very well for a
user apparently does not work well for an OS vendor. If the
OS vendor tries this abuse anyway, he must live with the
consequences.
The user would be better advised to use the UNIX scheme,
pass --prefix=/usr. This would automatically put things into
/usr/lib/python2.x. Why the OS vendor would chose not do so,
I cannot guess.
--
Comment By: John Levon (movement)
Date: 2006-09-11 12:17
Message:
Logged In: YES
user_id=53034
You still haven't given an explanation for why it's OK for
it to be different just because it's in somebody's $HOME.
> you have to live with the consequences
Huh? This makes no sense. I'm filing a bug saying the home
behaviour has problems and your answer is "it's not a bug,
because if you use this option, then you must live with this
bug". I can see an argument for this being an RFE, I
suppose, but I've really lost interest now.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 23:08
Message:
Logged In: YES
user_id=21627
I read the example you gave. In case of a shared directory,
you shouldn't use the "home" scheme. If you do anyway, you
have to live with the consequences. The home scheme is
called "home scheme" for a reason: the target directory is
expected to be inside the user's home directory.
--
Comment By: John Levon (movement)
Date: 2006-09-10 22:12
Message:
Logged In: YES
user_id=53034
> not have the right to install
Did you actually read the example I gave?
Just because it's a "possible slowdown" doesn't mean
that this behaviour is both inconsistent and potentially
troublesome. But I suppose you don't care.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 21:00
Message:
Logged In: YES
user_id=21627
Why would a user not have the right to install to its own
home directory? That's what the home scheme is there for.
In any case, it seems that there won't be actual breakage,
only a possible slowdown. I very much doubt that the
slowdown would ever be significant, though.
It seems you want to use the home scheme for something that
it was not designed for. Notice that it is merely an
abbreviation - you can specify the directories directly if
you want to.
I'm closing this as invalid: the original report ("Thus,
breakage can occur.") is apparently wrong.
--
Comment By: John Levon (movement)
Date: 2006-09-10 20:51
Message:
Logged In: YES
user_id=53034
Consider a shared tree where users do not
[ python-Bugs-1545658 ] distutils home scheme lacks python versioning
Bugs item #1545658, was opened at 2006-08-24 02:27 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: Distutils Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). -- >Comment By: John Levon (movement) Date: 2006-09-11 20:24 Message: Logged In: YES user_id=53034 Regarding the first part of your reply - I can understand that; thanks for the detailed rationale. Perhaps this bug is really about the distutils docs? In particular it seems useful to clarify the problems with non-pure modules as well. Regarding the second - it's only relevant due to the lack of upstream vendor-packages support. That is, I was trying to clean up our builds to not have to do: mv site-packages vendor-packages (You can refer to the original vendor-packages discussion if you're still asking why we don't install into the main Python directory.) I understand this was more of a hack than a solution, so consider that part void. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-11 19:48 Message: Logged In: YES user_id=21627 It's ok for the Lib directory to be the same across Python versions because it means that the user doesn't have to reinstall the packages (atleast not the pure-python ones, and, conditionally, perhaps not even the binary ones) when the Python version changes. Python will automatically, transparently replace the byte code files when the system Python is updated, and the user only has to add a single directory to the PYTHONPATH. If the user has the convention to include ~/bin in his path, he doesn't need any additional setup for scripts that get installed. So, adding a version number into the directories would add additional inconvenience, since the user would have to install the same package multiple times, and because she would have to set PYTHONPATH differently depending on what Python version she wants to use. It is the way it is to please the user; changing it the way you propose would make it more inconvenient. Now, you suggest that the home scheme would be used by an OS vendor who likes to install into /usr/lib/python2.x. This is an abuse of the home scheme, and what works very well for a user apparently does not work well for an OS vendor. If the OS vendor tries this abuse anyway, he must live with the consequences. The user would be better advised to use the UNIX scheme, pass --prefix=/usr. This would automatically put things into /usr/lib/python2.x. Why the OS vendor would chose not do so, I cannot guess. -- Comment By: John Levon (movement) Date: 2006-09-11 10:17 Message: Logged In: YES user_id=53034 You still haven't given an explanation for why it's OK for it to be different just because it's in somebody's $HOME. > you have to live with the consequences Huh? This makes no sense. I'm filing a bug saying the home behaviour has problems and your answer is "it's not a bug, because if you use this option, then you must live with this bug". I can see an argument for this being an RFE, I suppose, but I've really lost interest now. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 21:08 Message: Logged In: YES user_id=21627 I read the example you gave. In case of a shared directory, you shouldn't use the "home" scheme. If you do anyway, you have to live with the consequences. The home scheme is called "home scheme" for a reason: the target directory is expected to be inside the user's home directory. -- Comment By: John Levon (movement) Date: 2006-09-10 20:12 Message: Logged In: YES user_id=53034 > not have the right to install Did you actually read the example I gave? Just because it's a "possible slowdown" doesn't mean that this behaviour is both inconsistent and potentially troublesome. But I suppose you don't care. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-
[ python-Bugs-1545658 ] distutils home scheme lacks python versioning
Bugs item #1545658, was opened at 2006-08-24 04:27
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: Distutils
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: John Levon (movement)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils home scheme lacks python versioning
Initial Comment:
The "home scheme", as described here:
http://docs.python.org/inst/alt-install-windows.html
seems to be broken: no version suffix is appended,
yet .pyc files are not guaranteed across Python
revisions. Thus, breakage can occur.
This is quite annoying, as an OS vendor often would like
to install stuff into /usr/lib/python2.x/ (not using
vendor-packages).
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-09-11 23:01
Message:
Logged In: YES
user_id=21627
Unfortunately, the "vendor-packages" directory was never
really discussed. The only rationale I could find is from
Rich Burridge, on 09-20-2005, and says "We have been told
that this directory is inappropriate for vendor supplied
packages, just as "site_perl" is inappropriate for Perl."
This is hardly a convincing rationale: it is hearsay ("we
have been told", rather than "we believe"), and it suggests
that the only rationale for doing so is that Perl does so.
That couldn't convince me; the Perl way of doing things has
only in so far influenced Python as Perl was given as a bad
example which is not to follow in the past.
In any case, such discussion belongs to python-dev. I'm
personally not convinced that adding vendor-packages to
sys.path is necessary (why is site-packages not good
enough?), but I'm also not strongly opposed to add yet
another typically non-existing directory to the path
(especially since Python 2.5 caches the absence of the
directory so it gets skipped in subsequent imports)
--
Comment By: John Levon (movement)
Date: 2006-09-11 22:24
Message:
Logged In: YES
user_id=53034
Regarding the first part of your reply - I can understand
that; thanks for the detailed rationale.
Perhaps this bug is really about the distutils docs? In
particular it seems useful to clarify the problems with
non-pure modules as well.
Regarding the second - it's only relevant due to the lack of
upstream vendor-packages support. That is, I was trying to
clean up our builds to not have to do:
mv site-packages vendor-packages
(You can refer to the original vendor-packages discussion if
you're still asking why we don't install into the main
Python directory.) I understand this was more of a hack than
a solution, so consider that part void.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-11 21:48
Message:
Logged In: YES
user_id=21627
It's ok for the Lib directory to be the same across Python
versions because it means that the user doesn't have to
reinstall the packages (atleast not the pure-python ones,
and, conditionally, perhaps not even the binary ones) when
the Python version changes. Python will automatically,
transparently replace the byte code files when the system
Python is updated, and the user only has to add a single
directory to the PYTHONPATH. If the user has the convention
to include ~/bin in his path, he doesn't need any additional
setup for scripts that get installed.
So, adding a version number into the directories would add
additional inconvenience, since the user would have to
install the same package multiple times, and because she
would have to set PYTHONPATH differently depending on what
Python version she wants to use. It is the way it is to
please the user; changing it the way you propose would make
it more inconvenient.
Now, you suggest that the home scheme would be used by an OS
vendor who likes to install into /usr/lib/python2.x. This is
an abuse of the home scheme, and what works very well for a
user apparently does not work well for an OS vendor. If the
OS vendor tries this abuse anyway, he must live with the
consequences.
The user would be better advised to use the UNIX scheme,
pass --prefix=/usr. This would automatically put things into
/usr/lib/python2.x. Why the OS vendor would chose not do so,
I cannot guess.
--
Comment By: John Levon (movement)
Date: 2006-09-11 12:17
Message:
Logged In: YES
user_id=53034
You still haven't given an explanation for why it's OK for
it to be different just because it's in somebody's $HOME.
> you have to live with the consequences
Huh? This makes no sense. I'm filing a bug saying the home
behaviour has
[ python-Bugs-1553496 ] logging.handlers.RotatingFileHandler - inconsistent mode
Bugs item #1553496, was opened at 2006-09-06 16:03 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553496&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: Closed >Resolution: Invalid Priority: 5 Submitted By: Walker Hale (walkerh) Assigned to: Vinay Sajip (vsajip) Summary: logging.handlers.RotatingFileHandler - inconsistent mode Initial Comment: RotatingFileHandler does not remember the mode used to open files. By default it will initially open its file with 'a', but client code may set this to something else. After rollover, the mode for the new file changes to 'w'. The behavior is inconsistent with the interface. At the very least the docstring for __init__ should change to show that the mode parameter is not respected after rollover. This affects previous versions. -- >Comment By: Vinay Sajip (vsajip) Date: 2006-09-11 22:31 Message: Logged In: YES user_id=308438 I don't feel that the current behaviour is inconsistent, because you normally want the current log file to be appended to, when the program starts. (Of course, you can override this to specify "w" and start with a new file for every run.) However, when you rollover, you want the new file to be truncated, and not have new log messages appended to existing data. Hence, "a" is used at first, and "w" at rollover. Remember, the log file before rollover (e.g. test.log) is renamed to test.log.n, and rolled-over output goes into test.log. Since the original test.log is now test.log.n, what does it mean to open test.log with "a"? Since test.log does not exist, opening with "w" and "a" are equivalent. If you spot a flaw in this reasoning, please re-open and give a more detailed scenario which explains exactly why the current behaviour is causing you a problem. In particular, it would help if you could walk me through a scenario which shows how the system would behave observably differently if "a" were used instead of "w" at rollover. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553496&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1556784 ] datetime's strftime limits strings to 127 chars
Bugs item #1556784, was opened at 2006-09-11 22: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=1556784&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: Eric V. Smith (ericvsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime's strftime limits strings to 127 chars
Initial Comment:
[I'm putting this in category Python Library, because I
assume Extensions Modules is for problems in the
Extensions Module plumbing.]
datetime.date and datetime.time's strftime() methods
call wrap_strftime(), which limits the length of the
format string to 127 chars before calling time.strftime().
This can be seen in the examples below. Note that in
the third example, time.strftime() does not have a
problem with a 128 character format string.
>>> import datetime
>>> datetime.date.today().strftime('x'*128)
Traceback (most recent call last):
File "", line 1, in
MemoryError
>>> import datetime
>>> datetime.date.today().strftime('x'*256)
Traceback (most recent call last):
File "", line 1, in
SystemError: Objects/stringobject.c:4077: bad argument
to internal function
>>> import time
>>> time.strftime('x'*128)
''
Reproduced on 2.5c1 Linux, 2.4.3 Linux, and 2.3.3 Windows.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556784&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
